Bug#1032517: nginx settings deleted on upgrade

[Асет Шарипова]

On Wed, 08 Mar 2023 13:47:47 +0100 Ralf Jung  wrote:
> Package: nginx
> Version: 1.22.1-7
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> 
> last weekend I did an "apt upgrade" of my system as usual, asking apt to 
> prune configuration files for packages that are being uninstalled.
> Now I realize that my nginx stopped working, and it turns out its 
> configuration files are just completely gone.
> Look like the recent package reorganization went wrong and actually deletes 
> configuration under certain conditions -- that's pretty bad.
> Package updates shouldn't cause a loss of configuration files, even when 
> pruning packages that are not present any more.
> 
> Kind regards,
> Ralf
> 
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'testing-debug'), (100, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_USER
> 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 nginx depends on:
> ii debconf [debconf-2.0] 1.5.82
> ii iproute2 6.1.0-1
> ii libc6 2.36-8
> ii libcrypt1 1:4.4.33-2
> ii libpcre2-8-0 10.42-1
> ii libssl3 3.0.8-1
> ii zlib1g 1:1.2.13.dfsg-1
> 
> nginx recommends no packages.
> 
> Versions of packages nginx suggests:
> ii fcgiwrap 1.1.0-14
> pn nginx-doc 
> ii ssl-cert 1.1.2
> 
> -- Configuration Files:
> /etc/nginx/fastcgi.conf [Errno 2] No such file or directory: 
> '/etc/nginx/fastcgi.conf'
> /etc/nginx/fastcgi_params [Errno 2] No such file or directory: 
> '/etc/nginx/fastcgi_params'
> /etc/nginx/koi-utf [Errno 2] No such file or directory: '/etc/nginx/koi-utf'
> /etc/nginx/koi-win [Errno 2] No such file or directory: '/etc/nginx/koi-win'
> /etc/nginx/mime.types [Errno 2] No such file or directory: 
> '/etc/nginx/mime.types'
> /etc/nginx/nginx.conf [Errno 2] No such file or directory: 
> '/etc/nginx/nginx.conf'
> /etc/nginx/proxy_params [Errno 2] No such file or directory: 
> '/etc/nginx/proxy_params'
> /etc/nginx/scgi_params [Errno 2] No such file or directory: 
> '/etc/nginx/scgi_params'
> /etc/nginx/sites-available/default [Errno 2] No such file or directory: 
> '/etc/nginx/sites-available/default'
> /etc/nginx/snippets/fastcgi-php.conf [Errno 2] No such file or directory: 
> '/etc/nginx/snippets/fastcgi-php.conf'
> /etc/nginx/snippets/snakeoil.conf [Errno 2] No such file or directory: 
> '/etc/nginx/snippets/snakeoil.conf'
> /etc/nginx/uwsgi_params [Errno 2] No such file or directory: 
> '/etc/nginx/uwsgi_params'
> /etc/nginx/win-utf [Errno 2] No such file or directory: '/etc/nginx/win-utf'
> 


Отправлено с iPhone

Bug#1034236:

[fabricetsouli]

Hello,
FYI,mpd will be removed from bookworm tomorrow.

Regards,
Fabrice

Bug#1034775: ITP: libdbix-class-journal-perl -- auditing for tables managed by DBIx::Class

[mtj]

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

* Package name: libdbix-class-journal-perl
  Version : 0.900201
  Upstream Author : Jess Robinson 
* URL : https://metacpan.org/release/DBIx-Class-Journal
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : auditing for tables managed by DBIx::Class

DBIx::Class::Journal provides the basic utilities to write tests against
DBIx::Class.

The purpose of this DBIx::Class component module is to create an
audit-trail for all changes made to the data in your database (via a
DBIx::Class schema). It creates *changesets* and assigns each
create/update/delete operation an *id*. The creation and deletion date
of each row is stored, as well as the historical contents of any row
that gets changed.

All queries which need auditing must be called using "txn_do" in
DBIx::Class::Schema, which is used to create changesets for each
transaction.

To track who did which changes, the "user_id" (an integer) of the
current user can be set, and a "session_id" can also be set; both are
optional. To access the auditing schema to look at the auditdata or
revert a change, use "$schema->_journal_schema".

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1034774: xine-ui: aborts/killed when trying to play certain videos

[Brian Sammon]

Package: xine-ui
Version: 0.99.14-1
Severity: normal

Dear Maintainer,

When I try to view certain videos (one example is at
http://br1an.fastmail.fm.user.fm/debian/The_Banshees_Of_Inisherin.mp4 [4MB 
movie trailer] )
xine aborts/is killed immediately (sometimes after 1/2 sec of sound, but
never any video).

The following messages appear on the commandline where I ran xine:
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/i386-linux-gnu/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  150 (XVideo)
  Minor opcode of failed request:  13 ()
  Value in failed request:  0x2
  Serial number of failed request:  772
  Current serial number in output stream:  774

Let me know if there's things I can do to troubleshoot this further.

-- System Information:
Architecture: i386 (i686)

Kernel: Linux 4.19.0-23-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xine-ui depends on:
ii  libc62.36-9
ii  libcurl3-gnutls  7.43.0-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblirc-client0  0.9.4c-9
ii  libpng16-16  1.6.37-3
ii  libreadline8 8.1-2
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.1-2
ii  libxine2 1.2.13-1
ii  libxine2-ffmpeg  1.2.13-1
ii  libxine2-x   1.2.13-1
ii  libxinerama1 2:1.1.4-2
ii  libxtst6 2:1.2.2-1
ii  libxv1   2:1.0.11-1.1
ii  libxxf86vm1  1:1.1.3-1+b1

Versions of packages xine-ui recommends:
ii  xdg-utils  1.1.3-1+deb10u1

xine-ui suggests no packages.

-- no debconf information

Bug#1034773: unblock: flash-kernel/3.107

[Vagrant Cascadian]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: flash-ker...@packages.debian.org, debian-b...@lists.debian.org, 
vagr...@debian.org
Control: affects -1 + src:flash-kernel

Please unblock package flash-kernel

[ Reason ]

* Fixes issues in the OLPC boot script
* Adds hardware database entries for numerous boards
* Fixes reproducibilitiy issues with temporary files
* Fixes a regression since bullseye when building images on EFI
  systems

[ Impact ]

* Various hardware support is added, fixed or improved for better out
  of box experience.
* Reproducible building of system images created that include
  flash-kernel are possible.
* Creating images that use flash-kernel boot scripts is possible from
  EFI hosts systems again.

[ Tests ]

Tested booting pinebook pro (no regressions!)

[ Risks ]

Some of the hardware support is for obscure hardware, so may be hard
to test broadly (impact on other boards should be unlikely, though).

[ 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 testing

[ Other info ]

This is used by debian-installer, and they might want to make an RC
soon...

unblock flash-kernel/3.107


Thanks for considering!

live well,
  vagrant

diff -Nru flash-kernel-3.106/bootscript/armhf/olpc.fth 
flash-kernel-3.107/bootscript/armhf/olpc.fth
--- flash-kernel-3.106/bootscript/armhf/olpc.fth2022-03-23 
07:22:28.0 -0700
+++ flash-kernel-3.107/bootscript/armhf/olpc.fth2023-04-08 
17:51:45.0 -0700
@@ -1,19 +1,30 @@
 \ OLPC XO boot script
 
 : check-ofw-version ( -- )
-   " /" find-device
-   " compatible" get-property  abort" No compatible property on /" ( -- 
compatible$ )
-   " mrvl,mmp2" 2swap substring? not  if
- cr
+   " /" find-device " compatible" get-property
+   abort" No compatible property on /" ( -- compatible$ )
+
+   \ Good compatible strings
+   " mrvl,mmp2"2over sindex -1 <>  if  2drop exit  then
+   " marvell,mmp3" 2over sindex -1 <>  if  2drop exit  then
+
+   \ Try to be helpful
+   cr
+   " olpc,xo-1.75" 2swap sindex -1 <>  if
  ." Firmware Q4E00 or newer is needed to boot a Devicetree enabled 
kernel." cr
  cr
  ." One way to update is to copy http://dev.laptop.org/~quozl/q4e00ja.rom; 
cr
  ." to a FAT partition on a USB flash stick and run ""flash 
u:\q4e00ja.rom""" cr
- cr
- ." Aborting boot." cr
- show-sad
- abort
+ " show-sad" eval
+   else
+ ." This hardware or firmware revision is not supported. Sorry." cr
then
+   cr
+   ." Aborting boot." cr
+   abort
+;
+
+: set-model
\ Make sure the model is sensible -- flash-kernel relies on this.
" model" delete-property
" OLPC XO-1.75" " model" string-property
@@ -21,6 +32,7 @@
 
 visible unfreeze
 check-ofw-version
+set-model
 
 " last:\@@KERNEL@@" to boot-device
 " last:\@@INITRD@@" to ramdisk
diff -Nru flash-kernel-3.106/db/all.db flash-kernel-3.107/db/all.db
--- flash-kernel-3.106/db/all.db2022-04-22 16:48:49.0 -0700
+++ flash-kernel-3.107/db/all.db2023-04-08 17:51:45.0 -0700
@@ -29,6 +29,13 @@
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+Machine: Allwinner D1 Nezha
+Kernel-Flavors: allwinner riscv64
+DTB-Id: allwinner/sun20i-d1-nezha.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: Allwinner GA10H Quad Core Tablet (v1.1)
 Kernel-Flavors: armmp armmp-lpae
 Boot-Script-Path: /boot/boot.scr
@@ -386,6 +393,9 @@
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+## qemu instance on armhf
+Machine: Dummy Virtual Machine
+
 Machine: Empire Electronix D709 tablet
 Kernel-Flavors: armmp
 Boot-Script-Path: /boot/boot.scr
@@ -421,6 +431,9 @@
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools
 
+## ARMv8 Foundation Model
+Machine: Foundation-v8A
+
 Machine: Freescale i.MX53 Quick Start Board
 Machine: Freescale MX53 LOCO Board
 Kernel-Flavors: armmp mx5
@@ -895,6 +908,24 @@
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+Machine: Lenovo Miix 630
+Kernel-Flavors: arm64
+Boot-Script-Path: /boot/boot.scr
+DTB-Id: qcom/msm8998-lenovo-miix-630.dtb
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
+Machine: Lenovo ThinkPad X13s
+Kernel-Flavors: any
+DTB-Id: qcom/sc8280xp-lenovo-thinkpad-x13s.dtb
+
+Machine: Lenovo Yoga C630
+Kernel-Flavors: arm64
+Boot-Script-Path: /boot/boot.scr
+DTB-Id: qcom/sdm850-lenovo-yoga-c630.dtb
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 Machine: Lichee Pi Zero
 Kernel-Flavors: armmp armmp-lpae
 Boot-Script-Path: /boot/boot.scr
@@ -923,6 +954,9 @@
 U-Boot-Script-Name: bootscr.sunxi
 Required-Packages: u-boot-tools
 
+## qemu instance on arm64
+Machine: linux,dummy-virt
+
 Machine: Marvell 

Bug#1034772: ITP: libdbix-simple-class-perl -- advanced object construction for DBIx::Simple

[mtj]

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

* Package name: libdbix-simple-class-perl
  Version : 1.009
  Upstream Author : Красимир Беров 
* URL : https://metacpan.org/release/DBIx-Simple-Class
* License : Artistic-2.0
  Programming Lang: Perl
  Description : advanced object construction for DBIx::Simple

DBIx::Simple::Class is a database table/row abstraction. At the same
time it is not just a fancy representation of a table row like
DBIx::Simple::Result::RowObject.

Using this module will make your code more organized, clean and reliable
(separation of concerns + input-validation).
You will even get some more performance over plain DBIx::Simple
while keeping it's sexy features when you need them. Last but not
least, this module has no other non-CORE dependencies besides DBIx::Simple
and DBI.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1032615: please consider pcp over dool as replacement

[Marc Lehmann]

Please do NOT consider dool as replacement for dstat, but pcp instead.

The reasons are not only that pcp seems to be much more actively maintained,
it is also vastly more compatible to dstat than dool. For example, dool uses
an unreadable color palette (e.g. black text on black background) by
default, and uses a very different default output format.

pcp both works with the same terminals as dstat, and has a practically
identical default output format, i.e. it is indistinguishable top dstat
for most users out of the box.

It would certainly be great to package dool, but since it does not seem
to try to maintain bakcwards compatibility to dstat at all, it should not
be the default replacement, instead it should be pcp, which, for existing
dstat users, provides essentially the same experience.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#1034771: generate_firmware_patterns failed: 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257

[Daniel Leidert]

Package: simple-cdd
Version: 0.6.9
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

With debian-cd 3.2.0, simple-cdd fails to create an installer image with the
following errors:

2023-04-24 03:07:41 ERROR build/debian-cd exited with code 2
2023-04-24 03:07:41 ERROR Last 5 lines of standard error:
2023-04-24 03:07:41 ERROR build/debian-cd: + exit 0
2023-04-24 03:07:41 ERROR build/debian-cd: xorriso 1.5.4 : RockRidge filesystem 
manipulator, libburnia project.
2023-04-24 03:07:41 ERROR build/debian-cd: missing metadata file 
./tmp/mirror/dists/bullseye/main/dep11/Components-amd64.yml.gz at 
./tmp/debian-cd/tools/generate_firmware_patterns line 172.
2023-04-24 03:07:41 ERROR build/debian-cd: generate_firmware_patterns failed: 
512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257.
2023-04-24 03:07:41 ERROR build/debian-cd: make: *** [Makefile:487: 
image-trees] Error 2
2023-04-24 03:07:41 ERROR build/debian-cd exited with code 2, full log can be 
found in ./cdd/tmp/log/build-debian-cd

If I downgrade to debian-cdi 3.1.36, the build (a bullseye image) process
succeeds. The related build profile exports NONFREE, NONFREE_COMPONENTS, and
FORCE_FIRMWARE, and requires several firmware packages.

This might be worth fixing for Bookworm.

Regards, Daniel


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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.36
ii  lsb-release 12.0-1
ii  python3 3.11.2-1+b1
ii  python3-simple-cdd  0.6.9
ii  reprepro5.3.1-1
ii  rsync   3.2.7-1
ii  wget1.21.3-1+b2

Versions of packages simple-cdd recommends:
ii  dose-distcheck  7.0.0-1+b2

Versions of packages simple-cdd suggests:
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-5

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmRF2OAACgkQS80FZ8KW
0F2Awg/8DIJ4G7pr3rWCRbp+AZwtvJxPB459QjSR8fJ7FeRBA8OBcHtlhCzAtiHF
tQjjQRGyepbte2l0lpVVXEgzF5RWmovuHJ8T/QZWWd86MsBL0NSCt4vszCWhZ5pb
oQin7j+evt4gKx6noUQfQWgPfiwEwCSb6XBkvVv/oq2VY3mPl6AjbQIGd87NwjuV
ZtoyO+ywxW8LloI/AgA7iirStfu0xG28DCflzJZMnvJh4Ejj4RfxgkdvyAVn78PX
jlTPtaiUnC6E/XH9S0sGEK8uX6/eamOFoqPfjNWwxXtQ0mAUucvn7HiqGg+0K+aV
Up9gznKC3UP4FQMDjDl2C875IDVIeLaTrWN43KJQ+DH2okTmzM2lbusNw76n1eXg
oBJj+tjGsgtprJBw4YncR2fijS3MaSbotyY10H3jFTol91NxLx6Q5sXBi+RDgpm6
VvAAdHDNdy6i5idOfRUiGOpqk74WRMYxU3eFvWqARnHEcSv/iTHxXIeUdRONqbrX
atFcIEIpjNwPyxySsxHzaKO/wSkcfquUflNG0adQ4wcuf1jOY/HrrpS9SotP5WDR
uTnrRDS42V/K5ggpvB6Qozp1/zawch0dtd7+KRQWg3luiFNdDvjlJayBd+PFlQKb
qcWppktTZdQVOAkZTuGK9Xacd6flt8e8VeKW3jtUn/7PBRvRU8Y=
=59sG
-END PGP SIGNATURE-

Bug#1034737: yggdrasil: yggdrasilctl getSelf doesn't report version number

[John Goerzen]

Thank you!  Nice detective work there.

- John

On Sat, Apr 22 2023, Andres Salomon wrote:

> Control: tags -1 patch
>
> On Sat, Apr 22 2023 at 11:16:26 PM -04:00:00, Andres Salomon
>  wrote:
>>
>> However, I can't for the life of me figure out how to tell dh-golang
>> to actually pass that to the Go compiler. *shrug*
>>
>
> Here we go. This patch allows both `yggdrasil --version` and
> `yggdrasilctl getself` to report the current version.

Bug#1034770: mariadb-server-10.5: Fix for MDEV-29988 (part of 10.5.19) needs to be in stable

[Xan Charbonnet]

Package: mariadb-server-10.5
Version: 1:10.5.18-0+deb11u1
Severity: important
X-Debbugs-Cc: x...@charbonnet.com, t...@security.debian.org

Dear maintainer,

The update in bullseye from 10.5.15 to 10.5.18 on December 4, 2022 contained a
major performance problem for some workloads.  It causes my DNS server running
PowerDNS with a MariaDB backend to run out of memory.

This was reported in Debian Bug 1027337:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027337
and fixed by putting 10.5.19 into unstable.

However, I (and presumably others?) run stable for my DNS servers, and I'm
still stuck on 10.5.15.

If anything could be done I would appreciate it.  Thanks.



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

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

Versions of packages mariadb-server-10.5 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.77
ii  galera-4  26.4.11-0+deb11u1
ii  gawk  1:5.1.0-1
ii  iproute2  5.10.0-4
ii  libc6 2.31-13+deb11u5
ii  libdbi-perl   1.643-3+b1
ii  libpam0g  1.4.0-9+deb11u1
ii  libssl1.1 1.1.1n-0+deb11u4
ii  libstdc++610.2.1-6
ii  lsb-base  11.1.0
ii  lsof  4.93.2+dfsg-1.1
ii  mariadb-client-10.5   1:10.5.18-0+deb11u1
ii  mariadb-common1:10.5.18-0+deb11u1
ii  mariadb-server-core-10.5  1:10.5.18-0+deb11u1
ii  passwd1:4.8.1-1
ii  perl  5.32.1-4+deb11u2
ii  procps2:3.3.17-5
ii  psmisc23.4-2
ii  rsync 3.2.3-4+deb11u1
ii  socat 1.7.4.1-3
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

Versions of packages mariadb-server-10.5 recommends:
ii  libhtml-template-perl  2.97-1.1

Versions of packages mariadb-server-10.5 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-2
pn  mariadb-test   
pn  netcat-openbsd 

-- debconf-show failed

Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.

[Peter Green]

Package: singular
Version: 1:4.3.1-p3+ds-1
Severity: serious
Justification: rc-policy - "Packages must be buildable within the same release"

singular build-depends on python3-brial. python3-brial recently added a
dependency on python3-sage making it uninstallable on many architectures.
As a result singular can no longer be built on those architectures.

I had a look at the build log and grepped the source tree and could find
no evidence of singular actually using brial. I also was able to
successfully build the package locally without python3-brial installed.

So I think the appropriate course of action would be to remove the
build-dependency. If I get no response I will likely NMU this next
weekend, but I'd really like a second opinion if possible.

See also: bugs 1033878 and 1034443

Bug#1034768: linux-image-5.10.0-21-amd64: NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out

[js1]

Package: src:linux
Version: 5.10.162-1
Severity: normal
X-Debbugs-Cc: sujiannm...@gmail.com

Dear Maintainer,

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

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

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


-- Package-specific info:
** Version:
Linux version 5.10.0-21-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.162-1 (2023-01-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-21-amd64 
root=UUID=27876db4-6b63-4db1-b0bd-b8c9522ced14 ro

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[   26.265660] audit: type=1400 audit(1679921400.164:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="tcpdump" pid=461 
comm="apparmor_parser"
[   26.308246] audit: type=1400 audit(1679921400.204:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/ntpd" pid=463 
comm="apparmor_parser"
[   30.225547] r8169 :01:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8106e-1.fw
[   30.230353] RTL8208 Fast Ethernet r8169-0-100:00: attached PHY driver 
[RTL8208 Fast Ethernet] (mii_bus:phy_addr=r8169-0-100:00, irq=IGNORE)
[   30.527170] r8169 :01:00.0 enp1s0: Link is Down
[   32.076792] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow 
control rx/tx
[   32.221136] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   32.224262] Bluetooth: BNEP filters: protocol multicast
[   32.227404] Bluetooth: BNEP socket layer initialized
[   32.419527] NET: Registered protocol family 38
[   33.724858] tun: Universal TUN/TAP device driver, 1.6
[   36.251853] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for 
information.
[   36.254248] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld 
. All Rights Reserved.
[386650.559790] device enp1s0 entered promiscuous mode
[386655.161113] device enp1s0 left promiscuous mode
[422399.653397] perf: interrupt took too long (2514 > 2500), lowering 
kernel.perf_event_max_sample_rate to 79500
[441927.500514] FS-Cache: Loaded
[441927.554843] Key type dns_resolver registered
[441927.746254] FS-Cache: Netfs 'cifs' registered for caching
[441927.766221] Key type cifs.spnego registered
[441927.766289] Key type cifs.idmap registered
[441927.766802] CIFS: Attempting to mount //10.23.21.100/My Pictures
[441927.766904] CIFS: No dialect specified on mount. Default has changed to a 
more secure dialect, SMB2.1 or later (e.g. SMB3.1.1), from CIFS (SMB1). To use 
the less secure SMB1 dialect to access old servers which do not support 
SMB3.1.1 (or even SMB3 or SMB2.1) specify vers=1.0 on mount.
[474605.542758] device tun0 entered promiscuous mode
[474775.233455] device tun0 left promiscuous mode
[474788.768056] device enp1s0 entered promiscuous mode
[474967.369262] device enp1s0 left promiscuous mode
[528327.619042] CIFS: Attempting to mount //10.23.21.101/D
[621779.265374] perf: interrupt took too long (3147 > 3142), lowering 
kernel.perf_event_max_sample_rate to 63500
[1046726.784764] CIFS: Attempting to mount //10.23.21.100/My Pictures
[1133127.741290] CIFS: Attempting to mount //10.23.21.101/D
[1651527.282550] CIFS: Attempting to mount //10.23.21.100/My Pictures
[1737927.543896] CIFS: Attempting to mount //10.23.21.101/D
[1766994.946441] device enp1s0 entered promiscuous mode
[1767216.942432] device enp1s0 left promiscuous mode
[1767240.277558] device enp1s0 entered promiscuous mode
[1775760.579738] device enp1s0 left promiscuous mode
[1857740.948093] r8169 :01:00.0 enp1s0: Link is Down
[1857742.560112] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow 
control rx/tx
[1857809.037350] [ cut here ]
[1857809.037512] NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
[1857809.037673] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:467 
dev_watchdog+0x260/0x270
[1857809.037820] Modules linked in: md4 sha512_ssse3 sha512_generic nls_utf8 
cifs libarc4 dns_resolver fscache libdes wireguard curve25519_x86_64 
libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel 
libcurve25519_generic libchacha tun cmac algif_hash algif_skcipher af_alg bnep 
nft_chain_nat xt_MASQUERADE nf_nat nft_counter xt_tcpudp xt_state xt_conntrack 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables libcrc32c 
crc32c_generic nfnetlink amdgpu nls_ascii nls_cp437 vfat fat gpu_sched uvcvideo 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev 
rtsx_usb_ms mc memstick snd_hda_codec_realtek snd_hda_codec_generic 
ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg soundwire_intel 
soundwire_generic_allocation snd_soc_core btusb btrtl btbcm btintel 
snd_compress bluetooth soundwire_cadence snd_hda_codec 

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

[David Hedlund]

On 2023-04-23 18:44, Jonathan McDowell wrote:

On Sun, Apr 23, 2023 at 01:39:51PM +0200, David Hedlund wrote:

On 2023-04-23 13:04, Jonathan McDowell wrote:

On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote:

On 2023-04-21 19:00, Jonathan McDowell wrote:

On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:

Package: retroarch-assets
Version: 1.3.6+git20160731+dfsg1-2

Open the attached Debian_11_Stable.png screenshot. As you can see, these
icons are missing:


...

This issue has been fixed in:

Debian 11 Testing (see attached screenshot)
Package: retroarch
Version: 1.14.0+dfsg-1
Package: retroarch-assets
Version: 1.7.6+git20221024+dfsg-2

Yes, that's expected. The retroarch-assets package in bullseye was
extremely dated and this has been corrected for bookworm.


Thanks. This bug is marked as solved, why aren't these two PNG files going
to be added to the stable retroarch-assets package?

Debian generally doesn't update packages in the stable release unless
there's a security issue or a serious functionality issue. While it
might be a minor fix here it's also primarily a cosmetic issue.


Thanks. Personally, I think the lack of these icons in this stable package
release make it look unstable, because it's on the main interface. Don't you
agree?

I don't agree this is a critical enough bug to roll out to stable (bullseye),
even if we weren't so close to releasing bookworm. retroarch in bullseye
is not in great shape, but I believe I have resolved that for bookworm.

J.


I respect your decision, J.


I filed this issue: https://github.com/libretro/RetroArch/issues/15210 
-- Should I close it or merge it to Debian?


I'll close it if the "Update Assets" entry has been removed from the 
retroarch package in Debian.

Bug#1034747: systemd-journal-gatewayd flood log with entries from microhttpd

[Michael Biebl]

Am 23.04.23 um 10:18 schrieb phoenix...@t-online.de:

I run Debian 11 on a Raspberry Pi 4, but the same problem occurs on 
Debian 11 running on a amd64 machine.


Can you try with the backport version as well [1]


[1] https://packages.debian.org/source/stable-backports/systemd



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000793: bind9-dnsutils: dig command fails with "`fd > STDERR_FILENO' failed" when run from a XFCE4 desktop applet

[Cesar Enrique Garcia Dabo]

This turned out to be a bug in xfce4-genmon-plugin. For the record, this 
is the bug report:


https://gitlab.xfce.org/panel-plugins/xfce4-genmon-plugin/-/issues/19

And this is the patch:

https://gitlab.xfce.org/cquike/xfce4-genmon-plugin/-/merge_requests/1

This is included in xfce4-genmon-plugin 4.2.0 released recently 
(https://docs.xfce.org/panel-plugins/xfce4-genmon-plugin/start#latest_release).

Bug#831413: Similar to 1000793?

[Cesar Enrique Garcia Dabo]

Hi,

it looks to me as this is a similar symptom to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000793, since it is 
also related to standard input.


If so, then the fix has been merged: 
https://gitlab.xfce.org/cquike/xfce4-genmon-plugin/-/merge_requests/1


The fix is part of the recent release 4.2.0 
(https://docs.xfce.org/panel-plugins/xfce4-genmon-plugin/start#latest_release), 
so it would be great to get that fixed for bookworm.

Bug#1034767: cryptsetup: askpass goes to 100% CPU utilisation when it's terminal HUPs

[Christoph Anton Mitterer]

Package: cryptsetup
Version: 2:2.6.1-4
Severity: normal


Hey.

When askpass is running (and waiting) while it's terminal gets somehow
killed/HUPed/etc. ... it's process goes to 100% utilisation from where
it doesn't seem to recover anymore.

Reproducer:
Shell 1:
echo $$
/lib/cryptsetup/askpass foo
Shell 2:
kill -HUP 


Haven't tried it yet, but perhaps my waiting-forever PR at:
   https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/26
might fix that ;-)


Cheers,
Chris.

Bug#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Ben Hutchings]

On Mon, 2023-04-24 at 07:00 +1000, Rod Webster wrote:

[...]
> I have not kept my .config files as PC's have been reformatted so many
> times. However, my kernels and the steps used to build them are available
> in my google drive. They will show what we have changed. Here is the link
> to the 6.1.0-rt5 kernel
> https://drive.google.com/drive/folders/1jGc6AUYKMPvsSOdWRdvhWeDX1P96tsFQ?usp=sharing
> 
> I
> will redo this for the final 6.1 kernel and share the config to get in step
> with Debian Bookworm's current state.
[...]
> 

I'm not spotting any particular interesting differences in the config
there, unfortunately.  And from your earlier messages, it sounded like
you didn't have so much of a problem with the Debian packages for Linux
6.1 anyway.

If you still have custom packages of Linux 5.10 where the r8169
driver's network latency is OK, I would like to see those.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1034766: systemd-udevd[…]: Failed to call EVIOCSKEYCODE with scan code 0xc022d/0xc022e, and key code 103/108: Invalid argument

[Al Ma]

Package: systemd
Version: 247.3-7+deb11u2
Control: affects -1 + udev
In the output of journalctl -b we see
…
Apr 23 22:30:59 AnonymizedMachineName kernel: usb 1-10: new low-speed USB 
device number 4 using xhci_hcd
Apr 23 22:30:59 AnonymizedMachineName kernel: sr 5:0:0:0: Attached scsi CD-ROM 
sr1
Apr 23 22:30:59 AnonymizedMachineName kernel: usb 1-10: New USB device found, 
idVendor=045e, idProduct=00db, bcdDevice= 1.73
Apr 23 22:30:59 AnonymizedMachineName kernel: usb 1-10: New USB device strings: 
Mfr=1, Product=2, SerialNumber=0
Apr 23 22:30:59 AnonymizedMachineName kernel: usb 1-10: Product: Natural® 
Ergonomic Keyboard 4000
Apr 23 22:30:59 AnonymizedMachineName kernel: usb 1-10: Manufacturer: Microsoft
Apr 23 22:30:59 AnonymizedMachineName kernel: input: Microsoft Natural® 
Ergonomic Keyboard 4000 as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/0003:045E:00DB.0003/input/input1
Apr 23 22:30:59 AnonymizedMachineName kernel: microsoft 0003:045E:00DB.0003: 
input,hidraw2: USB HID v1.11 Keyboard [Microsoft Natural® Ergonomic Keyboard 
4000] on usb-:00:14.0-10/input0
Apr 23 22:30:59 AnonymizedMachineName kernel: input: Microsoft Natural® 
Ergonomic Keyboard 4000 as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10:1.1/0003:045E:00DB.0004/input/input2
Apr 23 22:30:59 AnonymizedMachineName kernel: usb 1-11: new high-speed USB 
device number 5 using xhci_hcd
Apr 23 22:30:59 AnonymizedMachineName kernel: microsoft 0003:045E:00DB.0004: 
input,hidraw3: USB HID v1.11 Device [Microsoft Natural® Ergonomic Keyboard 
4000] on usb-:00:14.0-10/input1
…
Apr 23 22:30:59 AnonymizedMachineName systemd[1]: Finished Flush Journal to 
Persistent Storage.
Apr 23 22:30:59 AnonymizedMachineName kernel: input: USB2.0 FHD UVC WebCam: 
USB2.0 F as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11.4/1-11.4.2/1-11.4.2:1.0/input/input8
Apr 23 22:30:59 AnonymizedMachineName kernel: uvcvideo: Found UVC 1.50 device 
USB2.0 FHD UVC WebCam (04f2:b612)
Apr 23 22:30:59 AnonymizedMachineName systemd-udevd[408]: ethtool: 
autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 23 22:30:59 AnonymizedMachineName kernel: input: USB2.0 FHD UVC WebCam: IR 
Camer as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11.4/1-11.4.2/1-11.4.2:1.2/input/input9
Apr 23 22:30:59 AnonymizedMachineName kernel: usbcore: registered new interface 
driver uvcvideo
Apr 23 22:30:59 AnonymizedMachineName kernel: USB Video Class driver (1.1.1)
Apr 23 22:30:59 AnonymizedMachineName systemd-udevd[397]: event1: Failed to 
call EVIOCSKEYCODE with scan code 0xc022d, and key code 103: Invalid argument
Apr 23 22:30:59 AnonymizedMachineName systemd-udevd[397]: event1: Failed to 
call EVIOCSKEYCODE with scan code 0xc022e, and key code 108: Invalid argument
The keyboard “Microsoft® Natural® Ergonomic Keyboard 4000 v1.0” is attached to 
the machine in question. As for the scan codes, we indeed see
###
# Microsoft
###
# Microsoft Natural Ergonomic Keyboard 4000
evdev:input:b0003v045Ep00DB*
KEYBOARD_KEY_c022d=up # zoomin
KEYBOARD_KEY_c022e=down # zoomout
in /lib/udev/hwdb.d/60-keyboard.hwdb .
In plain English, what do the two messages „systemd-udevd[…]: Failed to call 
EVIOCSKEYCODE with scan code …, and key code …: Invalid argument“ tell us, and 
how should this worry us? (By the way, the way I zoom in or out using keyboard, 
say, in Mozilla Firefox, is via Ctrl++ and Ctrl+-. The middle slide key of the 
keyboard moves the contents of the window or the cursor up and down.)

Bug#1020246: Not an active maintainer, but

[Iustin Pop]

AFAIK, both armel and armfh are low-powered/"slow" arches, but i386 is
surprising. Maybe due to memory limits?

I wonder if tests shouldn't simply be restricted to amd64, arm64, ppc64el and
s390x? This should give it enough of architecture heterogeneity to catch
any problems that simply do not appear on amd64 (mainstream arch) (yes,
I've been bitten by this in one package of mine).

This would be a cheap fix (one entry in the control file). Thoughts?
(Anyone?) It seems this bug is the only one that prevents it from
entering testing (and it's a leaf package).

regards,
iustin

Bug#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Rod Webster]

Thanks. I think I have tried most (if not all) released kernels (from 5.10
to present day 6.1) I adopted Bullseye a few weeks before it became the
stable branch. Bookworm supports the Realtek R8125 NIC which I noted this
week is also using the R8169 driver with the latest Bullseye kernel. I
believe it is also affected by this issue but have not benchmarked it.

Linuxcnc was accepted into SID back in January 2022 and I started using the
non-free sid versions from that time. I then started using Bookworm/Testing
once linuxcnc was accepted into it.

I have personally tested on 4-5 USFF PC's ranging from intel J1900, J4115
and i3 CPU's. All used Realtek network hardware and  all were affected. All
were initially using the R8169 driver. Many Other Linuxcnc users have
reported the issue. All of these had hardware covered by Realteks official
R8168 driver. All of these benefited from installing the Debian R8168-dkms
driver.

Compiling the RT kernel is not new to linuxcnc users as it was required up
until Debian first released linux-image-rt packages. All we have ever
needed to do was to patch the code and make a single change in
menuconfig/xconfig to select the fully preemptible kernel and compile. I
learnt how to build kernel debs when Bookworm was on the 6.0 kernel and
built a 6.1-rt5 version which I shared publicly with other users via Google
Drive. This resolved issues for a lot of users. Another user recently
reported substantial improvement in latency with the 6.3 kernel so two of
us built and tested it with outstanding and near identical results for both
overall latency and network latency.

I have not kept my .config files as PC's have been reformatted so many
times. However, my kernels and the steps used to build them are available
in my google drive. They will show what we have changed. Here is the link
to the 6.1.0-rt5 kernel
https://drive.google.com/drive/folders/1jGc6AUYKMPvsSOdWRdvhWeDX1P96tsFQ?usp=sharing

I
will redo this for the final 6.1 kernel and share the config to get in step
with Debian Bookworm's current state.

Note we use Linuxcnc's latency testing tools to measure latency but
cyclictest produces similar observable results.
Unfortunately, we don't have any portable method to test network latency.
Our hardware reports the maximum time to read and write to it in CPU timer
ticks.
This command may give some insight but the other device would need to be on
a dedicated point to point ethernet connection (no hub or router)
sudo chrt 99 ping -i .001 -q 10.10.10.10

I hope this covers your questions.

Rod Webster

VMN®

www.vmn.com.au

Ph: 1300 896 832

Mob: +61 435 765 611




On Sun, 23 Apr 2023 at 23:43, Ben Hutchings  wrote:

> Control: retitle -1 linux-image-rt-amd64: High network latency with r8169
> driver
> Control: tag -1 moreinfo
>
> On Sun, 2023-04-23 at 09:14 +1000, Rod Webster wrote:
> > Thanks.
> > That is really a disappointing response because:
> > 1. Hardware selected based on  Debian  4.x kernels in Buster that
> operated
> > safely was broken by the 5.10 and above kernels in Bullseye and Bookworm
> > 2. You ask us to report a bug if the R8168-dkms package has to be used so
> > we did, now no interest is shown in actioning the report
> > 3. It does not address the excessive latency in the Debian RT kernel that
> > is not present in the upstream version at kernel.org
> > 4. It has taken a lot of work from a lot of Linuxcnc users to identify
> the
> > issues before this report could be made.
> >
> > The official ISO release of Linuxcnc is still based on Buster so not many
> > users ventured into the later kernels hence the delay in reporting.
> > Linuxcnc is packaged in Bookworm so the issue will be more prevalent
> moving
> > forward.
> >
> > I was told by a Debian developer involved in linuxcnc that if there were
> > issues affecting us, they would be fixed. I hope something comes of this.
> [...]
>
> I'm not dismissing this bug report, but I wanted to first make it clear
> that we cannot take any responsibility for safety-critical
> applications.
>
> As to the general issue of network latency:
> - What was the latest Debian packaged kernel version you used?
> - You've said that installing r8168-dkms resolves the issue. Am I
> correct in assuming that when you ran the Debian packaged kernel, the
> r8169 driver was used?
> - Have you tested on any other machines with different network
> hardware?
> - We don't make a lot of changes to the kernel source, but our build
> configuration will be different. Can you confirm exactly which upstream
> release you've tested, and provide the configuration (.config) file you
> used?
>
> Ben.
>
> --
> Ben Hutchings
> It's easier to fight for one's principles than to live up to them.
>

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular

[Peter Michael Green]

On 23/04/2023 21:07, Paul Gevers wrote:
Can you point to a discussion where we might draw the conclusion that 
this is common practice or consensus? I *personally* [no hats on] find 
that distinction a bit weird although I can see how we would come to 
it and also why.
No, I can't point to a discussion. I vaugely remember hearing it from a 
more experianced developer (possiblly a release team member) on IRC 
years ago.


But it has been consistent with how I have seen bugs handled in practice 
over my years in Debian.


It's also consistent with how britney behaves or at least did until very 
recently. My understanging is that britney performs architecture checks 
on all release architectures where a package is built for arch specific 
packages, but only performs architecture checks on a small subset of 
architectures (when I first started with Debian it was i386 only, I 
think now it's amd64 and arm64, maybe also i386) for arch all packages.


I have vauge reccollections of a document descirbing the different 
behaviour for arch all packages in britney as a "hack", so I presume 
this is something that started as a hack and then just became the status 
quo. If you wanted your package in testing and it was arch specific you 
had to make sure it was installable on all architectures where it was 
built, but if it was arch all you did not (and often could not).


I have seen people ask the release team for exceptions when their 
arch-all package is not installable on one of the architectures where 
arch all packages are checked but I can't recall ever seeing such a 
request for an arch-specific package.


And when I look at 
https://qa.debian.org/dose/debcheck/testing_main/index.html this seems 
to back up my observation.


That does leave the question of how brial with this bug migrated to 
testing in the first place. Whether there was a recent intentional 
change in britney, whether there was a bug/glitch, or whether it was 
forced in (and if-so who forced it).


This seems to be your real issue. Why file the bug against 
python3-brial?
When an issue involving multiple packages shows up on my radar, I 
tend to start by filing a bug with the package where a fix could 
potentially have the most impact and cc the maintainers of other 
packages that are involved.


Ack. And I agree with this approach. However, we are *also* in the 
Hard Freeze, so RC bugs reports have more severe results if not 
treated swiftly.
Agreed, given where we are in the Freeze, enough time has passed to file 
a rc bug against singular with an expression of intent to NMU. I'll do 
that later today.


I also hereby announce that I intend to NMU brial if I don't get a 
maintainer response soon.
(I am assuming Paul is posting as a release team member and not as a 
maintainer of the package, if that is wrong please speak up)

Bug#1034765: [Firmware Bug]: APEI: Invalid physical address in GAR [0x0/64/0/4/0]

[Al Ma]

Package: linux-image-5.10.0-21-amd64
Version: 5.10.162-1
Severity: wishlist
In the output of journalctl -b we see this:
…
Apr 23 22:30:59 AnonymizedMachineName kernel: efifb: Truecolor: size=8:8:8:8, 
shift=24:16:8:0
Apr 23 22:30:59 AnonymizedMachineName kernel: Console: switching to colour 
frame buffer device 128x48
Apr 23 22:30:59 AnonymizedMachineName kernel: fb0: EFI VGA frame buffer device
Apr 23 22:30:59 AnonymizedMachineName kernel: intel_idle: MWAIT substates: 
0x2020
Apr 23 22:30:59 AnonymizedMachineName kernel: Monitor-Mwait will be used to 
enter C-1 state
Apr 23 22:30:59 AnonymizedMachineName kernel: Monitor-Mwait will be used to 
enter C-2 state
Apr 23 22:30:59 AnonymizedMachineName kernel: ACPI: \_SB_.SCK0.CP00: Found 2 
idle states
Apr 23 22:30:59 AnonymizedMachineName kernel: intel_idle: v0.5.1 model 0x55
Apr 23 22:30:59 AnonymizedMachineName kernel: intel_idle: Local APIC timer is 
reliable in all C-states
Apr 23 22:30:59 AnonymizedMachineName kernel: [Firmware Bug]: APEI: Invalid 
physical address in GAR [0x0/64/0/4/0]
What does the last message “[Firmware Bug]: APEI: Invalid physical address in 
GAR [0x0/64/0/4/0]” tell us in plain English, except that there's a firmware 
bug? Which firmware exactly is involved? Is there a real fault anywhere? The 
machine is stationary, has WS C422 PRO SE motherboard with Intel(R) Xeon(R) 
W-2235 CPU @ 3.80GHz, and runs Debian stable with a few updated packages from 
snapshots.
Cheers,
Alma

Bug#1034236: mpd: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Florian Schlichting]

Control: severity ! important

On Fri, Apr 21, 2023 at 03:24:25PM +0200, Geoffroy Youri Berret wrote:
> Le 11/04/2023 à 23:52, Florian Schlichting a écrit :
> > […]
> > I think we should take a step back and think about how a freshly
> > installed mpd package should look like. I think it may actually be a
> > feature that the system mpd.service is not enabled and started on a
> > fresh install. On most desktop/laptop machines, leaving the system
> > service off and enabling the user service is probably the better thing
> > to do. How long has dh-installsystemd been disregarding our unit files?
> > We may want to add --no-enable when we apply that patch.
> > 
> > So I think in the case of mpd, perhaps nothing is severely broken
> > currently and this bug doesn't require fixing for bookworm. Instead, it
> > can perhaps be downgraded and fixed with the next regular upload, after
> > the release?
> 
> I agree, this is the best thing to do.
> The package is not broken enough to require a fix, it's actually not really
> broken it's only not enabling/starting system unit which, I believe, is not
> the main use of MPD anyway.

Since we agree, I don't think we need to wait any further and can get
ourselves off the release-critical bugs list right away :-)

Let's fix this first thing in trixie, and also add an override for
dh_installsystemd --no-enable

Florian

Bug#1034764: unblock: spf-engine/3.0.4-1

[Scott Kitterman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package spf-engine

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
The only change this revision includes is an update to the logcheck
regex to account for logging changes in Bookworm.  For users that use
logcheck, not having this fix in would somewhat defeat the purpose of
using it.

[ Impact ]
Logcheck doesn't work correctly for this package.

[ Tests ]
This was tested by the submitter.  See #1034727 [1] for details.  I
don't use logcheck, so I didn't test it myself.  This is how I've
generally handled these submissions in the past and it's always worked
out fine.

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

[ Risks ]
Change is trivial.  The only potential risk is that logcheck will
continue not to work correctly in some way.  I don't think there's any
real risk of making things worse.

[ 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 testing

[ Other info ]
The updated package is uploaded to Experimental.  If approved, the
Unstable upload would have an additional d/changelog entry, but no other
changes.

unblock spf-engine/3.0.4-1
diff -Nru spf-engine-3.0.4/debian/changelog spf-engine-3.0.4/debian/changelog
--- spf-engine-3.0.4/debian/changelog   2023-04-09 09:24:11.0 -0400
+++ spf-engine-3.0.4/debian/changelog   2023-04-23 15:49:01.0 -0400
@@ -1,3 +1,11 @@
+spf-engine (3.0.4-2~exp1) experimental; urgency=medium
+
+  * Update logcheck rule for postfix-policyd-spf-python to account for logging
+changes in Bookworm (Closes: #1034727)
+- Thanks to Mathias Gibbens for the report and the fix
+
+ -- Scott Kitterman   Sun, 23 Apr 2023 15:49:01 -0400
+
 spf-engine (3.0.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru spf-engine-3.0.4/debian/logcheck/postfix-policyd-spf-python 
spf-engine-3.0.4/debian/logcheck/postfix-policyd-spf-python
--- spf-engine-3.0.4/debian/logcheck/postfix-policyd-spf-python 2022-11-30 
10:25:57.0 -0500
+++ spf-engine-3.0.4/debian/logcheck/postfix-policyd-spf-python 2023-04-23 
15:48:48.0 -0400
@@ -1,2 +1 @@
-+^\w{3} [ :0-9]{11} [._[:alnum:]-]+ policyd-spf\[[0-9]+\]: 
(Pass|Neutral|None|Softfail|Fail|Temperror|Permerror); 
identity=(helo|mailfrom); client-ip=[0-9a-f.:]+; helo=.*; envelope-from=.*; 
receiver=
-
+^(\w{3} [ :[:digit:]]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ 
policyd-spf\[[0-9]+\]:( :)? prepend Received-SPF: 
(Pass|Neutral|None|Softfail|Fail|Temperror|Permerror) \((helo|mailfrom)\) 
identity=(helo|mailfrom); client-ip=[0-9a-f.:]+; helo=.*; envelope-from=.*; 
receiver=

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular

[Paul Gevers]

Hi Peter,

On 23-04-2023 21:24, Peter Michael Green wrote:

That works in some cases, but it's a bad option here for two reasons.

1. It would create a build-dependency loop between brial and sagemath.


Which isn't practical problem as long as there is a proper build profile 
involved, right? But given point 2, I think both the point and this is 
argument are moot.


2. It would mean that other binary packages built from the brial source 
package had their architecture list unnecessarily limited.


Aha, I missed that detail. There are more arch: binaries build 
by src:brial.



 > Technically I even think that this isn't a bug in python3-brial.

One of the criteria (indeed the first on the list) for grave is "makes 
the package in question unusable or mostly so". I consider that a 
package that cannot be installed is unusable.


If I follow that reasoning than about 850 arch:all binaries also have RC 
bugs: https://qa.debian.org/dose/debcheck/testing_main/1682226002/some.html


My understanding has always been that for source packages that build 
multiple binaries, the test of "is the package unusable" is applied for 
each binary package individually and that for packages that are built 
separately for multiple architectures (not arch all packages) it is 
applied for each architecture individually. I don't think that is 
officially written down anywhere though.


Can you point to a discussion where we might draw the conclusion that 
this is common practice or consensus? I *personally* [no hats on] find 
that distinction a bit weird although I can see how we would come to it 
and also why.



This seems to be your real issue. Why file the bug against python3-brial?
When an issue involving multiple packages shows up on my radar, I tend 
to start by filing a bug with the package where a fix could potentially 
have the most impact and cc the maintainers of other packages that are 
involved.


Ack. And I agree with this approach. However, we are *also* in the Hard 
Freeze, so RC bugs reports have more severe results if not treated swiftly.


If the maintainer of brial came back and said that the fix for bug 
1033878 was wrong, and that python3-brial could in-fact be made usable 
on all architectures then there would.


[missing words?] Yes, sure. However, looking at the stack trace in that 
bug, I agree that the dependency is the most logical solution. Ensuring 
python3-brial to be useful without that dependency will require patching 
the code by the looks of it.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034763: unblock: grub2/2.06-12

[Steve McIntyre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package grub2

We've pulled in some really important fixes for GRUB, that I think are
important and should definitely be part of the bookworm release:

 * Fix an issue where a logical volume rename would lead grub to fail to
   boot (#987008)
 * Add a final patch needed to make arm64 Secure Boot work (#1020769)
 * Backport some upstream patches to fix probing of LUKS2 devices
   (#1028301), add luks2 to the signed EFI images (#1001248)
 * Add debconf logic to control os-prober use (#1031594, #1012865,
   #1025698). This dovetails with an update to grub-installer in d-i.

I've also added a small but important change to config_item() in the
postinst, which makes things much more robust. Without this,
grub-install on systems with Xen installed can fail unexpectedly.

And there's a trivial change to not warn about os-prober if it's not
installed (#1033657).

The os-prober fixes are a major change that I think we need for
bookworm. The default has changed in GRUB upstream, and this will
cause a lot of user confusion (on new installations particularly)
where they're trying to do dual-boot.

I'm asking for an unblock *now* for these changes, so that people can
review them. The os-prober update includes a new debconf template that
we'll want translations for (and hence another/more grub upload(s)
before release), but of course they should be ~zero-risk at that point.

  [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 testing

unblock grub2/2.06-12
unblock grub-efi-amd64-signed/1+2.06+12
unblock grub-efi-arm64-signed/1+2.06+12
unblock grub-efi-ia32-signed/1+2.06+12

debdiff attached, filtering out noise from *.po updates.


grub2_2.06-12.debdiff.gz
Description: application/gzip

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular

[Peter Michael Green]

On 23/04/2023 19:19, Paul Gevers wrote:


I claim this is wrong. Would python3-sage one day build on more 
architectures, this list would need manual updating. Instead of 
hard-coding the list, it's better to ensure the build doesn't happen 
or fails on architectures where python3-sage is not available. E.g. by 
build-depending (ideally with a build profile indicating that the 
*build* itself works; I suggest ). 


That works in some cases, but it's a bad option here for two reasons.

1. It would create a build-dependency loop between brial and sagemath.
2. It would mean that other binary packages built from the brial source 
package had their architecture list unnecessarily limited.


> Technically I even think that this isn't a bug in python3-brial.

One of the criteria (indeed the first on the list) for grave is "makes 
the package in question unusable or mostly so". I consider that a 
package that cannot be installed is unusable.


My understanding has always been that for source packages that build 
multiple binaries, the test of "is the package unusable" is applied for 
each binary package individually and that for packages that are built 
separately for multiple architectures (not arch all packages) it is 
applied for each architecture individually. I don't think that is 
officially written down anywhere though.



This seems to be your real issue. Why file the bug against python3-brial?
When an issue involving multiple packages shows up on my radar, I tend 
to start by filing a bug with the package where a fix could potentially 
have the most impact and cc the maintainers of other packages that are 
involved.


If the maintainer of brial came back and said that the fix for bug 
1033878 was wrong, and that python3-brial could in-fact be made usable 
on all architectures then there would.


On the other hand whatever changes were made in singular we would still 
have unusable python3-brial packages.


So I started out with a bug against python3-brial.

Bug#1034762: unblock: nheko/0.11.3-2

[Hubert Chathi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package nheko

Reason:

nheko 0.11.3-1 has a dependency on gstreamer1.0-vaapi.  This package is
not actually required, and reportedly causes crashes in some
environments.  nheko 0.11.3-2 downgrades this dependency to a Suggests.
No other changes are made.

Since the only change is in the dependencies, risk should be minimal.

debdiff:

diff -Nru nheko-0.11.3/debian/changelog nheko-0.11.3/debian/changelog
--- nheko-0.11.3/debian/changelog   2023-02-22 21:07:56.0 -0500
+++ nheko-0.11.3/debian/changelog   2023-03-23 12:17:45.0 -0400
@@ -1,3 +1,9 @@
+nheko (0.11.3-2) unstable; urgency=medium
+
+  * debian/control: Downgrade gstreamer1.0-vaapi to a Suggests.
+
+ -- Hubert Chathi   Thu, 23 Mar 2023 12:17:45 -0400
+
 nheko (0.11.3-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru nheko-0.11.3/debian/control nheko-0.11.3/debian/control
--- nheko-0.11.3/debian/control 2023-02-21 20:06:44.0 -0500
+++ nheko-0.11.3/debian/control 2023-03-23 11:50:20.0 -0400
@@ -54,12 +54,12 @@
  qml-module-qtquick-particles2,
  qml-module-qtquick-window2,
  gstreamer1.0-nice,
- gstreamer1.0-qt5,
- gstreamer1.0-vaapi
+ gstreamer1.0-qt5
 Recommends: ca-certificates,
 fonts-noto-color-emoji,
 kimageformat-plugins,
 qt5-image-formats-plugins
+Suggests: gstreamer1.0-vaapi
 Description: desktop IM client for the Matrix protocol
  Nheko is a Qt-based chat client for Matrix, an open, federated communications
  protocol.  The motivation behind the project is to provide a native desktop

Bug#1034761: ruby-webpacker missing package.json cause rails new to fail

[watson]

Package:ruby-webpacker
Version: 5.4.3-2

rails new aaabbbccc aborts, complaining:
No such file or directory @ rb_sysopen -
/usr/share/rubygems-integration/all/gems/webpacker-5.4.3/lib/install/../../package.json
/home/*/aaabbbccc/bin/rails:5:in `'
/home/*/aaabbbccc/bin/spring:10:in `require'
/home/*/aaabbbccc/bin/spring:10:in `block in '
/home/*/aaabbbccc/bin/spring:7:in `'
Tasks: TOP => app:template

Copying package.json from the source package to
/usr/share/rubygems-integration/all/gems/webpacker-5.4.3/ seems to fix.

Full steps to reproduce:
$ debootstrap --arch=amd64 --variant=minbase sid /sssiiiddd
$ for i in proc dev dev/shm dev/pts ; do mount --bind /$i /sssiiiddd/$i 
; done

$ chroot /sssiiiddd
$ apt --no-install-deps install rails yarnpkg
$ useradd --create-home happy
$ su -l happy
$ rails new --trace aaabbbccc |& tee stdout (attachment)
(copy package.json from source package)
$ rails new --trace dddeeefff |& tee with_package_json (attachment)

This is my second submit to the same bug. I think my last attempt gets 
lost in mail transmit. If I cause duplicate entries or other trouble, I 
give my apology.  create  
  create  README.md
  create  Rakefile
  create  .ruby-version
  create  config.ru
  create  .gitignore
  create  .gitattributes
  create  Gemfile
 run  git init from "."
  create  package.json
  create  app
  create  app/assets/config/manifest.js
  create  app/assets/stylesheets/application.css
  create  app/channels/application_cable/channel.rb
  create  app/channels/application_cable/connection.rb
  create  app/controllers/application_controller.rb
  create  app/helpers/application_helper.rb
  create  app/javascript/channels/consumer.js
  create  app/javascript/channels/index.js
  create  app/javascript/packs/application.js
  create  app/jobs/application_job.rb
  create  app/mailers/application_mailer.rb
  create  app/models/application_record.rb
  create  app/views/layouts/application.html.erb
  create  app/views/layouts/mailer.html.erb
  create  app/views/layouts/mailer.text.erb
  create  app/assets/images
  create  app/assets/images/.keep
  create  app/controllers/concerns/.keep
  create  app/models/concerns/.keep
  create  bin
  create  bin/rails
  create  bin/rake
  create  bin/setup
  create  bin/spring
  create  bin/yarn
  create  config
  create  config/routes.rb
  create  config/application.rb
  create  config/environment.rb
  create  config/cable.yml
  create  config/puma.rb
  create  config/spring.rb
  create  config/storage.yml
  create  config/environments
  create  config/environments/development.rb
  create  config/environments/production.rb
  create  config/environments/test.rb
  create  config/initializers
  create  config/initializers/application_controller_renderer.rb
  create  config/initializers/assets.rb
  create  config/initializers/backtrace_silencers.rb
  create  config/initializers/content_security_policy.rb
  create  config/initializers/cookies_serializer.rb
  create  config/initializers/cors.rb
  create  config/initializers/filter_parameter_logging.rb
  create  config/initializers/inflections.rb
  create  config/initializers/mime_types.rb
  create  config/initializers/new_framework_defaults_6_1.rb
  create  config/initializers/permissions_policy.rb
  create  config/initializers/wrap_parameters.rb
  create  config/locales
  create  config/locales/en.yml
  create  config/master.key
  append  .gitignore
  create  config/boot.rb
  create  config/database.yml
  create  db
  create  db/seeds.rb
  create  lib
  create  lib/tasks
  create  lib/tasks/.keep
  create  lib/assets
  create  lib/assets/.keep
  create  log
  create  log/.keep
  create  public
  create  public/404.html
  create  public/422.html
  create  public/500.html
  create  public/apple-touch-icon-precomposed.png
  create  public/apple-touch-icon.png
  create  public/favicon.ico
  create  public/robots.txt
  create  tmp
  create  tmp/.keep
  create  tmp/pids
  create  tmp/pids/.keep
  create  tmp/cache
  create  tmp/cache/assets
  create  vendor
  create  vendor/.keep
  create  test/fixtures/files
  create  test/fixtures/files/.keep
  create  test/controllers
  create  test/controllers/.keep
  create  test/mailers
  create  test/mailers/.keep
  create  test/models
  create  test/models/.keep
  create  test/helpers
  create  test/helpers/.keep
  create  test/integration
  create  test/integration/.keep
  create  test/channels/application_cable/connection_test.rb
  create  test/test_helper.rb
  create  test/system
  create  test/system/.keep
  create  

Bug#1000050: modsecurity: depends on obsolete pcre3 library

[Tobias Frost]

Source: modsecurity
Followup-For: Bug #150
Control: fixed -1 3.0.8-2
Control: severity -1 serious
Control: affects -1 libnginx-mod-http-modsecurity
Control: close -1


Fixed/Close:
The upload 3.0.8-2 switched to pcre2, so this bug is technically fixed.
(The bug can be also closed)

Raising the severity:
Unfortunatly this upload largely FTBFS on most archs… (#1034760)

TIL that nginx in testing has updated already to pcre2, and this makes
modsecurity in testing incompatible (broken). Therefore this bug is RC now, as
it still affects testing.

Marking this bug as affecting libnginx-mod-http-modsecurity.

-- 
tobi

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable, breaks building of singular

[Paul Gevers]

Hi Peter, all,

On Sat, 15 Apr 2023 15:33:04 +0100 Peter Green  wrote:

* The architecture list of python3-brial needs to be limited to architectures
   where python3-sage is available.


I claim this is wrong. Would python3-sage one day build on more 
architectures, this list would need manual updating. Instead of 
hard-coding the list, it's better to ensure the build doesn't happen or 
fails on architectures where python3-sage is not available. E.g. by 
build-depending (ideally with a build profile indicating that the 
*build* itself works; I suggest ). Technically I even think 
that this isn't a bug in python3-brial. Assuming the dependency is real 
and unavoidable, than being uninstallable is bug in the depending on 
package, but not an RC one.



* The build-dependency of singular on python3-brial needs to be either
   removed or limited to architectures where python3-sage is available


This seems to be your real issue. Why file the bug against python3-brial?


* Removal of the old python3-brial packages needs to be requested.


Assuming something is done to prevent the binaries from building, then 
yes, obviously. However, why would we consider arch: 
uninstallable packages different than arch:all uninstallable packages if 
the reason is the same: depending on a binary that's not build on some 
arch. Do our tools have different expectations for them?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034760: modsecurity: FTBFS on all archs except amd64/i386

[Tobias Frost]

Source: modsecurity
Version: 3.0.8-2
Severity: serious
Tags: ftbfs patch
Justification: FTBFS

Hi,

as you already know, modsecurity FTBFS on almost all archs, except amd64 and 
i386:
It fails to find libpcre2 on those archs.

It seems that the shipped pcre2.m4 is broken: When using pkg-config to locate 
the library,
it uses
  PCRE2_POSSIBLE_LIB_NAMES="pcre2 pcre2-8"
however, the pkg-config name is *lib*pcre2(-8)

On amd64/i386 some fallback mechansism eventually finds the library, this is 
why it works
there. Possibly, on Debian, only pkg-config should be used?

(Another observation: It finds the headers on the broken archs, so it seems it 
does not use
pkg-config for determining the include paths? This seems dangerous, if 
pkg-config is mixed with
some heurisitcs?)

The attached patch makes autoconf happy at least on arm64, likely also on the 
other archs:

Index: modsecurity-3.0.8/build/pcre2.m4
===
--- modsecurity-3.0.8.orig/build/pcre2.m4
+++ modsecurity-3.0.8/build/pcre2.m4
@@ -4,7 +4,7 @@ dnl CHECK_PCRE2(ACTION-IF-FOUND [, ACTIO
 AC_DEFUN([PROG_PCRE2], [
 
 # Possible names for the pcre2 library/package (pkg-config)
-PCRE2_POSSIBLE_LIB_NAMES="pcre2 pcre2-8"
+PCRE2_POSSIBLE_LIB_NAMES="libpcre2 libpcre2-8"
 
 # Possible extensions for the library
 PCRE2_POSSIBLE_EXTENSIONS="so so0 la sl dll dylib so.0.0.0"

-- 
tobi

Bug#1033811: closed by Graham Inggs (Re: Bug#1033811: unblock: mariadb/1:10.11.2-2)

[Otto Kekäläinen]

Thanks for the review. Can you please also look at commit log as it has
additional information and also commit-by-commit is easier to read?

I would argue that all the work done in Feb-March was targeted for Bookworm
and appropriate and low risk. As you can see in the Salsa project all
improvement type work was left pending to be merged after Bookworm is out.

Anyway, thanks for the feedback, I will review these and revert a subset of
bugfixes done in Feb-March and upload 1:10.11.2-4.

(I already reverted one commit Paul mentioned in 10.11.2-3 upload.)

Otto

Bug#1034759: unblock: scanssh/2.0-4.3

[Bastian Germann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: scan...@packages.debian.org
Control: affects -1 + src:scanssh

Please unblock package scanssh.

[ Reason ]
RC bug #1034699 is open in bookworm.

[ Impact ]
Package will be auto-removed if it is not unblocked.

[ Risks ]
None. Only source format and copyright changes.

ublock scanssh/2.0-4.3diff -Nru scanssh-2.0/debian/changelog scanssh-2.0/debian/changelog
--- scanssh-2.0/debian/changelog2023-04-22 01:10:31.0 +0200
+++ scanssh-2.0/debian/changelog2023-04-22 00:25:45.0 +0200
@@ -1,3 +1,12 @@
+scanssh (2.0-4.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing licenses, convert to machine-readable format. (Closes: 
#1034699)
+  * Convert to source format 3.0 (quilt).
+  * d/watch: Update to version 3 (no changes).
+
+ -- Bastian Germann   Sat, 22 Apr 2023 00:25:45 +0200
+
 scanssh (2.0-4.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru scanssh-2.0/debian/copyright scanssh-2.0/debian/copyright
--- scanssh-2.0/debian/copyright2023-04-22 01:10:31.0 +0200
+++ scanssh-2.0/debian/copyright2023-04-22 00:25:45.0 +0200
@@ -1,15 +1,124 @@
-This package was debianized by Rene Weber  on
-Wed, 28 Feb 2001 18:47:28 -0500.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Rene Weber  on
+ Wed, 28 Feb 2001 18:47:28 -0500.
+Source:
+ It was downloaded from http://www.monkey.org/~provos/scanssh/
+Upstream-Contact:
+ Niels Provos 
 
-It was downloaded from http://www.monkey.org/~provos/scanssh/
+Files: *
+Copyright:
+ Copyright 2000-2004 Niels Provos 
+ All rights reserved.
+License: BSD-3-clause
 
-Upstream Author: Niels Provos
+Files: strlcpy.c strlcat.c
+Copyright:
+ Copyright (c) 1998 Todd C. Miller 
+ All rights reserved.
+License: BSD-3-clause
 
+Files: xmalloc.*
 Copyright:
+ Copyright (c) 1995 Tatu Ylonen , Espoo, Finland
+All rights reserved
+License: xmalloc
+ As far as I am concerned, the code I have written for this software
+ can be used freely for any purpose.  Any derived versions of this
+ software must be clearly marked as such, and if the derived work is
+ incompatible with the protocol description in the RFC file, it must be
+ called by a name other than "ssh" or "Secure Shell".
+
+Files: err.c compat/err.h strsep.c
+Copyright:
+ Copyright (c) 2000 Dug Song 
+ Copyright (c) 1991, 1993
+ The Regents of the University of California.  All rights reserved.
+License: BSD-3-clause
+Comment: The UC California allows to remove the 3rd clause of BSD-4-clause.
+
+Files: inet_aton.c
+Copyright:
+ Copyright (c) 1983, 1990, 1993
+ The Regents of the University of California.  All rights reserved.
+ Portions Copyright (c) 1993 by Digital Equipment Corporation.
+License: BSD-3-clause and MIT-DEC
+Comment: The UC California allows to remove the 3rd clause of BSD-4-clause.
+
+Files: inet_pton.c
+Copyright:
+ Copyright (c) 1996 by Internet Software Consortium.
+License: ISC
+ Permission to use, copy, modify, and distribute this software for any
+ purpose with or without fee is hereby granted, provided that the above
+ copyright notice and this permission notice appear in all copies.
+ .
+ THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
+ ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
+ OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
+ CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+ DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+ PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+ ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ SOFTWARE.
+
+Files: atomicio.c
+Copyright:
+ Copyright (c) 1999 Theo de Raadt
+ All rights reserved.
+License: BSD-2-clause
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions
+ are met:
+ 1. Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+ 2. Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+ .
+ THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 

Bug#1033231: postgrey: Postgrey (testing) won't start after installation

[Tim Boneko]

Package: postgrey
Version: 1.37-1.1
Followup-For: Bug #1033231

Dear maintainer,
I just installed postgrey on my mail server and it won't start (canceled start 
after 5 attempts).
/var/log/syslog states that 

ERROR: --unix or --inet must be specified

among other things like missing config files and users.

Outcome of my installation is that postgrey won't start unless i add options to 
/lib/systemd/system/postgrey.service.
My expectation was that i install this little package and have it up and 
running in seconds.

Thanks for providing this package nevertheless!
Cheers,

tim


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

Kernel: Linux 6.2.11 (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)

Versions of packages postgrey depends on:
ii  adduser  3.132
ii  init-system-helpers  1.65.2
ii  libberkeleydb-perl   0.64-2+b1
ii  libnet-dns-perl  1.36-1
ii  libnet-server-perl   2.013-2
ii  libnetaddr-ip-perl   4.079+dfsg-2+b1
ii  perl 5.36.0-7
ii  ucf  3.0043+nmu1

Versions of packages postgrey recommends:
ii  libnet-rblclient-perl  0.5-4
ii  libparse-syslog-perl   1.10-4
ii  postfix3.7.4-2

postgrey suggests no packages.

-- no debconf information

Bug#1034409: Boot from removable media path fails after changing secure boot validation because MOK Manager is not found

[Steve McIntyre]

Control: reassign -1 src:grub2

On Fri, Apr 14, 2023 at 04:35:22PM +0200, Pascal Hambourg wrote:
>Package: src:shim
>Version: 15.7-1
>
>Dear maintainer,
>
>I have an HP Elitebook 2570p laptop with flawed UEFI firmware which ignores
>EFI boot variables in NVRAM for booting and boots from the removable media
>path by default. So I installed a copy of GRUB in the removable media path
>with:
>
># grub-install --force-extra-removable
>
>Secure boot is enabled in UEFI/BIOS settings.
>For a test I wanted to disable secure boot validation in shim with:
>
># mokutil --disable-validation
>
>and rebooted. At boot, the following error is displayed:
>
>  Failed to open mmx64.efi - Not Found
>  Failed to load image: Not Found
>  Failed to start MOK Manager : Not Found
>
>and the laptop shut down after a couple of seconds.
>Indeed /EFI/BOOT on the EFI system partition contains only BOOTX64.EFI,
>grubx64.efi and fbx64.efi.
>Now the same happens every time I reboot from the removable media path,
>either on the hard disk or on a USB drive with a Debian installation image.
>
>Not sure which software is to blame here.
>
>- grub-install which does not install the MOK manager into the removable
>media path ?

This is definitely a bug in grub-install, yeah. Re-assigning it
accordingly.

>- shim which shuts down the laptop instead of just ignoring the validation
>change request if it does not find the MOK Manager ?

shim is designed to be paranoid (here and elsewhere). There isn't a
*good* choice for it here IMHO. :-/

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Bug#985150: systemd-udevd[…]: could not read from '/sys/module/acpi_cpufreq/initstate': No such device

[Al Ma]

Thanks. I understand. As packages generally depend on each other on a large 
scale, I posted the version of systemd simply to indicate that the bug is not 
as old as it might seem from the prior report of Anonimno.
If the bug re-emerges (I don't wish to roll back my last update unless 
necessary for other reasons), I'll reopen the report.
Cheers,
Alma

Bug#1022073: pam-u2f: new upstream release 1.2.1 available

[Adam]

Is there any process I can initiate to get the upstream versions into 
Debian while the package maintainer (nicoo) is away?


It's been 9 months since I submitted the merge request to go from 1.1.0 
to 1.1.1. I'd like to do more to help, but I'm not sure how to proceed.


-- Adam Hacker

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

[Jonathan McDowell]

On Sun, Apr 23, 2023 at 01:39:51PM +0200, David Hedlund wrote:
> On 2023-04-23 13:04, Jonathan McDowell wrote:
> > On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote:
> > > On 2023-04-21 19:00, Jonathan McDowell wrote:
> > > > On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:
> > > > > Package: retroarch-assets
> > > > > Version: 1.3.6+git20160731+dfsg1-2
> > > > > 
> > > > > Open the attached Debian_11_Stable.png screenshot. As you can see, 
> > > > > these
> > > > > icons are missing:
> > > > > 
> > > > ...
> > > > > This issue has been fixed in:
> > > > > 
> > > > > Debian 11 Testing (see attached screenshot)
> > > > > Package: retroarch
> > > > > Version: 1.14.0+dfsg-1
> > > > > Package: retroarch-assets
> > > > > Version: 1.7.6+git20221024+dfsg-2
> > > > Yes, that's expected. The retroarch-assets package in bullseye was
> > > > extremely dated and this has been corrected for bookworm.
> > > > 
> > > Thanks. This bug is marked as solved, why aren't these two PNG files going
> > > to be added to the stable retroarch-assets package?
> > Debian generally doesn't update packages in the stable release unless
> > there's a security issue or a serious functionality issue. While it
> > might be a minor fix here it's also primarily a cosmetic issue.
> > 
> Thanks. Personally, I think the lack of these icons in this stable package
> release make it look unstable, because it's on the main interface. Don't you
> agree?

I don't agree this is a critical enough bug to roll out to stable (bullseye),
even if we weren't so close to releasing bookworm. retroarch in bullseye
is not in great shape, but I believe I have resolved that for bookworm.

J.

-- 
/-\ | Let's not go there.
|@/  Debian GNU/Linux Developer |
\-  |

Bug#1010385: task-spooler: Please update to newer upstream

[Felix Stupp]

Hi,

the dev of that GitHub project explained that it's a fork because the original 
one "is unmaintained".
However, he started the fork before the last version of the original upstream, 
1.0.2, was released.
I think it most probably deserves its own package at first.

On Sun, 29 May 2022 11:52:32 +0300 Alexander Inyukhin  
wrote:
> Hi!
> 
> Is it really a new upstream?
> Original one is often inaccessible but still valid, I guess.
> Latest version there is 1.0.2 with minor changes.
> 
> 
> On Sat, Apr 30, 2022 at 02:49:56AM -0500, John Goerzen wrote:
> > Package: task-spooler
> > Version: 1.0.1+dfsg1-1
> > Severity: wishlist
> > 
> > https://github.com/justanhduc/task-spooler seems to be the new home, and it 
> > up to 1.3.x.
> > 
> > Thanks!
> 
> 

Bug#1034758: x2goserver-common: fails to purge - command (deluser|delgroup) in postrm not found

[Patrice Duroux]

Package: x2goserver-common
Version: 4.1.0.3-6
Severity: wishlist

Hi,

During a test with piuparts I noticed your package failed to purge due to a
command not found. According to policy 7.2 you cannot rely on the depends being
available during purge, only the essential packages are available for sure.

The fix should be easy: your package is using adduser/addgroup or
deluser/delgroup from the adduser package, which is only priority important.
Using useradd/groupadd or userdel/groupdel from the passwd package (priority
required) should fix this problem.

There is ongoing discussion how to handle system users on package removal, see
https://bugs.debian.org/621833
Consensus seems to be not to remove system users (to avoid reusing user/group
IDs which could grant access to the wrong files) but to "lock" them (where
"locking"/"unlocking" is not yet precisely defined). Until that has been
decided it should be sufficient to have the postrm script ignore any errors
from deluser/delgroup:
   deluser/delgroup ... || true

Piuparts log is here:
https://piuparts.debian.org/sid/fail/x2goserver-common_4.1.0.3-6.log

Regards,
Patrice


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 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 x2goserver-common depends on:
ii  adduser  3.132

x2goserver-common recommends no packages.

x2goserver-common suggests no packages.

Bug#1034756: dpkg: please add support for riscv32

[Bo YU]

Package: dpkg
Version: 1.21.21
Severity: wishlist
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv32

Dear Maintainer,

Currently riscv32 has been supported upstream for a while[0] and people
can setup a riscv32 qemu with yocto[1], but it is time consuming.
There is no distro to support riscv32 AFAIK until now however I think
this will benefits users who want to setup riscv32 rootfs quickly if we
support this.

I thought the riscv32 has met the request[2] also.

Please let me know if there is any issue.

[0]: https://github.com/riscv-collab/riscv-gnu-toolchain#installation-linux
[1]: https://github.com/riscv/meta-riscv
[2]: 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F

-- 
Regards,
--
  Bo YU

From 2e254fb802635742bb81f2e0a776e87c71360e1f Mon Sep 17 00:00:00 2001
From: Bo YU 
Date: Sun, 23 Apr 2023 22:22:47 +0800
Subject: [PATCH] add support for riscv32

Signed-off-by: Bo YU 
---
 data/cputable | 1 +
 1 file changed, 1 insertion(+)

diff --git a/data/cputable b/data/cputable
index 7b1ee2c58..7c2c1c1c8 100644
--- a/data/cputable
+++ b/data/cputable
@@ -45,6 +45,7 @@ powerpc		powerpc		(powerpc|ppc)		32	big
 powerpcel	powerpcle	powerpcle		32	little
 ppc64		powerpc64	(powerpc|ppc)64		64	big
 ppc64el		powerpc64le	powerpc64le		64	little
+riscv32		riscv32		riscv32			32	little
 riscv64		riscv64		riscv64			64	little
 s390		s390		s390			32	big
 s390x		s390x		s390x			64	big
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1033811: closed by Graham Inggs (Re: Bug#1033811: unblock: mariadb/1:10.11.2-2)

[Graham Inggs]

Hi Otto

On Thu, 20 Apr 2023 at 16:44, Otto Kekäläinen  wrote:
> Can you please list the commits you do not accept so I can revert them and 
> upload a 10.11.2-3 which you are then willing to approve?

I've had a look at some of the bugs closed in the changelog of
10.11.2-2; #866751, #1029165, #1032047, #1032861 and #1032860, and
none of these seem to be of severity: important or release critical.
I suggest reverting to 10.11.2-1 and then only cherry-picking the
fixes from 10.11.2-2 that are appropriate for the current freeze
stage, i.e. release critical bugs, severity: important bugs, and
translation updates and documentation fixes, etc.  Be sure to make it
clear in your unblock request why the changes are important, e.g.
Reason, Impact, Tests, Risks, as per the template generated by
reportbug.

Regards
Graham

Bug#1034755: x2gothinclient-common: about .postinst and .postrm scripts

[Patrice Duroux]

Package: x2gothinclient-common
Version: 1.5.0.1-8.1
Severity: wishlist

Dear Maintainer,

To be consistent, regarding the entire content of the .postinst script,
I think it should use addgroup in line 49 (compared to line 30 and the
use of adduser and not useradd everywhere else).

Also during a test with piuparts I noticed your package failed to purge due
to a command not found. According to policy 7.2 you cannot rely on the
depends being available during purge, only the essential packages are
available for sure.

The fix should be easy: your package is using adduser/addgroup or
deluser/delgroup
from the adduser package, which is only priority important. Using
useradd/groupadd
or userdel/groupdel from the passwd package (priority required) should fix this
problem.

There is ongoing discussion how to handle system users/groups on package
removal, see https://bugs.debian.org/621833
Consensus seems to be not to remove system users/groups (to avoid reusing
UIDs/GIDs
which could grant access to the wrong files) but to "lock" them (where
"locking"/"unlocking" is not yet precisely defined). Until that has
been decided it should be sufficient to have the postrm script ignore
any errors from deluser/delgroup:
   deluser/delgroup ... || true

The piupart log is here:
https://piuparts.debian.org/sid/fail/x2gothinclient-common_1.5.0.1-8.1.log

Thanks,
Patrice


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 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 x2gothinclient-common depends on:
ii  adduser 3.132
ii  x2goclient  4.1.2.2-2+b1

x2gothinclient-common recommends no packages.

x2gothinclient-common suggests no packages.

Bug#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Diederik de Haas]

On Sunday, 23 April 2023 15:43:01 CEST Ben Hutchings wrote:
> Can you confirm exactly which upstream release you've tested

The initial bug report (which didn't end up on debian-kernel ML) had:

On Tue, 18 Apr 2023 12:12:58 +1000 Rod Webster  wrote:
> We note that RT latency/jitter has significantly improved in the 6.x kernels
> and is better again with the 6.3 kernel compiled from kernel.org sources
> where latency/jitter is on a par with the 4.x kernels found in Buster.

So I'm guess upstream master (so 6.3-rc7 f.e.).

me@pc:~/dev/kernel.org/linux$ git log --oneline v6.1..HEAD -- 
drivers/net/ethernet/realtek/r8169*
33189f0a94b9 r8169: fix RTL8168H and RTL8107E rx crc error
ce870af39558 r8169: reset bus if NIC isn't accessible after tx timeout
a99da46ac01a Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
80c0576ef179 r8169: disable ASPM in case of tx timeout
2ea26b4de6f4 Revert "r8169: disable detection of chip version 36"
bb41c13c05c2 r8169: fix dmar pte write access is not set error
ad425666a1f0 r8169: move rtl_wol_enable_rx() and rtl_prepare_power_down()
42f66a44d837 r8169: enable GRO software interrupt coalescing per default
4b6c6065fca1 r8169: use tp_to_dev instead of open code
eca485d22165 drivers: net: convert to boolean for the mac_managed_pm flag

It looks like some are now part of 6.1.25 too, but not all.

It also looks like realtek is now actually contributing to the upstream kernel
instead of periodically dumping their own code on the internet :-)

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

Bug#1034754: ITP: libdbix-class-toposort-perl -- topological sorting functionality to DBIx::Class

[mtj]

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

* Package name: libdbix-class-toposort-perl
  Version : 0.06
  Upstream Author : Rob Kinyon 
* URL : https://metacpan.org/release/libdbix-class-toposort-perl
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : topological sorting functionality to DBIx::Class

DBIx::Class::TopoSort adds a method to DBIx::Class::Schema which returns the
full list of sources (similar to "sources" in DBIx::Class::Schema) in
topological-sorted order.

A topological sort of the tables returns the list of tables such that any table
with a foreign key relationship appears after any table it has a foreign key
relationship to.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1034753: RM: paxctl -- RoM; obsolete

[GCS]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:paxctl

Hi FTP Masters,

Please remove src:paxctl as it's an old, outdated project in our
archives. I've no intentions to keep it in Sid nor ship it with
Bookworm.

Thanks,
Laszlo/GCS

Bug#1034550: r8168-dkms: Excessive network latency with PREEMPT_RT kernel without the R8168-dkms driver

[Ben Hutchings]

Control: retitle -1 linux-image-rt-amd64: High network latency with r8169 driver
Control: tag -1 moreinfo

On Sun, 2023-04-23 at 09:14 +1000, Rod Webster wrote:
> Thanks.
> That is really a disappointing response because:
> 1. Hardware selected based on  Debian  4.x kernels in Buster that operated
> safely was broken by the 5.10 and above kernels in Bullseye and Bookworm
> 2. You ask us to report a bug if the R8168-dkms package has to be used so
> we did, now no interest is shown in actioning the report
> 3. It does not address the excessive latency in the Debian RT kernel that
> is not present in the upstream version at kernel.org
> 4. It has taken a lot of work from a lot of Linuxcnc users to identify the
> issues before this report could be made.
> 
> The official ISO release of Linuxcnc is still based on Buster so not many
> users ventured into the later kernels hence the delay in reporting.
> Linuxcnc is packaged in Bookworm so the issue will be more prevalent moving
> forward.
> 
> I was told by a Debian developer involved in linuxcnc that if there were
> issues affecting us, they would be fixed. I hope something comes of this.
[...]

I'm not dismissing this bug report, but I wanted to first make it clear
that we cannot take any responsibility for safety-critical
applications.

As to the general issue of network latency:
- What was the latest Debian packaged kernel version you used?
- You've said that installing r8168-dkms resolves the issue. Am I
correct in assuming that when you ran the Debian packaged kernel, the
r8169 driver was used?
- Have you tested on any other machines with different network
hardware?
- We don't make a lot of changes to the kernel source, but our build
configuration will be different. Can you confirm exactly which upstream
release you've tested, and provide the configuration (.config) file you
used?

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1029976: libzen 0.4.38-1+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1029976 = 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: libzen
Version: 0.4.38-1+deb11u1

Explanation: fix null pointer dereference issue [CVE-2020-36646]

Bug#1034750:

[Holger Wansing]

Am 23. April 2023 14:09:59 MESZ schrieb Adam Baxter :
>I know this is the wrong way to do it, but d-i pkgsel/run_tasksel boolean 
>false in my preseed.cfg was the easiest way for me to fix it.
>
>Just the d-i netcfg/choose_interface select auto problem to go now.

You should provide your preseed file and of course the
syslog from the Installation (compressed), to allow debugging.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1034709: f3d: F3D default configuration files are not installed

[François Mazen]

Hi Mathieu,

> Since you rightly point that this will only be fixed with the new
> upstream version, I will only give information about F3D 2.0.0
>  (...)

Thanks for all the details, I'll update the next package version
accordingly.


Best Regards,

François




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

Bug#1034750:

[Adam Baxter]

I know this is the wrong way to do it, but d-i pkgsel/run_tasksel boolean false 
in my preseed.cfg was the easiest way for me to fix it.

Just the d-i netcfg/choose_interface select auto problem to go now.

This is possibly the wrong thread for it, IMO there needs to be a simple way to 
copy the SSH key/s provided by d-i network-console/authorized_keys_url to 
any/all created user accounts during installation, especially if I have d-i 
passwd/root-login boolean false set.

Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore

[Alf]

Here for completeness (just in case you want to dig into smplayer's vaapi 
issue):

$ vainfo
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.17 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 23.1.1 ()
vainfo: Supported profile and entrypoints
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileNone   : VAEntrypointStats
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointFEI
  VAProfileH264Main   : VAEntrypointEncSliceLP
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointFEI
  VAProfileH264High   : VAEntrypointEncSliceLP
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointVLD
  VAProfileJPEGBaseline   : VAEntrypointEncPicture
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointFEI
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
  VAProfileHEVCMain   : VAEntrypointVLD
  VAProfileHEVCMain   : VAEntrypointEncSlice
  VAProfileHEVCMain   : VAEntrypointFEI
  VAProfileHEVCMain   : VAEntrypointEncSliceLP
  VAProfileHEVCMain10 : VAEntrypointVLD
  VAProfileHEVCMain10 : VAEntrypointEncSlice
  VAProfileHEVCMain10 : VAEntrypointEncSliceLP
  VAProfileVP9Profile0: VAEntrypointVLD
  VAProfileVP9Profile0: VAEntrypointEncSliceLP
  VAProfileVP9Profile1: VAEntrypointVLD
  VAProfileVP9Profile1: VAEntrypointEncSliceLP
  VAProfileVP9Profile2: VAEntrypointVLD
  VAProfileVP9Profile2: VAEntrypointEncSliceLP
  VAProfileVP9Profile3: VAEntrypointVLD
  VAProfileVP9Profile3: VAEntrypointEncSliceLP
  VAProfileHEVCMain12 : VAEntrypointVLD
  VAProfileHEVCMain12 : VAEntrypointEncSlice
  VAProfileHEVCMain422_10 : VAEntrypointVLD
  VAProfileHEVCMain422_10 : VAEntrypointEncSlice
  VAProfileHEVCMain422_12 : VAEntrypointVLD
  VAProfileHEVCMain422_12 : VAEntrypointEncSlice
  VAProfileHEVCMain444: VAEntrypointVLD
  VAProfileHEVCMain444: VAEntrypointEncSliceLP
  VAProfileHEVCMain444_10 : VAEntrypointVLD
  VAProfileHEVCMain444_10 : VAEntrypointEncSliceLP
  VAProfileHEVCMain444_12 : VAEntrypointVLD
  VAProfileHEVCSccMain: VAEntrypointVLD
  VAProfileHEVCSccMain: VAEntrypointEncSliceLP
  VAProfileHEVCSccMain10  : VAEntrypointVLD
  VAProfileHEVCSccMain10  : VAEntrypointEncSliceLP
  VAProfileHEVCSccMain444 : VAEntrypointVLD
  VAProfileHEVCSccMain444 : VAEntrypointEncSliceLP
  VAProfileAV1Profile0: VAEntrypointVLD
  VAProfileHEVCSccMain444_10  : VAEntrypointVLD
  VAProfileHEVCSccMain444_10  : VAEntrypointEncSliceLP

Bug#1034752: embeds non-free headers

[Pierre Gruet]

Source: gluegen2
Version: 2.3.2-9
Severity: serious
Tags: fixed-in-experimental

Dear Maintainer,

Non-free header files are present in the source of gluegen2, see for instance
in make/stub_includes/jni/jni.h:
 *   Copyright 2006 Sun Microsystems, Inc. All rights reserved.
 *   SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

Removing these headers and using these of the jdk instead requires some extra
work in the rdep libjogl2-java, but it is done in experimental.

Best,

-- 
Pierre

Bug#1034751: python-xmlschema: accesses internet during build

[Sebastian Ramacher]

Source: python-xmlschema
Version: 1.10.0-5
Severity: serious
Justification: Policy §4.9

Policy §4.9 states: For packages in the main archive, required targets
must not attempt network access, except, via the loopback interface, to
services on the build host that have been started by the build.

Running "wget http://example.com; to check if network access is
available violates this rule. Furthermore, our buildds have network
access and thus this check succeeds and the package downloads files
during the build.

Cheers
-- 
Sebastian Ramacher

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

[David Hedlund]

On 2023-04-23 13:04, Jonathan McDowell wrote:

On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote:

On 2023-04-21 19:00, Jonathan McDowell wrote:

On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:

Package: retroarch-assets
Version: 1.3.6+git20160731+dfsg1-2

Open the attached Debian_11_Stable.png screenshot. As you can see, these
icons are missing:


...

This issue has been fixed in:

Debian 11 Testing (see attached screenshot)
Package: retroarch
Version: 1.14.0+dfsg-1
Package: retroarch-assets
Version: 1.7.6+git20221024+dfsg-2

Yes, that's expected. The retroarch-assets package in bullseye was
extremely dated and this has been corrected for bookworm.


Thanks. This bug is marked as solved, why aren't these two PNG files going
to be added to the stable retroarch-assets package?

Debian generally doesn't update packages in the stable release unless
there's a security issue or a serious functionality issue. While it
might be a minor fix here it's also primarily a cosmetic issue.

J.

Thanks. Personally, I think the lack of these icons in this stable 
package release make it look unstable, because it's on the main 
interface. Don't you agree?

Bug#1034736: bullseye-pu: package pev/0.81-3+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-04-22 at 22:52 -0300, David da Silva Polverari wrote:
> Package: release.debian.org
> Severity: important
> 

As noted (and already fixed) "normal" was the correct choice here.

> A buffer overflow vulnerability exists in Pev 0.81 via the pe_exports
> function from exports.c. The array offsets_to_Names is dynamically
> allocated on the stack using exp->NumberOfFunctions as its size.
> However, the loop uses exp->NumberOfNames to iterate over it and set
> its
> components value. Therefore, the loop code assumes that
> exp->NumberOfFunctions is greater than ordinal at each iteration.
> This
> can lead to arbitrary code execution.
> 

Please go ahead.

Regards,

Adam

Bug#1034714: bullseye-pu: package php-nyholm-psr7/1.3.2-2+deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-04-22 at 12:59 +0200, David Prévot wrote:
> Please note that this request is very similar to #1034713 for
> php-guzzlehttp-psr7/1.7.0-1+deb11u2 (even the CVE ID is the same).
> 
> [ Reason ]
> I’d like to fix an improper input validation [CVE-2023-29197]
> filed as #1034597. The security team reviewed this bug filed
> with a non-RC severity, so I assume they don’t expect to release
> a DSA for it (as for the other php-guzzlehttp-psr7 issue),
> anyway the team is X-D-Cc.
> 

Please go ahead.

Regards,

Adam

Bug#1034713: bullseye-pu: package php-guzzlehttp-psr7/1.7.0-1+deb11u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-04-22 at 12:17 +0200, David Prévot wrote:
> I’d like to fix an improper input validation [CVE-2023-29197]
> filed as #1034581. This is a follow up from [CVE-2022-24775]
> filed as #1008236 that was fixed via a previous point release.
> The security team filed those bugs with a non-RC severity, so
> I assume they don’t expect to release a DSA for it (as for the
> previous main issue), anyway the team is X-D-Cc.
> 

The Security Tracker agrees. Please go ahead.

Regards,

Adam

Bug#1028543: lutris: Application not shown in GNOME's application launcher without /usr/games in $PATH.

[Elliot Speck]

On Wed, 22 Feb 2023 16:10:03 -0800 Jaycee Santos 
 wrote:
> I still do not know why this happens, but I assume it is related to 
GDM's handling

> of wayland sessions.

I'm unsure we should even be using /usr/games. As far back as 2010 there 
was movement

to deprecate its use.

As far as I'm aware Debian is the only mainstream distribution that uses
/usr/games for anything anymore and - given the current state of the gaming
world with its deluge of always-online DRM - I can't imagine something 
like it

will be useful again.

Warm regards,

Arcayr

Bug#1034680: retroarch-assets: Missing icons (Favorites, and Netplay Rooms) for the default XMB theme, for Debian Stable (but solve in Testing, and Unstable)

[Jonathan McDowell]

On Fri, Apr 21, 2023 at 07:37:44PM +0200, David Hedlund wrote:
> On 2023-04-21 19:00, Jonathan McDowell wrote:
> > On Fri, Apr 21, 2023 at 03:33:00PM +0200, David Hedlund wrote:
> > > Package: retroarch-assets
> > > Version: 1.3.6+git20160731+dfsg1-2
> > > 
> > > Open the attached Debian_11_Stable.png screenshot. As you can see, these
> > > icons are missing:
> > > 
> > ...
> > > This issue has been fixed in:
> > > 
> > > Debian 11 Testing (see attached screenshot)
> > > Package: retroarch
> > > Version: 1.14.0+dfsg-1
> > > Package: retroarch-assets
> > > Version: 1.7.6+git20221024+dfsg-2
> > Yes, that's expected. The retroarch-assets package in bullseye was
> > extremely dated and this has been corrected for bookworm.
> > 
> Thanks. This bug is marked as solved, why aren't these two PNG files going
> to be added to the stable retroarch-assets package?

Debian generally doesn't update packages in the stable release unless
there's a security issue or a serious functionality issue. While it
might be a minor fix here it's also primarily a cosmetic issue.

J.

-- 
///\oo/\\\ There are no more bugs. ///\oo/\\\ ///\oo/\\\

Bug#1034750: installation-reports: Automated install worked, but installed full desktop environment

[Adam Baxter]

Package: installation-reports
Severity: minor
X-Debbugs-Cc: deb...@voltagex.org

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: debian-bookworm-DI-rc1-amd64-netinst.iso + custom grub.cfg
Date: 2023-04-23

Machine: Beelink U59 Pro
Partitions: 

Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   8038444   0   8038444   0% /dev
tmpfs  tmpfs  16147241604   1613120   1% /run
/dev/sda2  ext4 489634808 4980640 459708660   2% /
tmpfs  tmpfs  8073612   0   8073612   0% /dev/shm
tmpfs  tmpfs 5120  12  5108   1% /run/lock
/dev/sda1  vfat5232445948517296   2% /boot/efi
tmpfs  tmpfs  1614720  64   1614656   1% /run/user/113
tmpfs  tmpfs  1614720  52   1614668   1% /run/user/1000

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[OE]
Configure network:  [OE]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[OE]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:
The installer says it tries to automatically select the network card with an 
active link, but I am not sure this worked correctly.
The machine has 2 Ethernet ports plus wifi, all were detected correctly but the 
installer selected the wireless interface as the default.

(and d-i netcfg/choose_interface select auto didn't seem to work).

A full desktop environment was installed without prompting but I think this is 
a side effect 
of using priority=critical as a boot parameter. 


Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230401"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux BeeMovie 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1 
(2023-03-19) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4e24]
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 
JasperLake [UHD Graphics] [8086:4e61] (rev 01)
lspci -knn: DeviceName: Onboard - Video
lspci -knn: Subsystem: Intel Corporation Device [8086:2212]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Dynamic Tuning service [8086:4e03]
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:4ded] 
(rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:4def] 
(rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO 
I2C Host Controller [8086:4de8] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:15.1 Serial bus controller [0c80]: Intel Corporation Serial IO 
I2C Host Controller [8086:4de9] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:15.2 Serial bus controller [0c80]: Intel Corporation Device 
[8086:4dea] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:15.3 Serial bus controller [0c80]: Intel Corporation Device 
[8086:4deb] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 
Management Engine Interface [8086:4de0] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:17.0 SATA controller [0106]: Intel 

Bug#1026060: Bug: #1026060 -- mpv: dvb playback does not work anymore

[Alf]

Hi Nicholas and Thomas,

I have to correct my comment about "smplayer" -> got it working, my fault!

I probably choose the wrong wording when saying "What now does not work: 
smplayer".
It stopped working at the same time when mpv was upgradet to v0.35.* and 
stopped working.
Correct I should have said "smplayer did not start working after update to 
mpv_0.35.1-4".

But that's also not true - it now works as before after switching the settings 
under
"General" -> "Video" -> "Output driver"
from "vaapi" to "libmpv" - that's all!

I only use smplayer because of the comfortable way to zap between different 
channels.

So with using "libmpv" I have definitely higher CPU-load (~12%) compared to mpv 
using
vaapi (~1-2%)., but that's no issue for me.

For completeness here the full output when playing with mpv:

$ mpv dvb://ARD
[dvbin] Tuning to channel "ARD"...
[dvbin] dvb_tune DVB-C ANNEX A Freq: 33000
[ffmpeg] NULL: non-existing PPS 0 referenced
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: non-existing PPS 0 referenced
[ffmpeg/video] h264: decode_slice_header error
[ffmpeg/video] h264: no frame!
 (+) Video --vid=1 (h264 1280x720 50.000fps)
 (+) Audio --aid=1 (ac3 2ch 48000Hz)
File tags:
 Title: ARD
[ffmpeg/video] h264: co located POCs unavailable
[ffmpeg/video] h264: co located POCs unavailable
Using hardware decoding (vaapi).
AO: [pipewire] 48000Hz stereo 2ch floatp
VO: [gpu] 1280x720 vaapi[nv12]
AV: 00:02:42 / 00:02:45 (98%) A-V:  0.000 Cache: 3.3s/4MB

Exiting... (Quit)

Info regarding my GPU:

Alder Lake CPU Core i5-12400 Firmware für UHD-Grafik 730:

# dmesg | grep firmware
[0.994151] i915 :00:02.0: firmware: direct-loading firmware 
i915/adls_dmc_ver2_01.bin
[0.994647] i915 :00:02.0: [drm] Finished loading DMC firmware 
i915/adls_dmc_ver2_01.bin (v2.1)
[0.999702] i915 :00:02.0: firmware: direct-loading firmware 
i915/tgl_guc_70.bin
[0.999828] i915 :00:02.0: firmware: direct-loading firmware 
i915/tgl_huc.bin
[1.086191] i915 :00:02.0: [drm] GuC firmware i915/tgl_guc_70.bin 
version 70.5.1
[1.086192] i915 :00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 
7.9.3


If you need more information to enable/improve vaapi for this GPU please let me 
know.

Regards,
Alf


Am 23.04.23 um 01:21 schrieb Nicholas D Steeves:

Dear Thomas and Alf,

Thank you for confirming that this fix for DVB support works as it
should.

Thomas, if you have a few minutes of free time, would you please review
the rest of this email, and consider verifying whether or not
mpv_0.35.1-4 introduces a regression in smplayer?  I hypothesise that
mpv_0.35.1-3 works no better, but we need to be sure that mpv_0.35.1-4
doesn't cause any harm...if it does then smplayer will need a fix too
(maybe just a rebuild).

Alf  writes:


   (+) Video --vid=1 (h264 1280x720 50.000fps)

Ok, h264.


   (+) Audio --aid=1 (mp2 2ch 48000Hz)
File tags:
   Title: arte HD(Unitymedia)
[ffmpeg/video] h264: co located POCs unavailable

Here is a thread about what this message means:
   https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg80351.html


Using hardware decoding (vaapi).
AO: [pipewire] 48000Hz stereo 2ch s16p
VO: [gpu] 1280x720 vaapi[nv12]

"nv12" is a colour space and pixel format thing.  Yes, I had to look
this up, because I've never seen "nv12" before.
https://wiki.videolan.org/YUV

Bug#1034731: bullseye-pu: package pev/0.81-3

[Adam D. Barratt]

On Sat, 2023-04-22 at 21:31 -0300, David da Silva Polverari wrote:
> Closing this bug, as it was opened the wrong way. I will open it
> again
> with the proper metadata.
> 

This is a little confusing. So far as I can see, the only difference is
that you made the second report "severity: important".

That could have been changed without opening a new report, but in any
case "normal" was correct.

Regards,

Adam

Bug#1034749: ITP: session-manager-plugin -- This plugin helps you to use the AWS Command Line Interface (AWS CLI) to start and end sessions to your managed instances

[Damian Szuberski]

Package: wnpp
Severity: wishlist
Owner: Damian Szuberski 

* Package name: session-manager-plugin
  Version : 1.2.463.0-1
  Upstream Author : Amazon Web Services
* URL : https://github.com/aws/session-manager-plugin
* License : Apache-2.0
  Programming Lang: Go
  Description : This plugin helps you to use the AWS Command Line
Interface (AWS CLI) to start and end sessions to your managed instances

 Session Manager Plugin
 .
 This plugin helps you to use the AWS Command Line Interface (AWS CLI) to
 start and end sessions to your managed instances. Session Manager is a
 capability of AWS Systems Manager.

-- 
Damian Szuberski

Bug#1034691: nmu: why3_1.5.1-1+b1 frama-c_20220511-manganese-3-10

[Sebastian Ramacher]

Hi Stéphane

On 2023-04-22 20:28:34 +0200, Jochen Sprickerhof wrote:
> * Sebastian Ramacher  [2023-04-22 16:06]:
> > Both why3 and frama-c have been rebuilt after the last ocaml ABI change.
> > From a quick between a build now and from the last why3, the following
> > packages changed (that appear to be relevant):
> > 
> > libcairo2-ocaml-dev (= [-0.6.2+dfsg-1+b1),-] {+0.6.4+dfsg-1),+}
> > ocaml (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-base (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-compiler-libs (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-findlib (= [-1.9.3-1),-] {+1.9.6-1+b1),+}
> > ocaml-interp (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-nox (= [-4.13.1-3),-] {+4.13.1-4),
> > 
> > So either the change in ocaml caused the ABI to change and we probably
> > need to rebuild the world of ocaml packages, or the ABI of why3 is
> > influenced by libcairo2-ocaml-dev but is missing the proper
> > dependencies.
> 
> I can recreate the old ABI hash by downgrading the src:ocaml packages, i.e.:
> 
> > ocaml (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-base (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-compiler-libs (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-interp (= [-4.13.1-3),-] {+4.13.1-4),+}
> > ocaml-nox (= [-4.13.1-3),-] {+4.13.1-4),
> 
> I leave the decision what to do with it to you.

ocaml 4.13.1-4 causes the ABI to change for at least why3. Do you expect
that the ABI of ther ocaml packages also changes? If so, we should
rebuild the ocaml world before the release to not get any surprises if a
ocaml package gets a stable update.

Cheers
-- 
Sebastian Ramacher

Bug#1034747: systemd-journal-gatewayd flood log with entries from microhttpd

[Michael Biebl]

Am 23.04.2023 um 10:18 schrieb phoenix...@t-online.de:

TCP_NODELAY option to ON state failed: Operation not supported


That sounds like either a problem in the kernel or the microhttpd library.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#854497: ext4magic: SIGSEGV while recovery from encrypted USB stick

[Markus]

Package: ext4magic
Followup-For: Bug #854497
X-Debbugs-Cc: markusba...@users.sourceforge.net

Dear Maintainer,

the program segfaults with a similar backtrace during directory listing. I 
think the local_ext2fs_extent_free() function iterates one to far.
However, following the changes from the patch for Bug #802089 using the 
original ext2fs_extent_free() function here should be appropriate. It fixes it 
for me.


*** ext4magic-fix-segfault-extent-free.patch
--- ext4magic-0.3.2.orig/src/block.c
+++ ext4magic-0.3.2/src/block.c
@@ -699,7 +699,7 @@ errcode_t local_block_iterate3(ext2_fils
mark_extent_block(fs, (char*) inode.i_block);
 
extent_errout:
-   local_ext2fs_extent_free(handle);
+   ext2fs_extent_free(handle);
ret |= BLOCK_ERROR | BLOCK_ABORT;
goto errout;
}

Bug#1034748: PlanetarySystemStacker does not work anylonger

[Thorsten Alteholz]

Package: planetary-system-stacker
Version: 0.8.32~git20221019.66d7558-1
Severity: grave

Due to a recent change in numpy, the planetary-system-stacker does not 
work anylong and crashes during start:




Traceback (most recent call last):
  File "/usr/bin/PlanetarySystemStacker", line 33, in 
sys.exit(load_entry_point('planetary-system-stacker==0.9.3', 
'console_scripts', 'PlanetarySystemStacker')())


  File "/usr/bin/PlanetarySystemStacker", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File 
"/usr/lib/python3/dist-packages/planetary_system_stacker/planetary_system_stacker.py",
 line 64, in 
from workflow import Workflow
  File "/usr/lib/python3/dist-packages/planetary_system_stacker/workflow.py", line 
40, in 
from stack_frames import StackFrames
  File "/usr/lib/python3/dist-packages/planetary_system_stacker/stack_frames.py", 
line 33, in 
from numpy import int as np_int
ImportError: cannot import name 'int' from 'numpy' 
(/usr/lib/python3/dist-packages/numpy/__init__.py)

Bug#1034747: systemd-journal-gatewayd flood log with entries from microhttpd

[phoenix_64]

Package: systemd-journal-remote

Version: 247.3-7+deb11u1 arm64

When i try to get the log file with the systemd-journal-gatewayd service
thru an UNIX-SOCKET, the log ist flooded with the following meassages after
the normal log entries:

Apr 23 10:07:00 home-assistant systemd-journal-gatewayd[16476]: microhttpd:
Setting TCP_NODELAY option to ON state failed: Operation not supported

Apr 23 10:07:00 home-assistant systemd-journal-gatewayd[16476]: microhttpd:
Setting TCP_CORK option to OFF state failed: Operation not supported

Apr 23 10:07:00 home-assistant systemd-journal-gatewayd[16476]: microhttpd:
Failed to push the data from buffers to the network. Client may experience
some delay (usually in range 200ms - 5 sec).

 

The only setting in the systemd-journal-gatewayd.socket is:

[Socket]

ListenStream=/run/systemd-journal-gatewayd.sock

I run Debian 11 on a Raspberry Pi 4, but the same problem occurs on Debian
11 running on a amd64 machine.

When i try the same on an Ubuntu 20 machine, the recived log is okay.

I am using Linux home-assistant 5.10.0-21-arm64 #1 SMP Debian 5.10.162-1
(2023-01-21) aarch64 on the Raspberry Pi 4

 

Bug#1034629: pdf-presenter-console: pdfpc terminates with symbol lookup error

[Barak A. Pearlmutter]

Wow, thanks everyone for tracking this down so quickly!
I'm going to close it, since it was due to non-debian packages.

Bug#1034723: rust-hyper: CVE-2023-26964

[Peter Michael Green]

reassign 1034723 rust-h2
thanks


The following vulnerability was published for rust-hyper.

CVE-2023-26964[0]:
|/An issue was discovered in hyper v0.13.7. h2-0.2.4 Stream stacking /|/occurs 
when the H2 component processes HTTP2 RST_STREAM frames. As a /|/result, the 
memory and CPU usage are high which can lead to a Denial /|/of Service (DoS). /
https://github.com/hyperium/hyper/issues/2877
https://github.com/hyperium/h2/commit/5bc8e72e5fcbd8ae2d3d9bc78a1c0ef0040bcc39  
(v0.3.17)

I've just read though the github threads, it seems that although
this was initially filed against the hyper crate the actual
issue/fix was in the h2 crate. This has also been filed in the
rustsec database at https://rustsec.org/advisories/RUSTSEC-2023-0034.html

Bug#1034746: Bug: mk2efs/mkfs.ext4 does not create the correct amount of inodes if -i is specified with 640k to 832k

[The MH]

Package: e2fsprogs
Version: 1.46.5
Severity: minor

I did not find this bug in the patchnotes for the latest versions on
e2fsprogs.sourceforge.net/e2fsprogs-release.html, so I assume it is
still present.

I stumbled upon this, because I wanted to specifiy -i 768k for my main
data drive (a 2 TB hard drive) as kind of less "aggressive" option
than -i 1M or -T largefile.

I proceeded to test this behaviour against a file container with
exactly 4 GiB. From what I know the value should increment in steps of
512 for every 64k as this is the boundary for one inode block per
block group which ranges from 16 to 8 in this scenario.

-i 512k: number of inodes: expected 8192 actual 8192 -> ok
-i 576k: number of inodes: expected 7680 actual 7680 -> ok

-i 640k: number of inodes: expected 7168 actual 6656
-i 704k: number of inodes: expected 6656 actual 6144
-i 768k: number of inodes: expected 6144 actual 5632
-i 832k: number of inodes: expected 5632 actual 5120

-i 896k: number of inodes: expected 5120 actual 5120 -> ok
-i 960k: number of inodes: expected 4608 actual 4608 -> ok
-i 1024k or 1M: number of inodes: expected 4096 actual 4096 -> ok


Also I want to say a big thank you for all the great work with Debian
and FOSS software.

Bug#1034372: ncurses: CVE-2023-29491

[Sven Joachim]

On 2023-04-18 20:15 -0400, Thomas Dickey wrote:

> On Sat, Apr 15, 2023 at 07:27:45AM -0400, Thomas Dickey wrote:
>> On Sat, Apr 15, 2023 at 09:05:25AM +0200, Sven Joachim wrote:
>> > 
>> > Security boundaries are only crossed for setuid/setgid programs here,
>> > and we probably do not have many setuid binaries linked to libtinfo in
>> > the distribution (on my system, I could not find any).  So I guess you
>> > probably do not want to issue a DSA here, right?
>> > 
>> > Gentoo users have noticed a few problems after upgrading to the 20230408
>> > patchlevel[1,2,3], most notably output of openrc being completely
>> > broken.  While we do not have that particular problem because openrc in
>> 
>> It was already broken (the "(null)" strings come from its misuse of the
>> ncurses interface, which will require fixes in OpenRC).  I'm not going
>> to provide a patch for OpenRC itself - any maintainer should be able to
>> do _that_.
>> 
>> Today I'll put out the fix for zero-parameter tsl, along with similar minor
>> improvements, and if nothing else surfaces, use that as the basis for the
>> security-patch.
>
> I had another fix, which works fine.  Except of course for programs which
> call tparm without actually reading from the terminal database, and don't
> check error returns.  I could digress...

I am happy to reveal the bugs in theses non-conforming programs after
the bookworm release, but for now this is too intrusive.  We are about
to release Debian 12 within the next two months.

> ...reflecting on all of this, the low-impact change would be to use the
> --disable-root-environ configure option (possibly --disable-root-access
> as well).

The --disable-root-environ option disables _all_ use of custom terminfo
files by the superuser.  This has some side effects.

- At least one package FTBFS[1] because it runs TERMINFO=… tic under
  fakeroot.

- Rescue mode in the non-graphical Debian installer is broken if
  ncurses-term is not installed.  The installer uses an obscure terminal
  emulator called bogl-bterm which sets TERM=bterm, and if that terminfo
  entry is not found on the target system, it copies it to a temporary
  directory and sets TERMINFO accordingly before chrooting into the
  target system.

- Emacs' term.el package sets TERM=eterm-color and TERMINFO to the
  directory where Emacs ships this terminfo entry.  If ncurses-term is
  not installed, running programs as root is broken.

- The sysadmin can no longer use private terminfo files under
  /root/.terminfo and has to install those into the system database
  instead, where they affect everyone.  This might not always be
  desired.

It is because of such issues that I had proposed a new configure option
that only restricts programs running at elevated privileges[2].

Cheers,
   Sven


1. https://bugs.debian.org/1034644
2. https://lists.gnu.org/archive/html/bug-ncurses/2023-04/msg4.html