Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)

[Gabriel F. T. Gomes]

Control: tags -1 confirmed

Steps to reproduce

$ su -# become root
# echo $0
-bash # this is a login shell
# apt-get inst
(completes)
# su root
# echo $0
bash  # this is a non-login shell
# apt-get inst
(nothing happens)

I don't currently know what sources /etc/bash_completion in the login
shell. I'll try to figure it out.

On Tue, 18 Apr 2023 12:31:04 +
Askar Safin  wrote:

> Package: bash-completion
> Version: 1:2.11-6
> Severity: normal
> X-Debbugs-Cc: safinas...@gmail.com
> 
> bash-completion (for example, "apt-get inst") doesn't work for root in
> non-login shell on default settings. Completion works for normal users.
> And completion works in login shells.
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU threads)
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> 
> -- no debconf information

Bug#1034596: RFP: pdfsizeopt -- PDF file size optimizer

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: pdfsizeopt
  Version : v9
  Upstream Contact: Péter Szabó (https://keybase.io/pts)
* URL : https://github.com/pts/pdfsizeopt
* License : GPL-2.0
  Programming Lang: Python
  Description : PDF file size optimizer

pdfsizeopt is a program for converting large PDF files to small ones,
without decreasing visual quality or removing interactive features (such as
hyperlinks). More specifically, pdfsizeopt is a command-line application and
a collection of best practices to optimize the size of PDF files, with focus
on PDFs created from TeX and LaTeX documents.

Bug#1032914: phog: ships /etc/pam.d/greetd

[Jochen Sprickerhof]

Hi,

I've filled #1034595 to get phog unblocked as well.

(also this hopefully delays the autoremoval of phog).

Cheers Jochen

* Marc Dequènes  [2023-04-07 19:45]:

Quack Arnaud,

greetd was unblocked today. Thanks for your help :-).

\_o<

--
Marc Dequènes


signature.asc
Description: PGP signature

Bug#1034595: unblock: phog/0.1.3-2

[Jochen Sprickerhof]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: p...@packages.debian.org, Arnaud Ferraris 
Control: affects -1 + src:phog

Please unblock package phog

[ Reason ]
phog in testing ships PAM files for greetd that where transitioned to
the greetd package in 0.9.0-3 and are already unblocked in #1033966.
This cleans up the phog part of it.
In addition this fixes the dependencies of phog.

[ Impact ]
same as #1033966:
PAM configuration conflicts with greetd's embedded version (in new
version).
Also phog fails to start in a minimal installation due to the missing
dependencies.

[ Tests ]
I manually tested the upgrade (as did the greetd and phog maintainers,
according to #1033966) and uninstalling.
I also tested the missing runtime dependencies.

[ Risks ]
None.

[ 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 ]
I'm filling this on behalf of the DebianOnMobile team as I was not able
to reach Arnaud, assuming that he is fine with this and to finish #1033966.
I will also ping #1032914 to gain some time.

unblock phog/0.1.3-2
diff -Nru phog-0.1.3/debian/changelog phog-0.1.3/debian/changelog
--- phog-0.1.3/debian/changelog 2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/changelog 2023-03-15 13:59:03.0 +0100
@@ -1,3 +1,19 @@
+phog (0.1.3-2) unstable; urgency=medium
+
+  [ Guido Günther ]
+  * d/control: Allow for phosh-osk-stub.
+This allows to use phosh-osk-stub instead of squeekboard
+
+  [ Arnaud Ferraris ]
+  * debian: remove PAM conffiles on upgrade
+`greetd` now ships those, so we should get rid of them. Add a versioned
+dependency on `greetd` to ensure we have the proper configs.
+(Closes: #1032914)
+  * d/control: add missing runtime dependencies.
+(Closes: #1033282)
+
+ -- Arnaud Ferraris   Wed, 15 Mar 2023 13:59:03 +0100
+
 phog (0.1.3-1) unstable; urgency=medium
 
   * New upstream version 0.1.3
diff -Nru phog-0.1.3/debian/control phog-0.1.3/debian/control
--- phog-0.1.3/debian/control   2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/control   2023-03-15 13:59:03.0 +0100
@@ -36,9 +36,11 @@
  ${misc:Depends},
  ${shlibs:Depends},
  fonts-lato,
- greetd,
+ gnome-shell-common,
+ greetd (>= 0.9.0-3),
  phoc (>= 0.21.0+ds1),
- squeekboard,
+ polkitd,
+ squeekboard | phosh-osk-stub,
 Description: Greetd-compatible greeter for mobile phones
  Phog is a graphical greeter speaking the `greetd` protocol and aimed at mobile
  devices like smart phones and tablets using touch based inputs and small
diff -Nru phog-0.1.3/debian/phog.conffiles phog-0.1.3/debian/phog.conffiles
--- phog-0.1.3/debian/phog.conffiles1970-01-01 01:00:00.0 +0100
+++ phog-0.1.3/debian/phog.conffiles2023-03-15 13:59:03.0 +0100
@@ -0,0 +1,2 @@
+remove-on-upgrade /etc/pam.d/greetd
+remove-on-upgrade /etc/pam.d/greetd-greeter
diff -Nru phog-0.1.3/debian/phog.greetd-greeter.pam 
phog-0.1.3/debian/phog.greetd-greeter.pam
--- phog-0.1.3/debian/phog.greetd-greeter.pam   2023-02-02 19:50:11.0 
+0100
+++ phog-0.1.3/debian/phog.greetd-greeter.pam   1970-01-01 01:00:00.0 
+0100
@@ -1,2 +0,0 @@
-#%PAM-1.0
-@include login
diff -Nru phog-0.1.3/debian/phog.greetd.pam phog-0.1.3/debian/phog.greetd.pam
--- phog-0.1.3/debian/phog.greetd.pam   2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/phog.greetd.pam   1970-01-01 01:00:00.0 +0100
@@ -1,5 +0,0 @@
-#%PAM-1.0
-@include login
-
-authoptionalpam_gnome_keyring.so
-session optionalpam_gnome_keyring.so auto_start
diff -Nru phog-0.1.3/debian/rules phog-0.1.3/debian/rules
--- phog-0.1.3/debian/rules 2023-02-02 19:50:11.0 +0100
+++ phog-0.1.3/debian/rules 2023-03-15 13:59:03.0 +0100
@@ -15,7 +15,3 @@
# dh_auto_install will put files in debian/, while dh_install
# will look in debian/tmp. Make sure both use the same directory.
dh_auto_install --destdir=$(PHOG_DESTDIR)
-
-override_dh_installpam:
-   dh_installpam --name=greetd
-   dh_installpam --name=greetd-greeter

Bug#918135: No way to reproduce this EOL

[ng]

Hi, this bug was reported a long time ago, and I have no way to 
reproduce it anymore,  currently using 102.9.0-1~deb11u1.

Bug#991126: xfce4-panel: systray applet: when hovering, the consequent pop-up's text is messed up.

[ng]

Hi,

While I can still reproduce this bug in stable,  this bug is gone in 
testing.

Bug#1034594: avahi: CVE-2023-1981

[Salvatore Bonaccorso]

Source: avahi
Version: 0.8-9
Severity: important
Tags: security upstream
Forwarded: https://github.com/lathiat/avahi/issues/375
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for avahi.

CVE-2023-1981[0]:
| avahi-daemon can be crashed via DBus

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1981
https://www.cve.org/CVERecord?id=CVE-2023-1981
[1] https://github.com/lathiat/avahi/issues/375
[2] 
https://github.com/lathiat/avahi/commit/a2696da2f2c50ac43b6c4903f72290d5c3fa9f6f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1034530: mtrg: mrtg.postinst uses useradd/groupadd (passwd) while mrtg.postrm uses deluser/delgroup (adduser)

[Eriberto]

Hi Patrice,

Thanks for your bug report. I will an optional sequence, like
apt-cacher-ng, to solve this issue. I tested it using the piuparts
command.

  deluser --system mrtg 2>/dev/null || userdel -fr mrtg 2>/dev/null
  delgroup --system mrtg 2>/dev/null || groupdel -f mrtg 2>/dev/null

Regards,

Eriberto

Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

[Anton Gladky]

Hi,

boost-defaults_1.81.0 is in experimental. But boost1.81
is also available in the Debian Bookworm [1].

[1] https://packages.debian.org/source/testing/boost1.81

Regards

Anton

Am Di., 18. Apr. 2023 um 09:27 Uhr schrieb Olaf van der Spek
:
> ...
> 1.81 is in experimental, not in bookworm, right?
> It's unfortunate it's not in bookworm.

Bug#1034593: ITP: node-fortawesome-fontawesome-free -- The iconic font, CSS, and SVG framework

[Yadd]

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

* Package name: node-fortawesome-fontawesome-free
  Version : 6.4.0
  Upstream Contact: http://github.com/FortAwesome/Font-Awesome/issues
* URL : http://github.com/FortAwesome/Font-Awesome
* License : Expat, CC-by-4.0, SIL-OFL-1.1
  Programming Lang: JavaScript
  Description : The iconic font, CSS, and SVG framework

Font Awesome is the Internet's icon library and toolkit, used by
millions of designers, developers, and content creators.

This source package provides distincts binary packages to provides
FontAwesome icons in various format.

It's a dependency of JupyterLab and will be maintained under JS Team
umbrella.

Bug#1034592: systemd-coredump@0-9980-0.service

[Tim McConnell]

Package: systemd-coredump
Version: 252.6-1
Severity: normal

I see this in journalctl and my logs:
Apr 18 18:10:55  kernel: MainThread[9976]: segfault at 0 ip 7f22f8e472f9 sp
7ffdd6ecba98 error 6 in libxul.so[7f22f8d>
Apr 18 18:10:55  kernel: Code: 3f 08 48 8d 0d c8 ef 9a 06 48 89 08 31 c9 89 0c
25 00 00 00 00 0f 0b 48 8b 05 a3 4f 3f 08 48 8>
Apr 18 18:10:55 systemd[1]: Created slice system-systemd\x2dcoredump.slice -
Slice /system/systemd-coredump.
Apr 18 18:10:55  systemd[1]: Started systemd-coredump@0-9980-0.service -
Process Core Dump (PID 9980/UID 0).
Apr 18 18:10:58  systemd-coredump[9981]: [] Process 9976 (MainThread) of user
1000 dumped core.

  Module libsystemd.so.0 from
deb systemd-252.6-1.amd64
  Stack trace of thread 9976:
  #0  0x7f22f8e472f9 n/a
(libxul.so + 0xa472f9)
  #1  0x7f22f981382b n/a
(libxul.so + 0x141382b)
  #2  0x7f22fb065b8e n/a
(libxul.so + 0x2c65b8e)
  #3  0x7f22fb0b0acc n/a
(libxul.so + 0x2cb0acc)
  #4  0x7f22f9815f1c n/a
(libxul.so + 0x1415f1c)
  #5  0x7f22f981d77b n/a
(libxul.so + 0x141d77b)
  #6  0x7f22f981deb7 n/a
(libxul.so + 0x141deb7)
  #7  0x7f22f981e002 n/a
(libxul.so + 0x141e002)
  #8  0x7f22f97cbecd n/a
(libxul.so + 0x13cbecd)
  #9  0x7f22f97d3df0 n/a
(libxul.so + 0x13d3df0)
  #10 0x7f22f97cc412 n/a
(libxul.so + 0x13cc412)
  #11 0x7f22f97cb8de n/a
(libxul.so + 0x13cb8de)
  #12 0x7f22fcd59aa6 n/a
(libxul.so + 0x4959aa6)
  #13 0x55d29e055816 n/a
(plugin-container + 0xe816)
  #14 0x55d29e0553db n/a
(plugin-container + 0xe3db)
  #15 0x7f22f7e4218a
__libc_start_call_main (libc.so.6 + 0x2718a)
  #16 0x7f22f7e42245
__libc_start_main_impl (libc.so.6 + 0x27245)
  #17 0x55d29e055701 _start
(plugin-container + 0xe701)

  Stack trace of thread 9979:
  #0  0x7f22f7f23c06
epoll_wait (libc.so.6 + 0x108c06)
  #1  0x7f22f6a25f14 n/a
(libevent-2.1.so.7 + 0x2af14)
  #2  0x7f22f6a1ca15
event_base_loop (libevent-2.1.so.7 + 0x21a15)
  #3  0x7f22f97cc271 n/a
(libxul.so + 0x13cc271)
  #4  0x7f22f97cb8de n/a
(libxul.so + 0x13cb8de)
  #5  0x7f22f97de161 n/a
(libxul.so + 0x13de161)
  #6  0x7f22f97c79ea n/a
(libxul.so + 0x13c79ea)
  #7  0x55d29e0cbadd
_Z30set_alt_signal_stack_and_startP19PthreadCreateParams (plu>
  #8  0x7f22f7ea3fd4
start_thread (libc.so.6 + 0x88fd4)
  #9  0x7f22f7f245bc
__clone3 (libc.so.6 + 0x1095bc)
  ELF object binary
architecture: AMD x86-64
Apr 18 18:10:58  systemd[1]: systemd-coredump@0-9980-0.service: Deactivated
successfully.

Please let me know how to get more information if needed.
Thanks


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

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

Versions of packages systemd-coredump depends on:
ii  libc6  2.36-9
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libsystemd-shared  252.6-1
ii  libzstd1   1.5.4+dfsg2-5
ii  systemd252.6-1

Versions of packages systemd-coredump recommends:
ii  libdw1  0.188-2.1

systemd-coredump suggests no packages.

-- no debconf information

Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems

[Matt Taggart]

On 4/15/23 15:35, Chris Hofstaedtler wrote:


This behavior might follow the principle of least surprise, but I think for
SSD based systems it is losing out on the benefits of TRIM/discard (improved
i/o latency, flash wear).


Yes. Also it is - to the best of my knowledge - the only way of not
destroying possible admin configuration on upgrades.


I can think of a few situations:

A) installed system pre-bullseye, so not enabled by default. System does 
not have a /etc/systemd/system/timers.target.wants/fstrim.timer symlink.

  1) admin unaware of it, would benefit from it, might want it
  2) admin aware of it, chose not to not have it enabled
B) installed system bullseye or later, enabled by default. If the system 
is lacking the symlink, that means it was explicitly disabled by admin.


My guess is A1 vastly outnumbers A2 and B, but that those may be non-zero.
Does the differentiation between "disabled" and "masked" make any 
difference here? Would an admin that doesn't want it have explicitly 
masked it?


I thought of another case where it would be good to have it enabled by 
default: for virtual machines that use a copy on write filesystem and 
set discard=unmap to tell the virtualization that those blocks can be 
dropped on discard, potentially saving a lot of disk space. fstrim.timer 
not being enabled in the Debian VM hurts the virtualization host(even 
those not running Debian).


I guess it's already documented in README.Debian. Maybe it would be 
interesting to have something in the Bookworm release notes?


--
Matt Taggart
m...@lackof.org

Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470

[Jeremy Davis]

Thanks for the feedback.

On 19/4/23 08:08, Cyril Brulebois wrote:

If you can spare a reboot, it'd be interesting to confirm your installed
system is actually SB-capable. It should be, as we install grub-efi-$arch
and shim based on recognizing a system booted under UEFI, so it should be
fine. Of course, if it isn't, turning SB off again should restore booting…


I have re-enabled secure boot and can confirm that it "just works"! :)

If there is anything else that is of interest that you want me to test 
out, please feel free to ask.


TBH, I don't like some of the aspects of newer Gnome, but overall, 
Bookworm feels pretty solid.


Great work to you and all the other incredible volunteers that make 
Debian possible!


Cheers,
Jeremy

Bug#1034591: firejail-profiles: SuperTuxKart cannot cope with existing supertuxkart savefile

[Rishi Cutchin]

Package: firejail-profiles
Version: 0.9.72-2
Severity: normal
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,

Attempting to run 'supertuxkart' with an existing savefile will lead to
the game not launching, with errors related to the rendering engine, creating a 
new user and launching supertuxkart
does allow it to start, not sure how I would go about working around
this as it appears that supertuxkart has access to everything it should
need.


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

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

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.72-2

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- Configuration Files:
/etc/firejail/steam.profile changed [not included]

-- no debconf information

Bug#1034590: precedence of /etc/containers/storage.conf should higher than /usr/share/containers/storage.conf

[鐘翊修]

Package: podman
Version: 4.4.0+ds1-1

following man 5 containers-storage.conf,
when a system have both /etc/containers/storage.conf and 
/usr/share/containers/storage.conf

the values in /etc/containers/storage.conf overwrite the value in 
/usr/share/containers/storage.conf

But in 4.4.0+ds1-1. with both files, podman takes the config from 
/usr/share/containers/stroage.conf

To reproduce this

Create podman graph database on podman 4.3.1 with btrfs (config in 
/etc/containers/storage.conf)

upgrade from 4.3.1 to 4.4.0

run the following command

sudo podman info

expected error message

User-selected graph driver \"overlay\" overwritten by graph driver \"btrfs\" 
from database

Bug#1034589: inkscape: font-family is changed on PDF import

[Martin]

Package: inkscape
Version: 1.2.2-2+b1

Hi,

when importing a PDF, font is changed from a sans serif to a serif.

inkscape --export-overwrite --export-type=svg debian.pdf

Should probably be 'Liberation Sans' or similar, but it is 'CairoFont'.

Cheers



debian.pdf
Description: example input

Bug#1034588: lintian: provide a check for Build-Depends: python3-setuptools-scm for python packages using setuptools_scm

[Drew Parsons]

Package: lintian
Version: 2.116.3
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

The current recommended way for packaging python packages (upstream)
is to provide a pyproject.toml file and build with setuptools
(python3-setuptools).  Debian python package building activates this
build method with
  Build-Depends: dh-python, pybuild-plugin-pyproject

There are a number of different ways in which python packages maintain
their version (within the package, not the debian version). One of
these methods is setuptools_scm, https://github.com/pypa/setuptools_scm/

setuptools_scm is activated by including a [tool.setuptools_scm]
section in the package's pyproject.toml file.

setuptools_scm often operates by overwriting any existing version.py
file that might be present in the source tarball, and in some cases
this generates very weird version numbers based on local git tags.

That behaviour can be annoying for debian packaging, but
setuptools_scm has provided a mechanism to make life easier for
package distribution systems. If the environment variable
SETUPTOOLS_SCM_PRETEND_VERSION is set, then setuptools_scm does not
overwrite the existing version file. This mechanism is documented
upstream at https://github.com/pypa/setuptools_scm/

pybuild is smart enough to know about SETUPTOOLS_SCM_PRETEND_VERSION
(see /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm)
But it only processes this if python3-setuptools-scm has been included
in Build-Depends (more precisely, l.130
  if ((grep /python3-(setuptools-scm|hatch-vcs)/, @deps)

This behaviour is not obvious, so it's a good opportunity for lintian
to help debian python packages, by suggesting to add
  Build-Depends: python3-setuptools-scm 
when needed, if it's not already used.

The condition could be

1) debian/control has Build-Depends: dh-python, pybuild-plugin-pyproject
2) source has pyproject.toml containing [tool.setuptools_scm]
3) debian/control does not have Build-Depends: python3-setuptools-scm
 [3b) and debian/rules does not set SETUPTOOLS_SCM_PRETEND_VERSION manually]
then
  emit warning (or error) suggesting to add
Build-Depends: python3-setuptools-scm

Bug#1034587: inkscape: CJK font-size too small on PDF import

[Martin]

On 2023-04-19 00:24, Martin wrote:
> Workaround: Use pdf2svg instead.

Sorry, broken workaround: This tool changes all text to glyphs.

Better workaround: Find out correct font-size and edit.

Bug#1034587: inkscape: CJK font-size too small on PDF import

[Martin]

Package: inkscape
Version: 1.2.2-2+b1

Hi,

when importing a PDF, Chinese, Japanese, and Korean text is invisible,
because the font size inkscape applies, is too small:

inkscape --export-overwrite --export-type=svg example.pdf

creates a file example.svg with font-size:9.75px for most text, but
font-size:1e-32px for Korean and Chinese.

(Also, the symbol 繁 is left out entirely.)

Workaround: Use pdf2svg instead.

Cheers



example.pdf
Description: example input

Bug#1034372: ncurses: CVE-2023-29491

[Thomas Dickey]

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:
> > On 2023-04-13 20:39 +0200, Moritz Mühlenhoff wrote:
> > 
> > > The following vulnerability was published for ncurses.
> > >
> > > CVE-2023-29491 was assigned to 
> > > https://invisible-island.net/ncurses/NEWS.html#index-t20230408
> > >
> > > If you fix the vulnerability please also make sure to include the
> > > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > >
> > > For further information see:
> > >
> > > [0] https://security-tracker.debian.org/tracker/CVE-2023-29491
> > > https://www.cve.org/CVERecord?id=CVE-2023-29491
> > 
> > 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...

...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).

By the way, the issues that I've been addressing exist in other
implementations.  Have a nice day.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1034347: spamd timeout after reboot: dns: bad dns reply: bgread: recv() failed

[Martin Michlmayr]

* Martin Michlmayr  [2023-04-13 18:23]:
> A Google search has led to:
> https://bugzilla.redhat.com/show_bug.cgi?id=1985587
> The proposed patch seems relevant to Debian's spamd service file too:
> https://src.fedoraproject.org/rpms/spamassassin/pull-request/12#request_diff

I've now tested this change to the systemd file and it makes it work
as expected.

Can you please add this fix as an update to bookworm.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1034564: debbugs: "There is no record of Bug" after getting confirmation e-mail

[Don Armstrong]

Control: reassign -1 bugs.debian.org
Control: forcemerge 1021304 -1

On Tue, 18 Apr 2023, Askar Safin wrote:
> I just reported bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034563 
> .
> 
> After some minutes I got confirmation e-mail titled "Bug#1034563:
> Acknowledgement (login: "su" doesn't put /sbin and /usr/sbin to PATH)"
> 
> This e-mail contained a link " https://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=1034563 "

There's a short delay between a bug being filed and the bug being
distributed to the frontends. It's known, it's short, and it only
happens on new bugs.

-- 
Don Armstrong  https://www.donarmstrong.com

I finally developed
a computer with feelings.
It just doesn't have
feelings for me.
 -- a softer world #633
http://www.asofterworld.com/index.php?id=633

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

[James Addison]

Source: mpv
Followup-For: Bug #1026060
X-Debbugs-Cc: patchesthomas@web.de, alf.debian...@gmx.de

Hi,

I haven't 100% confirmed this, but from some inspection it looks like DVB
support may be disabled-by-default based on the meson options[1] in the source
package for mpv.

The upstream source began using meson from version 0.35 onwards[2], so that
could fit as an explanation.

FWIW: Debian's packaging has (both in the past[3], and currently[4]) included
build configuration to enable DVB.. so this may likely be a regression as a
result of those upstream build system changes.

Thanks,
James

[1] - https://sources.debian.org/src/mpv/0.35.1-3/meson_options.txt/#L14

[2] - https://github.com/mpv-player/mpv/pull/8840

[3] - https://sources.debian.org/src/mpv/0.32.0-3/debian/rules/#L8

[4] - https://sources.debian.org/src/mpv/0.35.1-3/debian/rules/?hl=8#L8

Bug#1034586: always reports inactive/expired certificate on armhf

[Marco d'Itri]

Package: lighttpd
Version: 1.4.69-1
Severity: normal

I am using the latest openssl and lighttpd packages on an armhf (with an 
arm64 kernel) and an amd64 system, and only on the armhf system I always 
get this warning at startup even just after having created a Let's 
Encrypt certificate.

Apr 19 01:23:31 omitted.mi.bofh.it lighttpd[8876]: 2023-04-19 01:23:30: 
(mod_openssl.c.1335) SSL: inactive/expired X509 certificate 
'/var/lib/dehydrated/certs/omitted.mi.bofh.it/fullchain.pem'

# openssl x509 -noout -text -in 
/var/lib/dehydrated/certs/bokassa.mi.bofh.it/fullchain.pem | grep -A2 Validity
Validity
Not Before: Apr 18 22:13:45 2023 GMT
Not After : Jul 17 22:13:44 2023 GMT

After looking at 
https://github.com/lighttpd/lighttpd1.4/blob/fdb7ffed88b9dfe09a51e7fb58e5ddfe938c1ec9/src/mod_openssl.c#L1284
 
I wonder if this is common on all 32 bit systems instead.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034585: lmfit-py: should use Build-Depends: python3-setuptools-scm instead of patching out scm

[Drew Parsons]

Source: lmfit-py
Version: 1.1.0-1
Severity: normal

lmfit-py 1.1.0-1 introduced debian patch preserve_version.patch to
prevent the python package build from introducing a spurious package
version.

If I correctly understand the way pybuild-plugin-pyproject interacts
with setuptools_scm, setuptools_scm itself already has a mechanism via
SETUPTOOLS_SCM_PRETEND_VERSION for preserving the package version.
pybuild will automatically activate this mechanism if
python3-setuptools-scm is listed in the Build-Depends.

If that's the case, then preserve_version.patch should be dropped, and
  Build-Depends: python3-setuptools-scm
should instead be added in debian/control.


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

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

Bug#1034584: firejail-profiles: Private-etc breaks steam

[Rishi Cutchin]

Package: firejail-profiles
Version: 0.9.72-2
Severity: normal
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,

Attempting to run steam with its default firejail profile leads to
errors relating to libGL.so.1, I tried numerous ways to work arounds
this and it appears that the private-etc does correctly list
alternatives, but it still failed to start. I had to add ignore
private-etc to steam.local to work around this issue.

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

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

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.72-2

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- Configuration Files:
/etc/firejail/steam.profile changed [not included]

-- no debconf information

Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470

[Cyril Brulebois]

Jeremy Davis  (2023-04-19):
> Apologies about slow reply.

No worries at all.

> Perhaps there was something else going on and it was coincidental that
> it worked after disabling secure boot? I just assumed that it was a
> UEFI bug(/feature?) and not directly relevant to Debian.

That kind of things Steve is more likely to know about.

> I haven't tried re-enabling secure boot.

If you can spare a reboot, it'd be interesting to confirm your installed
system is actually SB-capable. It should be, as we install grub-efi-$arch
and shim based on recognizing a system booted under UEFI, so it should be
fine. Of course, if it isn't, turning SB off again should restore booting…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1034583: kodi-game-libretro: Joystick input doesn't work in games

[Hugh Cole-Baker]

Package: kodi-game-libretro
Version: 20.2.2-2
Severity: normal

Dear Maintainer,

In Kodi 20 in Debian testing, game addons don't seem to receive any input from
a USB game controller.

I have an attached USB game controller (VID 2dc8, PID 9001, 8Bitdo NES30 Pro)
which is working OK to control the user interface in Kodi to navigate menus,
etc, but when I launch a game in Kodi, the game doesn't receive any input from
the controller. The Kodi UI still seems to receive game controller input while
the game is running, for example I can press Select+Start to exit the game,
or hold Start to bring up the Kodi game settings menu, but the actual game
can't be controlled at all.

This is a regression from the previous version, since I had the same game
controller working with the libretro-based game addons in Kodi 19 on Bullseye.

I have mapped the buttons in Kodi's settings for both the default type of
controller (named "Kodi" in the UI) and the "Super Nintendo" control scheme,
and have tested and found this problem with the libretro
"kodi-game-libretro-bsnes-mercury-performance" Debian package, but also with
other libretro addons I've built locally, so I don't think it's specific to
any single libretro game addon, and the controller works fine in other Kodi
UI, so kodi-game-libretro seemed like the most appropriate package to report
the bug against.

Some things I've noticed that could be useful info:
- if I hold Start while a game is running in the BSNES emulator, and go into
  Settings->Controls, the Kodi UI shows "Super Nintendo" under the controller
  profile, and a picture of a SNES gamepad, but under the list of "Buttons"
  it says "Nothing to map". I'd sorta expect the SNES gamepad buttons to be
  listed there.
- If I turn on debug logging in Kodi, for every button press while a game is
  running, I can see 2 log messages about the button being ignored and one
  about it being handled, e.g.:
  debug : BUTTON [ 11 ] on "8Bitdo NES30 Pro   8Bitdo NES30 Pro" 
pressed
  debug : FEATURE [ start ] on game.controller.default pressed 
(ignored)
  debug : FEATURE [ start ] on game.controller.snes pressed (ignored)
  debug : FEATURE [ start ] on game.controller.default pressed 
(handled)
- I'm using Kodi GBM 'windowing', i.e. running it without X or Wayland.
- Other maybe-relevant package versions: kodi-peripheral-joystick 20.1.3+ds-1,
  kodi-game-libretro-bsnes-mercury-performance 094+git20220807-6

I'm happy to test patches or recompile Kodi/addons to help debugging.
Regards, Hugh

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

Kernel: Linux 6.0.3-g54e50e1b1-sigmaris (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kodi-game-libretro depends on:
ii  kodi [kodi-api-main]  2:20.1+dfsg-1
pn  kodi-api-filesystem   
pn  kodi-api-game 
pn  kodi-api-general  
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libtinyxml2.6.2v5 2.6.2-6

kodi-game-libretro recommends no packages.

kodi-game-libretro suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LC_TERMINAL = "iTerm2",
LANG = "en_GB.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#1034101: installation-reports: bookworm rc1 successful install to Levono T470

[Jeremy Davis]

Hi Cyril & Steve,

Apologies about slow reply. I only just found this thread buried in my 
'debian bugs' folder (I'm subscribed to bugs@debian and obviously don't 
have my filters set up as they should be...).


On 9/4/23 11:39, Steve McIntyre wrote:

On Sun, Apr 09, 2023 at 01:53:11AM +0200, Cyril Brulebois wrote:

Hi Jeremy,

and thanks for your report.

Jeremy Davis  (2023-04-09):

Machine: Lenovo T470 (20HD)

Had to disable secure boot to get USB to boot, but otherwise,
everything "just worked".


Why is that? We've been supporting Secure Boot for a very long while.


And one of my standard test machines here is my old T470. Jeremy: what
problem are you seeing please?



FWIW this is my first "proper" UEFI hardware.

The issue I had was that the USB stick (with debian iso copied to it) I 
was using wasn't showing up in the (bios/uefi) boot options (f12) as a 
bootable device (i.e. wasn't listed as an option).


I was considering trying PXE boot, but I ran across online suggestions 
that some USB sticks aren't recognized by BIOS/UEFI with secure boot 
enabled. So I disabled secure boot and the USB appeared! :) Everything 
worked as expected after that.


Perhaps there was something else going on and it was coincidental that 
it worked after disabling secure boot? I just assumed that it was a UEFI 
bug(/feature?) and not directly relevant to Debian.


I haven't tried re-enabling secure boot.

Regards,
Jeremy

Bug#1003976: RFS: xmrig/6.16.2-1 [ITP] -- High performance, open source CPU/GPU miner and RandomX benchmark.

[Ben Westover]

Hello,

On 4/18/23 10:18 AM, Bastian Germann wrote:
I looked into this when I first started packaging xmrig. 
Unfortunately, for many of these third party libraries, Debian's 
packaging of them won't work because the version included in xmrig is 
specially modified and contains lots of xmrig-specific functions that 
aren't easy to work around. For example, many of argon2's functions 
directly have xmrig in the name, and work a bit differently to those 
of the original project.


The missing thing is hugepages support:
https://github.com/xmrig/xmrig/commit/b1db0803cfdcb25fd51cef1df2dba46dc63fb0f7

src/crypto/randomx/dataset.cpp relies on some private argon2 
implementation details.
But as far as I can see you can just have some definitions to satisfy 
these needs.


Ah, I see. I'm very inexperienced with C(++), so I didn't understand how 
easy or hard it would be to replace those specifics.



Either patch or build with WITH_ARGON2=OFF.


I wish I knew how to patch. I would build with argon2 off, but looking 
at cmake/randomx.cmake it seems like randomx, essential for mining XMR, 
requires argon2 to be enabled.


The source also directly includes headers that exist in the original 
source but not a packaged version, and which are also modified 
specifically for xmrig. If I were to get rid of all the third party 
libraries that don't work easily with Debian's packaged versions, 
there wouldn't be much xmrig functionality left.


The only thing that is not easily replacable from the original list is 
llhttp. Just keep this one. I have done the trivial replacements for CL, 
fmt, and rapidjson. hwloc is built with the system library anyway and 
adl is only used on Windows.


Okay, there's my inexperience again. When I was first packaging this, I 
took a look at argon2 and assumed most of the other libraries were as 
hard to replace as it. Thanks for showing me how easy it really was.


I've pushed what I have so far to Salsa; unless randomx is disabled, it 
won't build without argon2, and I don't know how to patch it. Can you 
please help me?


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034582: opencpn: broken symlinks: MathJax.js highlight.min.js due to missing dependencies

[Paul Wise]

Package: opencpn
Version: 5.8.0+dfsg-1
Severity: serious
File: /usr/share/opencpn/plugins/chartdldr_pi/data/doc/MathJax.js
File: /usr/share/opencpn/plugins/chartdldr_pi/data/doc/highlight.min.js
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

opencpn 5.8.0+dfsg-1 introduced two broken symlinks:

   /usr/share/opencpn/plugins/chartdldr_pi/data/doc/MathJax.js -> 
../../../../../javascript/mathjax/MathJax.js
   /usr/share/opencpn/plugins/chartdldr_pi/data/doc/highlight.min.js -> 
../../../../../javascript/highlight.js/highlight.min.js

This appears to be because opencpn switched to using the packaged
versions of these files, but only added the libjs-mathjax and
libjs-highlight.js packages to the Build-Depends. Since there is
nothing to auto-populate Depends for JavaScript packages (please talk
to the JS team about adding that) and the packages weren't added
manually to Depends, the added symlinks aren't working unless the user
already had the packages installed. This bug was filed at severity
serious because of the missing dependencies.

Here is some information about the symlinks:

   $ adequate opencpn
   opencpn: broken-symlink 
/usr/share/opencpn/plugins/chartdldr_pi/data/doc/MathJax.js -> 
../../../../../javascript/mathjax/MathJax.js
   opencpn: broken-symlink 
/usr/share/opencpn/plugins/chartdldr_pi/data/doc/highlight.min.js -> 
../../../../../javascript/highlight.js/highlight.min.js
   
   $ readlink /usr/share/opencpn/plugins/chartdldr_pi/data/doc/MathJax.js 
/usr/share/opencpn/plugins/chartdldr_pi/data/doc/highlight.min.js
   ../../../../../javascript/mathjax/MathJax.js
   ../../../../../javascript/highlight.js/highlight.min.js
   
   $ chase /usr/share/opencpn/plugins/chartdldr_pi/data/doc/MathJax.js 
/usr/share/opencpn/plugins/chartdldr_pi/data/doc/highlight.min.js
   chase: ../../../../../javascript/mathjax: No such file or directory
   chase: ../../../../../javascript/highlight.js: No such file or directory
   
   $ apt-file search javascript/mathjax/MathJax.js
   libjs-mathjax: /usr/share/javascript/mathjax/MathJax.js
   
   $ apt-file search javascript/highlight.js/highlight.min.js
   libjs-highlight.js: /usr/share/javascript/highlight.js/highlight.min.js
   
   $ apt-cache show opencpn opencpn-data | grep libjs ; echo $?
   1

Here is the log of the upgrade:

   Log started: 2023-04-18  17:09:54
   apt-listchanges: Reading changelogs...
   apt-listchanges: Mailing root: apt-listchanges: changelogs for chianamo
   apt-listchanges: Reading changelogs...
   Selecting previously unselected package libcxx-serial1:amd64.
   Preparing to unpack .../libcxx-serial1_1.2.1-5+b1_amd64.deb ...
   Unpacking libcxx-serial1:amd64 (1.2.1-5+b1) ...
   Preparing to unpack .../opencpn-data_5.8.0+dfsg-1_all.deb ...
   Unpacking opencpn-data (5.8.0+dfsg-1) over (5.6.2+dfsg-3) ...
   Preparing to unpack .../opencpn_5.8.0+dfsg-1_amd64.deb ...
   Unpacking opencpn (5.8.0+dfsg-1) over (5.6.2+dfsg-3) ...
   Setting up opencpn-data (5.8.0+dfsg-1) ...
   Setting up libcxx-serial1:amd64 (1.2.1-5+b1) ...
   Setting up opencpn (5.8.0+dfsg-1) ...
   Processing triggers for mailcap (3.70+nmu1) ...
   Processing triggers for desktop-file-utils (0.26-1) ...
   Processing triggers for hicolor-icon-theme (0.17-2) ...
   Processing triggers for gnome-menus (3.36.0-1.1) ...
   Processing triggers for libc-bin (2.36-9) ...
   Processing triggers for man-db (2.11.2-2) ...
   Log ended: 2023-04-18  17:10:17

Here is the changelog of the version that introduced this:

   opencpn (5.8.0+dfsg-1) unstable; urgency=medium
   
 * New upstream release
 * Drop upstreamed patches, rebase remaining
 * Exclude MathJax and highlight js libraries, use packages instead.
 * Add new build deps:
- libssl-dev
- googletest
- libglew-dev
- repidjson-dev
- libjs-highlight.js
- libjs-mathjax
 * Update deprecated libpixbuf-dev build dep
 * Update d/copyright using cme.
   
-- Alec Leamas   Fri, 14 Apr 2023 09:37:20 +0200

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (950, 'testing-security'), (900, 'testing-debug'), (900, 
'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages opencpn depends on:
ii  bzip2   1.0.8-5+b1
ii  libarchive133.6.2-1
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.36-9
ii  libcurl3-gnutls 7.88.1-8
ii  libcxx-serial1  1.2.1-5+b1
ii  libelf1 0.188-2.1

Bug#1034581: php-guzzlehttp-psr7: CVE-2023-29197

[Salvatore Bonaccorso]

Source: php-guzzlehttp-psr7
Version: 2.4.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for php-guzzlehttp-psr7.

CVE-2023-29197[0]:
| guzzlehttp/psr7 is a PSR-7 HTTP message library implementation in PHP.
| Affected versions are subject to improper header parsing. An attacker
| could sneak in a newline (\n) into both the header names and values.
| While the specification states that \r\n\r\n is used to terminate the
| header list, many servers in the wild will also accept \n\n. This is a
| follow-up to CVE-2022-24775 where the fix was incomplete. The issue
| has been patched in versions 1.9.1 and 2.4.5. There are no known
| workarounds for this vulnerability. Users are advised to upgrade.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-29197
https://www.cve.org/CVERecord?id=CVE-2023-29197
[1] https://github.com/guzzle/psr7/security/advisories/GHSA-wxmh-65f7-jcvw

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1034580: php-slim-psr7: CVE-2023-30536

[Salvatore Bonaccorso]

Source: php-slim-psr7
Version: 1.6.0-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for php-slim-psr7.

CVE-2023-30536[0]:
| slim/psr7 is a PSR-7 implementation for use with Slim 4. In versions
| prior to 1.6.1 an attacker could sneak in a newline (\n) into both the
| header names and values. While the specification states that \r\n\r\n
| is used to terminate the header list, many servers in the wild will
| also accept \n\n. An attacker that is able to control the header names
| that are passed to Slilm-Psr7 would be able to intentionally craft
| invalid messages, possibly causing application errors or invalid HTTP
| requests being sent out with an PSR-18 HTTP client. The latter might
| present a denial of service vector if a remote service#8217;s web
| application firewall bans the application due to the receipt of
| malformed requests. The issue has been patched in version 1.6.1. There
| are no known workarounds to this issue. Users are advised to upgrade.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-30536
https://www.cve.org/CVERecord?id=CVE-2023-30536
[1] https://github.com/slimphp/Slim-Psr7/security/advisories/GHSA-q2qj-628g-vhfw
[2] 
https://github.com/slimphp/Slim-Psr7/commit/4fea29e910391b1883de5bf6e84b50f6900355fb

Regards,
Salvatore

Bug#1034579: GMock fails to pass a cross compiler again

[Helmut Grohne]

Package: cmake-extras
Version: 1.6-1
Severity: important
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:biometryd

Hi,

the 1.6-1 upload has a noticeable regression. It reverts #973580
claiming it was fixed upstream. The referenced MR
https://gitlab.com/ubports/development/core/cmake-extras/-/merge_requests/4
is still open. Yet the patch has been dropped in 1.6-1. It still is
needed. Now any package that uses include(GMock) fails to cross build
from source. Can you reinstate the patch? I think this can be eligible
for bookworm as you'd be reverting a faulty revert.

Helmut

Bug#1034577: SSL certificate hostname check too restrictive

[Micha Lenk]

Patch verification

To be sure, I just made a cross-check with the same AqBanking configuration as
above and with the patch applied.

To prove the fix is working as intended, I've retried the reproduction given in
the initial Debian bug report.  The hostname was no longer flagged as issue, so
the patch seems to work.

```
$ aqhbci-tool4 getcert --user=1
5:2023/04/18 22-26-58:aqbanking(51692):siotlsext.c:  233: Status for
certificate 76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73" has changed
to "The certificate is valid" (->8000), need to present
4:2023/04/18 22-26-58:gwen(51692):syncio_tls.c:  137: No checkCertFn
set, using GWEN_GUI
= Certificate Received =
The following certificate has been received:
Name : fints1.atruvia.de
Organisation : Atruvia AG
Department   : unknown
Country  : DE
City : Karlsruhe
State: Baden-W?rttemberg
Valid after  : 2023/03/21 08:14:05
Valid until  : 2024/03/21 08:09:00
Hash (MD5)   : 76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73
Hash (SHA1)  : 8E:C0:B3:C1:F7:B6:0A:9B:8F:86:00:D0:F2:72:E9:F6:72:EE:D7:18
Hash (SHA512):
DE:A2:D8:16:29:3B:64:83:34:C4:BD:5C:08:40:DE:45:26:BA:EF:5E:79:E9:21:52:77:DE:3A:A2:F6:B8:98:E4:62:BE:28:31:03:57:D8:67:40:64:35:C7:A1:7C:31:AB:C3:B2:7C:B3:3B:98:31:CE:DE:23:36:50:F9:F2:77:E1
Status   : The certificate is valid
Do you wish to accept this certificate?
(1) Yes  (2) No
Please enter your choice:
```

To also prove the SSL certificate hostname check is still done correctly, I've
temporarily configured in /etc/hosts the hostname of the server to point to the
ip address of one of my servers. It got flagged correctly as hostname mismatch:

```
$ aqhbci-tool4 getcert --user=1
4:2023/04/18 22-18-05:gwen(51547):syncio_tls.c:  971: Certificate was
not issued for this host
Certificate was not issued for this host
5:2023/04/18 22-18-05:aqbanking(51547):siotlsext.c:  233: Status for
certificate CA:AB:31:39:32:97:D9:DD:E0:DA:7F:E5:CD:FB:51:D4" has changed
to "Certificate owner does not match hostname" (->0020),
need to present
4:2023/04/18 22-18-05:gwen(51547):syncio_tls.c:  137: No checkCertFn
set, using GWEN_GUI
= Certificate Received =
The following certificate has been received:
Name : www.lenk.info
Organisation : unknown
Department   : unknown
Country  : unknown
City : unknown
State: unknown
Valid after  : 2023/03/23 17:03:39
Valid until  : 2023/06/21 18:03:38
Hash (MD5)   : CA:AB:31:39:32:97:D9:DD:E0:DA:7F:E5:CD:FB:51:D4
Hash (SHA1)  : FD:39:60:A0:8F:07:58:76:47:E5:8D:0E:E1:E5:81:66:1B:CB:C6:87
Hash (SHA512):
8B:DE:8E:4F:F7:B4:3F:89:D1:C3:86:8E:AC:9F:52:26:CC:3F:4F:32:22:86:11:1A:EB:8E:13:18:3B:AE:3B:21:A1:6D:E1:42:88:7C:8A:92:EF:BF:2C:54:B2:57:06:93:90:7C:EC:AA:15:C2:57:4F:2D:C2:32:4B:62:A0:EE:59
Status   : Certificate owner does not match hostname
Do you wish to accept this certificate?
(1) Yes  (2) No
Please enter your choice: 2
```

Bug#1034210: python3-charon: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Christoph Berg]

Re: Gregor Riepl
> -install(FILES service/charon.service DESTINATION lib/systemd/system)
> +install(FILES service/charon.service DESTINATION /lib/systemd/system)

Thanks for figuring that out!

Uploaded to experimental and unstable.

Christoph

Bug#1034578: bullseye-pu: package tzdata/2021a-1+deb11u10

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: tzd...@packages.debian.org, debian-gl...@lists.debian.org
Control: affects -1 + src:tzdata

[ Reason ]
Include the changes found tzdata 2023c into the bullseye package, namely
the change to Lebanon DST. Given the confusion about DST in Lebanon, and
with a point release so close, I haven't judged necessary to go through
stable-updates.

[ Impact ]
Users in Lebanon will still have the wrong time.

[ Tests ]
There are not tests for the current change.

[ Risks ]
The change is trivial and is based on upstream change, and is in sid for
almost 3 weeks.

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

[ Changes ]
This basically reverts the change done in version 2021a-1+deb11u9 to
match the status quo about DST in Lebanon. It's best summarized by the
upstream changelog: "Model Lebanon's DST chaos by reverting data to tzdb
2023a".

[ Other info ]
I have already uploaded the package to the archive. Thanks for
considering.
diff -Nru tzdata-2021a/debian/changelog tzdata-2021a/debian/changelog
--- tzdata-2021a/debian/changelog   2023-03-24 22:41:33.0 +
+++ tzdata-2021a/debian/changelog   2023-04-18 20:03:16.0 +
@@ -1,3 +1,11 @@
+tzdata (2021a-1+deb11u10) bullseye; urgency=medium
+
+  * Cherry-pick patch from upstream:
+- 24-lebanon-dst2.patch: Revert the Lebanon DST change introduced in
+  2023b and backported to 2021a-1+deb11u9.
+
+ -- Aurelien Jarno   Tue, 18 Apr 2023 22:03:16 +0200
+
 tzdata (2021a-1+deb11u9) bullseye; urgency=medium
 
   * Cherry-pick patches from upstream:
diff -Nru tzdata-2021a/debian/patches/24-lebanon-dst2.patch 
tzdata-2021a/debian/patches/24-lebanon-dst2.patch
--- tzdata-2021a/debian/patches/24-lebanon-dst2.patch   1970-01-01 
00:00:00.0 +
+++ tzdata-2021a/debian/patches/24-lebanon-dst2.patch   2023-04-18 
20:00:36.0 +
@@ -0,0 +1,110 @@
+commit 0e0b0eb3e5b3c046971ff69aae1ca69c1450f5b4
+Author: Paul Eggert 
+Date:   Mon Mar 27 10:17:37 2023 -0700
+
+Revert 2023b’s data changes
+
+* NEWS: Mention this.
+* asia (Lebanon): Revert to 2023a data.  Add commentary.
+* tz-link.html: Warn further about confusion.
+
+diff --git a/NEWS b/NEWS
+index 9b235a29..fe0e809b 100644
+--- a/NEWS
 b/NEWS
+@@ -4,6 +4,9 @@
+
+   Changes to future timestamps
+
++Model Lebanon's DST chaos by reverting data to tzdb 2023a.
++(Thanks to Jad Baz for the heads-up.)
++
+ This year Lebanon springs forward April 20/21 not March 25/26.
+ (Thanks to Saadallah Itani.)
+
+diff --git a/asia b/asia
+index dd06a5fd..180b3992 100644
+--- a/asia
 b/asia
+@@ -2693,9 +2693,37 @@ ZoneAsia/Pyongyang  8:23:00 -   LMT 1908 
Apr  1
+ # Lebanon
+ #
+ # From Saadallah Itani (2023-03-23):
+-# Lebanon too announced today delay of Spring forward from March 25 to April 
20.
+-# From Paul Eggert (2023-03-23):
++# Lebanon ... announced today delay of Spring forward from March 25 to April 
20.
++#
++# From Paul Eggert (2023-03-27):
++# This announcement was by the Lebanese caretaker prime minister Najib Mikati.
+ # 
https://www.mtv.com.lb/en/News/Local/1352516/lebanon-postpones-daylight-saving-time-adoption
++# A video was later leaked to the media of parliament speaker Nabih Berri
++# asking Mikati to postpone DST to aid observance of Ramadan, Mikati objecting
++# that this would cause problems such as scheduling airline flights, to which
++# Berri interjected, "What flights?"
++#
++# The change was controversial and led to a partly-sectarian divide.
++# Many Lebanese institutions, including the education ministry, the Maronite
++# church, and two news channels LCBI and MTV, ignored the announcement and
++# went ahead with the long-scheduled spring-forward on March 25/26, some
++# arguing that the prime minister had not followed the law because the change
++# had not been approved by the cabinet.  Google went with the announcement;
++# Apple ignored it.  At least one bank followed the announcement for its 
doors,
++# but ignored the announcement in internal computer systems.
++# Beirut international airport listed two times for each departure.
++# Dan Azzi wrote "My view is that this whole thing is a Dumb and Dumber 
movie."
++# Eventually the prime minister backed down, said the cabinet had decided to
++# stick with its 1998 decision, and that DST would begin midnight March 29/30.
++# 
https://www.nna-leb.gov.lb/en/miscellaneous/604093/lebanon-has-two-times-of-day-amid-daylight-savings
++# 
https://www.cnbc.com/2023/03/27/lebanon-in-two-different-time-zones-as-government-disagrees-on-daylight-savings.html
++#
++# Although we could model the chaos with two Zones, that would likely cause
++# more trouble than it would cure.  Since 

Bug#1034071: u-boot-menu: Does not show a menu due to 'prompt 0'

[Vagrant Cascadian]

On 2023-04-08, Diederik de Haas wrote:
> On Saturday, 8 April 2023 04:24:10 CEST Vagrant Cascadian wrote:
>> On 2023-04-08, Diederik de Haas wrote:
>> I had intended to test a few different versions to see how they were
>> affected before moving forward with that... but I did not get around to
>> it and we are now very late in the freeze.
>> 
>> If it proves harmless on the version of u-boot in bookworm (2023.01*)
>> and bullseye (2021.01*), and if we are being really careful, buster
>> (2019.01*) ... then I think it would be good to consider for bookworm,
>> or maybe the first bookworm point release?
>
> Anyway, the goal is to make it configurable in u-boot-menu and it would be 
> better to keep the default behavior as it was.
> A new/better default could be considered for Trixie.
>
> I've updated the MR and attached the updated patch which only makes the 
> 'prompt' value a variable (with a default of '0').

I've tested u-boot-menu 4.2.2, which contains your patch applied, and at
least on the pinebook-pro it works correctly with u-boot 2023.04 (with both
U_BOOT_PROMPT=0 and U_BOOT_PROMPT=1) and does not break u-boot 2023.01
(although that version effectively ignores any setting, always behaving
as if U_BOOT_PROMPT=1).

So at least for versions of u-boot shipped in bookworm or newer, it does
not appear to cause problems.

Would be good to try the versions from bullseye and buster at some
point, but my hunch is it will be fine. The only problem I would expect
is with arbitrary vendor forks of u-boot which may or may not have
changed the code.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1034562: installation-reports: "Works", graphical corruption & flashing once in Gnome

[Roland Clobus]

Hello Adam,

I've seen some issues on openQA which run on AMD hardware, but I 
personally only have Intel processors, so I cannot reproduce such 
issues. [1]


Can you confirm that the microcode is active?
sudo journalctl --boot | grep microcode

Could you try uninstalling the package 'amd-microcode'?
sudo apt-get remove amd-microcode
sudo update-initramfs -u

Does that fix your graphical issues?

With kind regards,
Roland Clobus

[1] https://openqa.debian.net/tests/140684#step/_graphical_wait_login/9


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034577: SSL certificate hostname check too restrictive

[Micha Lenk]

Package: libgwenhywfar79
Version: 5.6.0-2
Severity: serious
Tags: patch upstream fixed-upstream
Forwarded: https://www.aquamaniac.de/rdm/issues/295

A few days ago the communication to the banking server
https://hbci-pintan.gad.de/ doesn't work anymore because the already accepted
server certificate is rejected with the message "Owner of certificate does not
match hostname".

The issue could be easily reproduced with bogus anonymous credentials as below
(the error is triggered before authentication or credentials are needed). The
only relevant parameter for the reproduction is the "--server" parameter, all
other parameters are just there as the command wants them to be present.

```
$ aqhbci-tool4 adduser --username=Anonymous \
   --tokentype=pintan \
   --user=anonymous \
   --bank=0 \
   --server=https://hbci-pintan.gad.de/
3:2023/04/18 21-14-36:(null)(50094):banking_update.c:  610: No AqBanking config 
folder found at [/home/user/.aqbanking/settings6/users] (-1)
3:2023/04/18 21-14-36:(null)(50094):banking_update.c:  610: No AqBanking config 
folder found at [/home/user/.aqbanking/settings/users] (-1)
3:2023/04/18 21-14-36:(null)(50094):banking_update.c:  411: There is no old 
settings folder, need initial setup
```

On a system which didn't have any AqBanking setup before, a new user with
unique id 1 will be created (see output of "aqhbci-tool4 listusers").

```
$ aqhbci-tool4 listusers
User 0: Bank: de/0 User Id: anonymous Customer Id: anonymous Unique Id: 1
```

Now, for reproduction of the error, you need to retrieve the server
certificate, which will implicitly validate it.

```
$ aqhbci-tool4 getcert --user=1
5:2023/04/18 21-22-43:aqbanking(50117):siotlsext.c:  233: Status for 
certificate 76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73" has changed to 
"Certificate owner does not match hostname" (->0020), need to 
present
4:2023/04/18 21-22-43:gwen(50117):syncio_tls.c:  137: No checkCertFn set, using 
GWEN_GUI
= Certificate Received =
The following certificate has been received:
Name : fints1.atruvia.de
Organisation : Atruvia AG
Department   : unknown
Country  : DE
City : Karlsruhe
State: Baden-W?rttemberg
Valid after  : 2023/03/21 08:14:05
Valid until  : 2024/03/21 08:09:00
Hash (MD5)   : 76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73
Hash (SHA1)  : 8E:C0:B3:C1:F7:B6:0A:9B:8F:86:00:D0:F2:72:E9:F6:72:EE:D7:18
Hash (SHA512): 
DE:A2:D8:16:29:3B:64:83:34:C4:BD:5C:08:40:DE:45:26:BA:EF:5E:79:E9:21:52:77:DE:3A:A2:F6:B8:98:E4:62:BE:28:31:03:57:D8:67:40:64:35:C7:A1:7C:31:AB:C3:B2:7C:B3:3B:98:31:CE:DE:23:36:50:F9:F2:77:E1
Status   : Certificate owner does not match hostname
Do you wish to accept this certificate?
(1) Yes  (2) No
Please enter your choice: 2
5:2023/04/18 21-22-52:aqbanking(50117):siotlsext.c:  360: User response to 
presentation of cert "76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73" 
(Certificate owner does not match hostname): -108
3:2023/04/18 21-22-52:gwen(50117):syncio_tls.c: 1399: Peer cert not accepted 
(-108), aborting
Could not connect to server
3:2023/04/18 21-22-52:aqhbci(50117):provider_online.c:  919: Could not connect 
to server (-108)
Could not connect to server
3:2023/04/18 21-22-52:aqhbci-tool(50117):getcert.c:   98: Error -108 [Unknown 
error]
3:2023/04/18 21-22-52:aqhbci-tool(50117):aqhbci-tool.c:  275: Error calling 
control function (3)
```

Here you can see that Gwenhywfar reports the certificate as invalid with reason
"Certificate owner does not match hostname".

However, the very same configuration was working in the past just fine. Most
likely something on the server end changed.

Inspecting the certificate sent by the server shows that the "Common Name"
field is set to "fints1.atruvia.de", but also that a SubjectAltName extension
is present, which makes the certificate valid also for other hostnames,
including "hbci-pintan.gad.de".

Quoting https://en.wikipedia.org/wiki/Subject_Alternative_Name:
> RFC 2818 (May 2000) specifies Subject Alternative Names as the preferred
> method of adding DNS names to certificates, deprecating the previous method
> of putting DNS names in the commonName field. Google Chrome version 58
> (March 2017) removed support for checking the commonName field at all,
> instead only looking at the SANs.

So, if the certificate is valid, but AqBanking doesn't accept it, I concluded
to have found a bug.

Looking into the code, I think the culprit is some incomplete hostname
verification in Gwenhywfar's source file src/sio/syncio_tls.c at these lines
(line numbers based on current Git master):

```
1041   rv=gnutls_x509_crt_get_dn_by_oid(cert, GNUTLS_OID_X520_COMMON_NAME, 
0, 0, buffer1, );
1042   if (rv==0) {
1043 GWEN_SslCertDescr_SetCommonName(certDescr, buffer1);
1044 if (xio->hostName && strcasecmp(xio->hostName, buffer1)!=0) {
1045   DBG_INFO(GWEN_LOGDOMAIN, "Owner of 

Bug#1034576: unblock: caddy/2.6.2-5

[Peymaneh]

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

Please unblock package caddy

[ Reason ]
Fixes RC bug in 2.6.2-4: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034221

[ Impact ]
Systemd service files shipped by the package might not be installed in
the correct location and not automatically enabled at boot. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034221 for details

[ Tests ]
Additional to the standard golang autopkgtest, caddy includes a simple
autopkgtest that verifies if the Caddy webserver is running and able to
deliver a simple html-page.

[ Risks ]
None, since the changes done in this revision are very small.

[ 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


unblock caddy/2.6.2-5
diff -Nru caddy-2.6.2/debian/caddy.install caddy-2.6.2/debian/caddy.install
--- caddy-2.6.2/debian/caddy.install2023-01-15 22:06:16.0 +0100
+++ caddy-2.6.2/debian/caddy.install2023-04-17 15:11:12.0 +0200
@@ -1,6 +1,6 @@
 dist/config/Caddyfile   etc/caddy/
-dist/init/caddy.service usr/lib/systemd/system
-dist/init/caddy-api.service usr/lib/systemd/system
+dist/init/caddy.service lib/systemd/system
+dist/init/caddy-api.service lib/systemd/system
 debian/missing-sources/caddy/welcome/index.html usr/share/caddy/
 debian/generated/completions/caddy  
usr/share/bash-completion/completions/
 debian/generated/completions/_caddy 
usr/share/zsh/vendor-completions/
diff -Nru caddy-2.6.2/debian/changelog caddy-2.6.2/debian/changelog
--- caddy-2.6.2/debian/changelog2023-01-15 22:06:16.0 +0100
+++ caddy-2.6.2/debian/changelog2023-04-17 15:11:12.0 +0200
@@ -1,3 +1,9 @@
+caddy (2.6.2-5) unstable; urgency=high
+
+  * d/caddy.install: Fix location for systemd files (Closes: #1034221)
+
+ -- Peymaneh   Mon, 17 Apr 2023 15:11:12 +0200
+
 caddy (2.6.2-4) unstable; urgency=medium
 
   * d/rules: enable CGO, use common hardening flags

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Dmitry Baryshkov]

On Tue, 18 Apr 2023 at 21:36, Roger Shimizu  wrote:
>
> > Hello Roger, FTP masters,
> > Short story: the uploaded linux-board-support-package-dragonboard845c 
> > package (currently in NEW) contains a file with unclear license background 
> > and as such it should not be allowed into the archive.
> > The orig.tar.gz file needs to be repackaged before uploading.
>
> I tried to repack the orig, and re-upload, but got REJECTED by:
>
> linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc:
> Does not match file already existing in the pool.

Usually one would use suffix like -dfsg to mark the repacked package.
The -dfsg doesn't make sense in the case of a non-free package, so you
can probably use -repack.

More importantly I'm not sure that this package should be a part of
Debian at all.
I doubt that DI should touch these partitions. Firstly, because of the
reasons I expressed in my previous email (risk of bricking the board,
custom bootloaders being used on these devboards, etc).
Secondly, I'd like to point out that RB3/RB5 (and other dragonboards)
are in a pretty unique position. Other development boards (QRD, HDK,
Open-Q, etc.) do not have public redistributable bootloader archives.

-- 
With best wishes
Dmitry

Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3

[Roger Shimizu]

> Hello Roger, FTP masters,
> Short story: the uploaded linux-board-support-package-dragonboard845c package 
> (currently in NEW) contains a file with unclear license background and as 
> such it should not be allowed into the archive.
> The orig.tar.gz file needs to be repackaged before uploading.

I tried to repack the orig, and re-upload, but got REJECTED by:

linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc:
Does not match file already existing in the pool.

Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)

[J]

Thank you so much. Your help was amazing. Keep up the great work. Can close
this report.

On Tue, 18 Apr 2023 at 13:13, Simon Deziel  wrote:

> You can override ExecStart= by first defining it empty like that:
>
> [Service]
> ExecStart=
> ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
>
> HTH,
> Simon
>
> On 2023-04-17 23:20, J wrote:
> > Thank you so much, thats exactly what I was missing. I commented out the
> -p
> > in
> > ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
> > in
> > /usr/lib/systemd/system/unbound.service
> >
> > And now I have a pidfile back that I can use.
> > Unless there is any better way? I tried to override the unbound.service
> but
> > I'm not sure ExecStart= can be overrode.
> >
> > On Sun, 16 Apr 2023 at 18:52, J  wrote:
> >
> >> Hi!
> >> I'm having an issue where unbound is not creating the pid file
> >> I've specified in unbound.conf `pidfile: "/run/unbound.pid"`
> >> I also see that this path is hard coded in `/etc/init.d/unbound` as
> >> `PIDFILE="/run/unbound.pid"`
> >>
> >> The only thing that fixes it is commenting out `.
> /lib/lsb/init-functions`
> >> in  `/etc/init.d/unbound` which is obviously not what I want to do
> >>
> >> On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System <
> >> ow...@bugs.debian.org> wrote:
> >>
> >>> Thank you for filing a new Bug report with Debian.
> >>>
> >>> You can follow progress on this Bug here: 1034494:
> >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494.
> >>>
> >>> This is an automatically generated reply to let you know your message
> >>> has been received.
> >>>
> >>> Your message is being forwarded to the package maintainers and other
> >>> interested parties for their attention; they will reply in due course.
> >>>
> >>> Your message has been sent to the package maintainer(s):
> >>>   unbound packagers 
> >>>
> >>> If you wish to submit further information on this problem, please
> >>> send it to 1034...@bugs.debian.org.
> >>>
> >>> Please do not send mail to ow...@bugs.debian.org unless you wish
> >>> to report a problem with the Bug-tracking system.
> >>>
> >>> --
> >>> 1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494
> >>> Debian Bug Tracking System
> >>> Contact ow...@bugs.debian.org with problems
> >>>
> >>
> >
>
>

Bug#1034210: python3-charon: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Gregor Riepl]

Hi,


As a result, could you please move these files to /lib/systemd/system instead
so they are properly detected by debhelper?
As soon as debhelper is supporting (not until bookworm+1 aka Trixie) you will
be able to move them back to the newer location.


I've committed a patch to Salsa.
It looks like it does what it's supposed to, but I don't know how to 
test it because I don't understand the inner workings of debhelper very 
well.


@myon: Could you push a new release when you have time, and also against 
4.13.0-1? Thanks!


The patch also works with 4.13.0-1, with minor fuzz. Here's the 
refreshed version:


$ cat debian/patches/0002-service-files-in-root.patch
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -35,7 +35,7 @@
 install(DIRECTORY Charon DESTINATION ${CHARON_INSTALL_PATH} ${_excludes})

 if(INSTALL_SERVICE)
-install(FILES service/charon.service DESTINATION lib/systemd/system)
+install(FILES service/charon.service DESTINATION /lib/systemd/system)
 install(FILES service/nl.ultimaker.charon.conf DESTINATION 
share/dbus-1/system.d)

 endif()

Bug#1034575: ITP: cve-bin-tool -- The CVE Binary Tool is a free, open source tool to help you find known vulnerabilities in software, using data from the National Vulnerability Database (NVD) list of

[jarebear6expepjozn6rakjq5iczi3irqwphcvbswgkahd6b6twnxxid]

Package: wnpp
Severity: wishlist
Owner: jarebear6expepjozn6rakjq5iczi3irqwphcvbswgkahd6b6twnxxid 

X-Debbugs-Cc: debian-de...@lists.debian.org, 
jarebear6expepjozn6rakjq5iczi3irqwphcvbswgkahd6b6twnx...@4xvk.com

* Package name: cve-bin-tool
  Version : 3.2.0 
  Upstream Author : Teri Oda 
* URL : https://github.com/intel/cve-bin-tool
* License : GPL
  Programming Lang: Python
  Description : The CVE Binary Tool is a free, open source tool to help you 
find known vulnerabilities in software, using data from the National 
Vulnerability Database (NVD) list of Common Vulnerabilities and Exposures 
(CVEs).

The tool has two main modes of operation:

A binary scanner which helps you determine which packages may have been 
included as part of a piece of software. There are 288 checkers which focus on 
common, vulnerable open source components such as openssl, libpng, libxml2 and 
expat.
Tools for scanning known component lists in various formats, including 
.csv, several linux distribution package lists, language specific package 
scanners and several Software Bill of Materials (SBOM) formats.

It is intended to be used as part of your continuous integration system to 
enable regular vulnerability scanning and give you early warning of known 
issues in your supply chain.

Bug#1034526: azure-cli: Better collaboration with upstream

[Gregor Riepl]

The only official Debian packages are what you find on debian.org and
its mirrors, third party repositories are unofficial by definition and

...

From upstream's perspective, this is not true, unless you apply the 
term Debian in the strict sense of "released by the Debian project" and 
not in the sense of "packaged using Debian's packaging system".



Debian packages are not broken, they are working fine, to the extent
permitted by extremely broken and messy upstream sources. Due to
upstream bugs outside of our control at times some subfeature might not
work, but there's nothing we can do about it, there's always something
broken in the upstream code.


From a user's perspective, this is also untrue:
If azure-cli is currently installed from the Debian package repository, 
it fails on multiple subfeatures. In this context, it's irrelevant if 
this is "upstream's fault". By releasing the package in the Debian 
package repositories, one or multiple DDs or DMs have taken (limited) 
responsibility for the Debian version, and they should make sure the 
Debian version gets fixed.



That is a bit rich, given upstream routinely ignores bug reports, pull
requests and so on, to the extent that I have given up even trying. The
"azure-sdk-for-python" upstream repository is an absolute disaster of a
dumpster fire, with no attempt whatsoever at even a semblance of
functional release engineering, which causes enough pain already to us.


That may be the case, but this is not visible to users.
They will experience a bug in the Debian version, report it upstream, be 
rebuffed because they had the gall (!!) to use the Debian version 
instead of the upstream version, and then get redirected to upstream's 
package repository.


Most regular users would think at this point that the fault lies with 
the Debian project and simply install the upstream version instead.


This is a terrible user experience and does absolutely nothing to get 
broken subfeatures fixed in the Debian packages.



Absolutely not, the official Debian packages are following Debian
policy and best practices as they should, while upstream is a gigantic
mess and a security nightmare, so ask them instead.


This may be the case, but taking this stance doesn't get the mess fixed. 
As is evident in https://github.com/Azure/azure-cli/issues/19640 , 
upstream doesn't care about what their mess causes downstream, and they 
will simply continue "fixing" it in their own way.


Again: I'm trying to blame Debian Developers for broken packages, I'm 
trying to request a solution that does not result in a shitty user 
experience.

Bug#1034574: uscan: support OpenPGP signature verification without requiring a saved upstream signing key

[John Scott]

Package: devscripts
Version: 2.23.3
Severity: wishlist

I know if you're looking at the subject line alone you'll think I'm proposing 
introducing a security vulnerability, but let me explain.

There are some problems with storing an upstream signing key inside the 
package. It might get stale, not incorporating additional subkeys necessary for 
signature verification or revocations. Also, it requires manual work on the 
part of the maintainer and can't be done automatically.

Folks outside the OpenPGP ecosystem might not know this, but the Web of Trust 
is now not the only way of doing things. There are ways, like Web Key 
Directory, DANE, and LDAP, to not only discover an OpenPGP key, but also verify 
that it really belongs to the person in the user ID.

First, we save in some metadata file somewhere (debian/upstream/metadata?) the 
user IDs (aka names and email addresses) of upstream, or perhaps mappings of 
key IDs to email addresses. When uscan goes to verify the signature, it will 
know the key ID of the signer but might not know their user ID, so it will look 
in the mapping table.

Then it will fetch the key using an authenticated method and use it to verify 
the signature.

I hope that makes sense. Unfortunately I only know C, so I don't think I'll be 
able to contribute this.

Thanks

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBSIGN_KEYID=A23F3CA5BD39D9EB18AC7F35B3F4DD2861F4CDBA!
DEBSIGN_MAINT="John Scott"
BTS_MAIL_READER="evolution %s"
BTS_INTERACTIVE=yes
BTS_CACHE=yes
BTS_CACHE_MODE=full
DEBCOMMIT_SIGN_TAGS=yes
DEBCOMMIT_SIGN_COMMITS=yes
WHOUPLOADS_DATE=yes
DSCVERIFY_KEYRINGS=/home/john/.gnupg/pubring.kbx
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEBCHANGE_MULTIMAINT_MERGE=yes
DEBCHANGE_MAINTTRAILER=yes

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
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 devscripts depends on:
ii  dpkg-dev  1.21.21
ii  fakeroot  1.31-1.1
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
ii  gpgv  2.2.40-1.1
ii  libc6 2.36-8
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl    0.12-2
ii  libfile-which-perl    1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.68-1
ii  patchutils    0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.2-1
ii  sensible-utils    0.0.17+nmu1
ii  wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii  apt 2.6.0
ii  curl    7.88.1-7
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2022.12.24
ii  dput    1.1.3
ii  equivs  2.3.1
ii  libdistro-info-perl 1.5
ii  libdpkg-perl    1.21.21
ii  libencode-locale-perl   1.05-3
ii  libgit-wrapper-perl 0.048-2
ii  libgitlab-api-v4-perl   0.26-3
ii  liblist-compare-perl    0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-3
ii  libstring-shellquote-perl   1.04-3
ii  libtry-tiny-perl    0.31-2
ii  liburi-perl 5.17-1
ii  licensecheck    3.3.5-1
ii  lintian 2.116.3
ii  man-db  2.11.2-2
ii  patch   2.7.6-7
ii  pristine-tar    1.50
ii  python3-apt 2.5.3
ii  python3-debian  0.1.49
ii  python3-magic   2:0.4.26-3
ii  python3-requests    2.28.1+dfsg-1
ii  python3-unidiff 0.7.3-1
ii  python3-xdg 0.28-2
ii  strace  6.1-0.1
ii  unzip   6.0-28
ii  wget    1.21.3-1+b2
ii  xz-utils    5.4.1-0.2

Versions of packages devscripts suggests:
pn  adequate 
ii  at   3.2.5-1+b1
ii  autopkgtest  5.28
ii  bls-standalone   0.20151231+b1
ii  build-essential  12.9
ii  check-all-the-things 2017.05.20+nmu1
pn  cvs-buildpackage 
ii  debhelper    13.11.4
ii  diffoscope   238
ii  disorderfs   0.5.11-3
ii  dose-extra   7.0.0-1+b2
ii  duck 0.14.1
pn  elpa-devscripts  
ii  faketime 0.9.10-2.1
ii  gnuplot-x11 [gnuplot]    5.4.4+dfsg1-2+b2
ii  

Bug#1034573: note: Note not setting non-default database path

[Oliver Schode]

Package: note
Version: 1.3.26-3
Severity: normal
Tags: patch

Hey guys,

due to a mistake in the package provided config file, if copied as is,
changing the directory for the DBM backend has no effect.

/usr/share/doc/note/examples/noterc.gz:

60c60
< dbm::directory = ~/.notedbm  # directory
---
> dbm::dbname = ~/.notedbm  # directory

The package appears to be unmaintained, perhaps QA or the Debian Perl
Group could have a look into this.

Regards,
Oliver

Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)

[Simon Deziel]

You can override ExecStart= by first defining it empty like that:

[Service]
ExecStart=
ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS

HTH,
Simon

On 2023-04-17 23:20, J wrote:

Thank you so much, thats exactly what I was missing. I commented out the -p
in
ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS
in
/usr/lib/systemd/system/unbound.service

And now I have a pidfile back that I can use.
Unless there is any better way? I tried to override the unbound.service but
I'm not sure ExecStart= can be overrode.

On Sun, 16 Apr 2023 at 18:52, J  wrote:


Hi!
I'm having an issue where unbound is not creating the pid file
I've specified in unbound.conf `pidfile: "/run/unbound.pid"`
I also see that this path is hard coded in `/etc/init.d/unbound` as
`PIDFILE="/run/unbound.pid"`

The only thing that fixes it is commenting out `. /lib/lsb/init-functions`
in  `/etc/init.d/unbound` which is obviously not what I want to do

On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:


Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  unbound packagers 

If you wish to submit further information on this problem, please
send it to 1034...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1034085: spyder: Cursor jumps somewhere else after right-clicking → selecting Format with Black or Autopep8

[Amr Ibrahim]

Am 18.04.23 um 17:30 schrieb Julian Gilbey:

Would you be able to share the file you were editing when you did this 
screenshot? I'd like to see if I can reproduce it on my machine.



Attached is the file.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Created on Sat Mar 18 18:41:38 2023

@author: amr
"""


def solution(A):
# Implement your solution here
for a in range(1, 11, 1):
if a not in A:
if a > 0:
return a
else:
return 1


def puzzle1(a):
return a.count(19) == 2 and a.count(5) >= 3


# print(puzzle1([19, 19, 15, 5, 3, 5, 5, 2]))
# print(puzzle1([19, 15, 15, 5, 3, 3, 5, 2]))
# print(puzzle1([19, 19, 5, 5, 5, 5, 5]))


def puzzle2(a):
return len(a) == 8 and a.count(a[4]) == 3


# print(puzzle2([19, 19, 15, 5, 5, 5, 1, 2]))
# print(puzzle2([19, 15, 5, 7, 5, 5, 2]))
# print(puzzle2([11, 12, 14, 13, 14, 13, 15, 14]))
# print(puzzle2([19, 15, 11, 7, 5, 6, 2]))


def puzzle3(a):
return a > 4**4 and a % 34 == 4


# print(puzzle3(922))


def piles(num_of_piles):
list_of_piles = [num_of_piles]
for i in range(num_of_piles - 1):
list_of_piles.append(num_of_piles + 2)
num_of_piles += 2
return list_of_piles


def piles2(num_of_piles):
return [num_of_piles + 2 * i for i in range(num_of_piles)]


# print(piles2(2))
# print(piles2(10))
# print(piles2(3))
# print(piles2(17))


def strings(list_of_strings):
return (
list_of_strings[len(list_of_strings) - 2]
in list_of_strings[len(list_of_strings) - 1]
and list_of_strings[len(list_of_strings) - 2]
!= list_of_strings[len(list_of_strings) - 1]
)


# print(strings(["a", "abb", "sfs", "oo", "de", "sfde"]))
# print(strings(["a", "abb", "sfs", "oo", "ee", "sfde"]))
# print(
# strings(
# ["a", "abb", "sad", "ooaaesdfe", "sfsdfde", "sfsd", "sfsdf", "qwrew"]
# )
# )
# print(
# strings(
# [
# "a",
# "abb",
# "sad",
# "ooaaesdfe",
# "sfsdfde",
# "sfsd",
# "sfsdf",
# "qwsfsdfrew",
# ]
# )
# )


def list_of_ints(a):
if len(a) == 100:
for x in a:
if x in range(0, 1000, 10):
return True
else:
return False
else:
return False


# print(list_of_ints([0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200, 210, 220, 230, 240, 250, 260, 270, 280, 290, 300, 310, 320, 330, 340, 350, 360, 370, 380, 390, 400, 410, 420, 430, 440, 450, 460, 470, 480, 490,
# 500, 510, 520, 530, 540, 550, 560, 570, 580, 590, 600, 610, 620, 630, 640, 650, 660, 670, 680, 690, 700, 710, 720, 730, 740, 750, 760, 770, 780, 790, 800, 810, 820, 830, 840, 850, 860, 870, 880, 890, 900, 910, 920, 930, 940, 950, 960, 970, 980, 990]))
# print(list_of_ints([0, 20, 40, 60, 80, 100, 120, 140, 160, 180, 200, 220, 240, 260, 280, 300, 320, 340, 360, 380, 400, 420, 440, 460,
#   480, 500, 520, 540, 560, 580, 600, 620, 640, 660, 680, 700, 720, 740, 760, 780, 800, 820, 840, 860, 880, 900, 920, 940, 960, 980]))


def sum_of_ints(a, i):
return print(sum(a[:i]) == i)


# sum_of_ints([0, 1, 2, 3, 4, 5], 4)
# sum_of_ints([1, 1, 1, 1, 1, 1], 4)
# sum_of_ints([2, 2, 2, 2, 2], 4)


def split_strings(s):
import re

words = re.split(r"([ ,]+)", s)
print(words)


# split_strings("The dance, held in the school gym, ended at midnight.")


def list_of_distinct_ints(nums):
# return all([nums[i] != nums[i + 1] for i in range(len(nums)-1)]) and len(set(nums)) == 4

if len(set(nums)) == 4:
for i in range(len(nums) - 1):
if nums[i] != nums[i + 1]:
return True
else:
return False
else:
return False


# print(list_of_distinct_ints([1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4]))
# print(list_of_distinct_ints([1, 2, 3, 3, 1, 2, 3, 3, 1, 2, 3, 3, 1, 2, 3, 3]))
# print(list_of_distinct_ints([1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3]))


def test(combined):
li = []
st = ""
for s in combined.replace(" ", ""):
st += s
if st.count("(") == st.count(")"):
li.append(st)
st = ""
return li


# test('( ()) ((()()())) (()) ()')


def indices(list_of_nums, thres):
return [i for i, x in enumerate(list_of_nums) if x < thres]
# list_of_indices = []
# for i, x in enumerate(list_of_nums):
# if x < thres:
# list_of_indices.append(i)
# return list_of_indices


# print(indices([0, 12, 45, 3, 4923, 322, 105, 29, 15, 39, 55], 100))
# print(indices([0, 12, 4, 3, 49, 9, 1, 5, 3], 10))


def check_palindrome(list_of_strings):
return [x == x[::-1] for x in list_of_strings]
# list_of_bool = []
# for x in list_of_strings:
# list_of_bool.append(x == x[::-1])
# return list_of_bool


# print(check_palindrome(['palindrome', 

Bug#1034572: Add a unveil(3) implementation?

[Marco d'Itri]

Source: libbsd
Version: 0.11.7-4
Severity: wishlist

OpenBSD wrote a unveil(3) implementation for Linux based on landlock(7), 
maybe it is general enough that it could be added to libbsd:

https://github.com/rpki-client/rpki-client-portable/blob/master/compat/unveil_landlock.c

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034571: Gallium unstable on Gen 5 (likely also Gen 4), need legacy driver

[Fierelier OwO]

Package: libgl1-mesa-dri
Version: 22.3.6-1+deb12u1
Severity: important

I think the Gallium driver for older Intel graphics is a bit
undercooked, and should not be considered a silver bullet (stable)
yet. I've been experiencing issues with WineD3D, like flickering, bad
performance and application crashing that I didn't have before. Wine
Nine did not help my situation.

When I've curiously tried these drivers on another distro before (this
was year or two ago, when this driver was experimental), I was able to
use MESA_LOADER_DRIVER_OVERRIDE=i965, to fall back to the legacy
driver. However this isn't possible on Debian:
> libGL error: MESA-LOADER: failed to open i965: /usr/lib/dri/i965_dri.so: 
> cannot open shared object file: No such file or directory (search paths 
> /usr/lib/i386-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri, suffix _dri)
> libGL error: failed to load driver: i965

I've tried 'apt-file search i965_dri.so', but it gave me no result. I
think this driver should be shipped with Debian, and perhaps (?) even
be preferred over Gallium for Gen 5 and probably Gen 4. The Gallium
driver just didn't have the years upon years of fixings that the i965
driver had.

I suspect i965 is part of mesa-amber now.

Bug#1034570: ITP: node-y-codemirror -- node-yjs binding to a CodeMirror editor

[Yadd]

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

* Package name: node-y-codemirror
  Version : 3.0.1
  Upstream Contact: Kevin Jahns 
* URL : https://github.com/yjs/y-codemirror
* License : Expat
  Programming Lang: JavaScript
  Description : node-yjs binding to a CodeMirror editor

node-y-codemirror binds a Y.Text to a CodeMirror editor.
Features:
 * Sync CodeMirror editor
 * Shared Cursors
 * Shared Undo / Redo (each client has its own undo-/redo-history)
 * Successfully recovers when concurrents edit result in an invalid
   document schema

node-y-codemirror is a reverse dependency of JupyterLab. It will be
maintained under JS Team umbrella.

Bug#1034085: spyder: Cursor jumps somewhere else after right-clicking → selecting Format with Black or Autopep8

[Julian Gilbey]

On Sun, Apr 09, 2023 at 03:13:26PM +0200, Amr Ibrahim wrote:
> 
> Am 09.04.23 um 12:15 schrieb Julian Gilbey:
> > If you can take a screencast showing the behaviour you describe,
> > please do send it to this bug report and I will be able to investigate
> > further.
> 
> Hallo Julian,
> 
> I run Spyder on Wayland if that matters. A screencast is attached, and the
> file (~/.config/spyder-py3/config/spyder.ini) in case it helps.

Hello Amr,

Thanks for this and sorry for the slow reply.  I doubt Wayland makes
much of a difference, but this is strange behaviour which I thought
was fixed already.  Would you be able to share the file you were
editing when you did this screenshot?  I'd like to see if I can
reproduce it on my machine.

Best wishes,

   Julian

Bug#1034569: dolphin: very slow and cpu hungery for displaying thumbnails of CR3 raw image files

[Aron Xu]

Package: dolphin
Version: 5.103-2

Hi,

Dolphin gains the ability to display thumbnails of Canon's CR3 raw
image files through the updated libraw and kimageformats in bookworm,
but it is too slow and consumes too much CPU especially when the
directory has a number of image files and RAW preview is toggled on in
preference, the fans of my workstation are roaring constantly.

It looks to me that it's always trying to render the thumbnail from a
full RAW file, rather than using the embedded thumbnail (which is
commonly seen in RAW image formats). Darktable in bookworm, which is
also backed by libraw for CR3 support, is able to display the embedded
thumbnail.

Finally I'm not sure whether this report is suitable for dolphin or
kimageformat-plugins, please help reassign the proper package.

Thanks,
Aron

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Daniel Abrecht]

In my image builder, I just mount a tmpfs over /sys/firmware to hide it: 
https://github.com/Daniel-Abrecht/dpa-image-builder/blob/22a18b8108d07ef72595f5217fd196cd01ddb71f/script/chns#L100

An Image builder shouldn't mess with the hosts firmware anyway.

Bug#1025480: another manifestation of the problem with AVX-512 kernel, workarond

[Enzo Alberto Dari]

This bug was correctly retitled by the maintainer as related to the AVX-512
kernel.
However, it is filed against the libopenblas0-pthread debian package while
I have found another case that gives wrong results even using one thread.
The script solves a linear elasticity problem using the finite element
method in octave, the files are shared here:
https://drive.google.com/file/d/1xkw-1YfX3W-mfqD92I1fNYnQM78yA9Sy/view?usp=sharing
After building the system of linear equations, it is solved using the
octave operator "\", and by "lu" factorization, the results are checked by
computing the residual vectors (should have a norm around the truncation
error).

These are the results of the tests:
-Using defaults:
$ octave fem_lame2d.m
Residualbackslash = 17.947
ResidualLUPQbackslash = 7.2444

-Forcing sequential mode (1 thread):
$ OMP_NUM_THREADS=1 octave fem_lame2d.m
Residualbackslash = 17.947
ResidualLUPQbackslash = 7.2444

-Avoiding the use of the openblas AVX-512 kernel (working workaround !!):
$ OPENBLAS_CORETYPE=Haswell octave fem_lame2d.m
Residualbackslash = 1.4547e-13
ResidualLUPQbackslash = 1.4879e-13

-- 
Enzo A. Dari
Profesor Titular
Instituto Balseiro 

Bug#1016810: Bug#924667: qemu-user-static: setting up of binfmt_misc is slightly naive about cpu features

[Michael Tokarev]

Replying to 3 different bug reports all about the same theme.

With the upcoming version of qemu-user[-static] package, I'm shipping all
available binfmt entries, including the ones for the same-family arch and
even for native arch.

But the same-family-arch entries will go into /usr/share/doc/qemu-user-static/,
not to /usr/lib/binfmt.d/ where all other entries reside.

This way, the system will automatically enable only entirely foreign binfmt
formats by default, just like it does now.  But it is possible to symlink,
say, /usr/share/doc/qemu-user-static/qemu-x86_64.conf to
/etc/binfmt.d/qemu-x86_64.conf, and it will be enabled on a i386 system.

You have to be careful though, and not enable native format this way, as
it will break your system.

Thanks,

/mjt

Bug#1034319: debootstrap of foreign arch fails w/o recommended binfmt-support

[Michael Tokarev]

On Wed, 12 Apr 2023 17:58:38 -0400 Joey Hess  wrote:

Package: qemu-user-static
Version: 1:7.2+dfsg-5
Severity: normal

I got a new arm64 host at Hetzner, and needed an amd64 chroot in it.
Of course that's easy, since debootstrap --arch just works for foreign
arches with qemu-user-static installed.


I assume this is bullseye system, right?

..

If systemd by itself is supposed to somehow handle what binfmt-support
does, it did not work in my case. I had to install binfmt-support
and rerun /var/lib/dpkg/info/qemu-user-static.postinst to fix the
problem.


Did you try to restart systemd-binfmt service, or rebooting?

IIRC, systemd added triggers for /usr/lib/binfmt.d/ in a version
after bullseye one.

systemd (251.2-1) unstable; urgency=medium

  * Add dpkg file trigger for systemd-binfmt to update binfmt registrations

This stuff works just fine on bookworm or with systemd from
bullseye-backports. This is why I haven't bothered adding my
own triggers.

I guess this can be closed as fixed in version 251.2-1 :)

Thanks,

/mjt

Bug#1032902: Numba issues for genx for other architectures than amd64 and ppc64el (Was: genx won't start: TypeError: Pen(): arguments did not match any overloaded call)

[Andreas Tille]

Hi,

I've found genx in the "Cleaner view"[1] due to missing builds[2].
It turns out that for instance for arm64[3] the build fails with

   tests/test_numba_equivalency.py Fatal Python error: Segmentation fault

For armel[4] (and armhf) we get

   dh_auto_test -a -O--buildsystem=pybuild
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
python3.11 -m pytest tests
Fatal Python error: Aborted

Current thread 0xf7a30020 (most recent call first):
  File "/usr/lib/python3/dist-packages/llvmlite/binding/ffi.py", line 151 in 
__call__
  File "/usr/lib/python3/dist-packages/llvmlite/binding/executionengine.py", 
line 92 in finalize_object
  File "/usr/lib/python3/dist-packages/numba/core/codegen.py", line 1060 in 
wrapper
  File "/usr/lib/python3/dist-packages/numba/core/codegen.py", line 999 in 
_finalize_specific
  File "/usr/lib/python3/dist-packages/numba/core/codegen.py", line 797 in 
_finalize_final_module
  ...

For i386[5]

I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build; 
python3.11 -m pytest tests
= test session starts ==
platform linux -- Python 3.11.2, pytest-7.2.1, pluggy-1.0.0+repack
rootdir: /<>
collected 14 items / 1 error

 ERRORS 
_ ERROR collecting .pybuild/cpython3_3.11/build/tests/test_numba_equivalency.py 
_
tests/test_numba_equivalency.py:11: in 
from genx.models.lib import instrument, instrument_numba, paratt, 
paratt_numba, neutron_refl, neutron_numba, \
genx/models/lib/instrument_numba.py:9: in 
@numba.jit(
/usr/lib/python3/dist-packages/numba/core/decorators.py:219: in wrapper
disp.compile(sig)
/usr/lib/python3/dist-packages/numba/core/dispatcher.py:965: in compile
cres = self._compiler.compile(args, return_type)
   ...


and we have other errors for other architectures which all contain
the string "numba".  IMHO this is a mess we can hardly fix in hard
freeze.  I see only two chances:

   1. Restrict the architectures to amd64 and ppc64el (which are
  the only ones where the build succeeds or
   2. Remove the package from testing for the moment.  The only
  rdepends is currently pan-grazing-incidence which will be
  lowered to suggests once we re-render debian-pan metapackages.

What do you think?

Kind regards
Andreas.

[1] 

Bug#999526: Taking over package into Debian Python Team maintenance and fixing bug (Was: mdp: FTBFS with numpy 1.21 (in experimental): dh_auto_test: error: pybuild --test --test-pytest -i python{versi

[Andreas Tille]

Hi Yaroslav,

Am Mon, Apr 17, 2023 at 05:59:23PM -0400 schrieb Yaroslav Halchenko:
> Hi Andreas,
> 
> Thank you very much for offering help.  I think Tiziano would not mind,
> so please feel very welcome to a) for the sake of b) or any other
> goodness you would like to bring ;)

  
https://tracker.debian.org/news/1429393/accepted-mdp-36-2-source-into-unstable/
  https://salsa.debian.org/python-team/packages/mdp

> Note though that MDP is pretty much inactive project since a few years
> back.  It seems it is still used by some and somewhat maintained
> upstream, so might indeed be worthwhile keeping afloat in Debian but I
> would not cry if it got RMed.

We have some rdepends:

$ apt rdepends python3-mdp
python3-mdp
Reverse Depends:
  Recommends: pan-machine-learning
  Recommends: science-machine-learning
  Enhances: python3-sklearn
  Recommends: python3-pymca5
  Recommends: science-machine-learning

> After/if packaging moves to a new repo on salsa, we can submit a
> PR to add an empty out debian/ and add stub debian/README to that
> upstream repo to signal that packaging moved to salsa.

See above.  A finding that came unexpected after adding autopkgtest
is that 32bit architectures can't cope with 'float128', 'complex256'
data types.  Since I wanted to avoid further trouble in hard freeze
I decided to restrict architectures to 64bit for the moment.
 
Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1034568: binascii.Error: Odd-length string when asking the status

[Marek Küthe]

Package: ufw
Version: 0.36-7.1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
Adding a few rules:
ufw route allow in on {{ item }} from fd00::/8 to fd00::/8 comment
 'dnet' ufw route allow in on {{ item }} from 172.20.0.0/14 to
 172.20.0.0/14 comment 'dnet' ufw route allow in on {{ item }} from
 10.0.0.0/8 to 10.0.0.0/8 comment 'dnet' ufw route allow in on {{
 item }} from 10.0.0.0/8 to 172.20.0.0/14 comment 'dnet' ufw route
 allow in on {{ item }} from 172.20.0.0/14 to 10.0.0.0/8 comment
 'dnet' ufw route allow in on {{ item }} from
 2001:db8:dead:beef::/64 to 2001:db8:dead:beef::/64 comment 'dnet'
 ufw route allow in on {{ item }} from 172.24.0.0/16 to
 172.24.0.0/16 comment 'dnet'

and then ufw status
* What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
Traceback (most recent call last):
  File "/usr/sbin/ufw", line 147, in 
res = ui.do_action(pr.action, "", "", pr.force)
  File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 652, in
do_action res = self.get_status()
  File "/usr/lib/python3/dist-packages/ufw/frontend.py", line 261, in
get_status out = self.backend.get_status(verbose, show_count)
  File "/usr/lib/python3/dist-packages/ufw/backend_iptables.py", line
419, in get_status comment_str = " # %s" % r.get_comment()
  File "/usr/lib/python3/dist-packages/ufw/common.py", line 372, in
get_comment return ufw.util.hex_decode(self.comment)
  File "/usr/lib/python3/dist-packages/ufw/util.py", line 1104, in
hex_decode return binascii.unhexlify(h).decode('utf-8')
binascii.Error: Odd-length string

   * What outcome did you expect instead?

the normal ufw status

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


-- 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/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot
set LC_ALL to default locale: No such file or directory UTF-8),
LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ufw depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  iptables   1.8.7-1
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  ucf3.0043

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.2102.0-2+deb11u1

-- Configuration Files:
/etc/default/ufw changed:
IPV6=yes
DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"
DEFAULT_FORWARD_POLICY="ACCEPT"
DEFAULT_APPLICATION_POLICY="SKIP"
MANAGE_BUILTINS=no
IPT_SYSCTL=/etc/ufw/sysctl.conf
IPT_MODULES=""


-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_ADDRESS = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_MEASUREMENT = "de_DE.UTF-8",
LC_IDENTIFICATION = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
  ufw/existing_configuration:
  ufw/allow_known_ports:
  ufw/allow_custom_ports:
  ufw/enable: false

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_TIME = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_ADDRESS = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_MEASUREMENT = "de_DE.UTF-8",
LC_IDENTIFICATION = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").

-- 
Marek Küthe
m...@mk16.de
er/ihm he/him

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Lisandro Damián Nicanor Pérez Meyer]

Hi again

And tip: have you noticed that the default web engine for Konqueror is
actually Qt5's webengine?

On Tue, 18 Apr 2023 at 04:30, Bernhard Reiter  wrote:
>
> Hi,
>
> Am Dienstag 18 April 2023 04:55:35 schrieb Lisandro Damián Nicanor Pérez
> Meyer:
> > On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter 
> wrote:
>
> > > Konqueror is advertised as web browser, which means it will (offer to)
> > > open URLs from different sources, e.g. when clicked from emails which
> > > means external URLs and data.
> >
> > Same goes with KMail too :-)
>
> not really, KMail protects against just displaying external HTML
> code from mails, you need to explicitely enable it, e.g. by clicking.

Well, you are supposed to know what you are doing if you open a web browser :-)

> > Whatever uses webengine/webkit/ has the same
> > issue. Well, for as long as they are a pile of embedded code, at least
> > to start with.
>
> Only if they are exposed to unfiltered external data and having active code
> elements enabled like 

Bug#525849: (no subject)

[ETAYOUN Littlejohn]

Bug#1034551: kmod: Include iwlwifi.conf from Ubuntu

[Diederik de Haas]

On On Apr 18, Jamie Bainbridge  wrote:
> > > I can only assume from the massive Ubuntu install base that this file
> > > doesn't cause any problems for devices which don't need the modules
> > > loaded in this order, while also resolving whatever problem requires
> > > that modules are loaded in the order which the above file forces.

Forgot to add:
Ubuntu has their own kernel configuration and probably also their own (kernel) 
patches, so it seems a rather dangerous assumption that what (apparently) 
works for the Ubuntu kernel also (flawlessly) works on the Debian kernel.

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

Bug#1034567: bash-completion: Doesn't work for root in non-login shell (on default settings)

[Askar Safin]

Package: bash-completion
Version: 1:2.11-6
Severity: normal
X-Debbugs-Cc: safinas...@gmail.com

bash-completion (for example, "apt-get inst") doesn't work for root in
non-login shell on default settings. Completion works for normal users.
And completion works in login shells.



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

Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

-- no debconf information

Bug#1034378: Allow Percentage Formatting in apt

[Emir SARI]

Hello,

> David Kalnischkies  şunları yazdı (15 Nis 2023 15:31):
> 
> Hi,
> 
>> On Thu, Apr 13, 2023 at 11:49:01PM +0300, Emir SARI wrote:
>> The percentage formatting among different locales can vary. For instance, 
>> Turkish uses %100 style formatting, whereas French uses 100 %. There are 
>> also other languages that use varying styles like using non-break spaces 
>> between the sign and the number and else. However, the percentage values 
>> displayed in apt only uses a fixed format, such as 100%.
> 
> Can you give example(s) of the messages you refer to?

Yes, Progress message is one of them, and also there are percentages on each 
individual package and/or repository update string.

> These "%.0f%%" are indeed not marked for translation, but I am not sure
> if it is a good idea as they come without any explanation and show info
> pretty densely more or less to the benefit of "something is happening"
> rather than "here are all the details you could possibly ask for so you
> can refer back to this great knowledge forever".
> 
> Never the less I suppose we can put in the work to make them
> translatable (currently the formatting is hardcoded in a few places,
> that would need to be fixed).
> On the other hand, it seems pointless labour to make the string
> translatable if a similar translatable string isn't used in this way,
> so as a compromise I suggest a deal: I will see to implement it if
> a language team/translator asks for it here.

I have contacted Mr. Dirik, as he’s the current translator and CC’d him here. 
He said he is going to fix the Progress string, your help in i18n’sing other 
currently non-i18n percentages would be really appreciated and make it more 
coherent among all apt.


Thank you for your help.
Best regards,
Emir

Bug#1034551: kmod: Include iwlwifi.conf from Ubuntu

[Diederik de Haas]

Note: I do NOT speak on behalf of the kernel team.

On Tuesday, 18 April 2023 09:47:14 CEST Marco d'Itri wrote:
> On Apr 18, Jamie Bainbridge  wrote:
> > I have a laptop with iwlwifi wireless card:
> >  $ sudo lspci -nn | grep Net
> >  Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a]
> >  (rev 59)> 
> 
> > Ubuntu ships a file in its kmod package with the following contents:
> >  # /etc/modprobe.d/iwlwifi.conf
> >  # iwlwifi will dyamically load either iwldvm or iwlmvm depending on the
> >  # microcode file installed on the system.  When removing iwlwifi, first
> >  # remove the iwl?vm module and then iwlwifi.
> >  remove iwlwifi \
> >  (/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs
> >  /sbin/rmmod) \
> >  && /sbin/modprobe -r mac80211
> 
> > Adding this file to Debian resolves the problem.
> 
> > This is a request to include the above iwlwifi.conf file in Debian's
> > kmod package too.
> > 
> > I can only assume from the massive Ubuntu install base that this file
> > doesn't cause any problems for devices which don't need the modules
> > loaded in this order, while also resolving whatever problem requires
> > that modules are loaded in the order which the above file forces.
> > 
> > in the first place. It's been there for a very long time, at least since
> > kmod 9 from over 10 years ago.
> 
> Given also that Debian never shipped this, I would like to better
> understand why we should do it now.

So in order for the wifi device to work properly, the modules need to be loaded 
in a specific order? And this *workaround* does that?

If the kernel does not load modules in the right order, then that sounds like 
an upstream kernel bug which should be reported (upstream), so that it can be 
fixed properly.
Pampering over that for 10 YEARS sounds like the wrong 'solution'?

My 0.02

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

Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1

[Santiago R.R.]

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

Dear Release Team,

Please unblock package isc-dhcp

[ Reason ]

Two main reasons:
1. Include a NEWS entry to help users to be aware ISC DHCP Server has
been EOL'ed by upstream.

2. Solve https://bugs.debian.org/1034502 so dhclient can  handle
resolv.conf inside network namespaces. The proposed changes include an
autopkgtest to test this.

[ Impact ]

1. Less chances for the users to be aware of the end of upstream support
for a very important software.

2. Users or application using dhclient inside a network namespace would
continue to have issues with the DNS resolution.  See:
https://stackoverflow.com/questions/38102481/how-can-dhclient-be-made-namespace-aware

[ Tests ]
1. Doesn't really need a test. The NEWS entry would be displayed during
upgrading if apt-listchanges is available.

2. This is the autopkgtest included in this request applied to the
current version in testing:
https://salsa.debian.org/santiago/isc-dhcp/-/jobs/4144234#L324
And this is for the proposed version:
https://salsa.debian.org/santiago/isc-dhcp/-/jobs/4144350

[ Risks ]

1. There is no risk.

2. Code is trivial.

[ 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 ]
There is minor (and harmless) change:

  [ Bastian Germann ]
  * d/copyright Format: Add trailing slash

that I include since it was part of the default git branch. I keep it to
make it easier to handle changes in the future.

Also, I've uploaded these changes to experimental.

Thanks!

 -- Santiago

unblock isc-dhcp/4.4.3-P1-1.1
diff -Nru isc-dhcp-4.4.3-P1/debian/changelog isc-dhcp-4.4.3-P1/debian/changelog
--- isc-dhcp-4.4.3-P1/debian/changelog  2023-01-09 10:15:41.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/changelog  2023-04-17 14:20:02.0 +0200
@@ -1,3 +1,17 @@
+isc-dhcp (4.4.3-P1-2) unstable; urgency=medium
+
+  [ Gabriel Potter ]
+  * Support bound /etc/resolv.conf (Closes: #1034502)
+
+  [ Bastian Germann ]
+  * d/copyright Format: Add trailing slash
+
+  [ Santiago Ruano Rincón ]
+  * Add NEWS about isc-dhcp-server EOL'ed and its apparmor profile
+  * Test debian/tests/client-server
+
+ -- Santiago Ruano Rincón   Mon, 17 Apr 2023 14:20:02 
+0200
+
 isc-dhcp (4.4.3-P1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru isc-dhcp-4.4.3-P1/debian/copyright isc-dhcp-4.4.3-P1/debian/copyright
--- isc-dhcp-4.4.3-P1/debian/copyright  2023-01-09 09:25:59.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/copyright  2023-04-17 13:50:46.0 +0200
@@ -1,4 +1,4 @@
-Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Source: https://www.isc.org/downloads/dhcp
 
 Files: *
diff -Nru isc-dhcp-4.4.3-P1/debian/dhclient-script.linux 
isc-dhcp-4.4.3-P1/debian/dhclient-script.linux
--- isc-dhcp-4.4.3-P1/debian/dhclient-script.linux  2023-01-09 
09:27:37.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/dhclient-script.linux  2023-04-17 
13:50:46.0 +0200
@@ -84,7 +84,9 @@
chown --reference=$resolv_conf $new_resolv_conf
chmod --reference=$resolv_conf $new_resolv_conf
fi
-mv -f $new_resolv_conf $resolv_conf
+   # cat then rm to handle binds (e.g. ip netns exec)
+   cat $new_resolv_conf > $resolv_conf
+   rm -f $new_resolv_conf
 # DHCPv6
 elif [ -n "$new_dhcp6_domain_search" ] || [ -n "$new_dhcp6_name_servers" 
]; then
 resolv_conf=$(readlink -f "/etc/resolv.conf" 2>/dev/null) ||
@@ -115,7 +117,8 @@
 chown --reference=$resolv_conf $new_resolv_conf
 chmod --reference=$resolv_conf $new_resolv_conf
fi
-mv -f $new_resolv_conf $resolv_conf
+   cat $new_resolv_conf > $resolv_conf
+   rm -f $new_resolv_conf
 fi
 }
 
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS 
isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS   2023-01-09 
09:25:59.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS   2023-04-17 
13:50:46.0 +0200
@@ -1,3 +1,24 @@
+isc-dhcp-server (4.4.3-P1-2) unstable; urgency=medium
+
+  # ISC DHCP completely EOL
+
+  ISC has stopped maintaining the server component of isc-dhcp since October
+  2022. A similar decision was made for the client and relay parts earlier the
+  same year. ISC DHCP Server users are strongly encouraged to look for an
+  alternative.
+
+  More information can be found in these official announcements:
+  https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
+  https://www.isc.org/blogs/isc-dhcp-eol/
+
+  # AppArmor support
+
+  Since 4.4.3-P1-1.1, isc-dhcp-server includes an apparmor profile (thanks
+  

Bug#924788: /usr/bin/akonadictl: aKonadi server with postgreSQL backend fails to start after buster upgrade

[Hefee]

Control: tags -1 +moreinfo unreproducible 

Hey,

Sorry that I haven't found time to look to it further.

>From the file list it seems like you switched to from PostgresQL backend to 
Mysql backend by dist-upgrade and than started it. That removed all of the 
postgres cluster. Maybe the config that selected the PostgresQL was removed 
while the upgrade? I need more information in order to fix anything.

> I expect that aKonadi should be using postgreSQL 11, not 9.6, but that it
> will auto-migrate my data.

I don't know when this support was added to Akonadi, but bookworm will support 
for sure automatic upgrades to new PostgresQL versions.

Regards,

hefee


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

Bug#1034565: ftbfs tests fail on ppc64el and mips64el

[Pirate Praveen]

Package: ruby-prometheus-client-mmap
Version: 0.17.0+spec-1
Severity: serious
Control: forwarded -1 
https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/issues/43


Version in testing is not affected as we did not have tests enabled.

Failures:

  1) Prometheus::Client::Helper::MmapedFile file does not exist creates 
a file with minimum initial size
 Failure/Error: expect(File.size(subject.filepath)).to 
eq(subject.send(:initial_mmap_file_size))


   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/helpers/mmaped_file_spec.rb:30:in 
`block (3 levels) in '


  2) Prometheus::Client::MmapedDict#initialize empty mmap'ed file is 
initialized with correct size
 Failure/Error: expect(File.size(tmp_file.path)).to 
eq(tmp_mmaped_file.send(:initial_mmap_file_size))


   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/mmaped_dict_spec.rb:19:in `block (4 
levels) in '


  3) Prometheus::Client::MmapedDict#initialize mmap'ed file that is 
above minimum size is initialized with the a page size

 Failure/Error: expect(tmp_file.size).to eq(4096);

   expected: 4096
got: 16384

   (compared using ==)
 # ./spec/prometheus/client/mmaped_dict_spec.rb:34:in `block (4 
levels) in '


Full build logs 
https://buildd.debian.org/status/fetch.php?pkg=ruby-prometheus-client-mmap=ppc64el=0.19.1-1=1681745611=0 
https://buildd.debian.org/status/fetch.php?pkg=ruby-prometheus-client-mmap=mips64el=0.19.1-1=1681745649=0


Forwarded upstream at 
https://gitlab.com/gitlab-org/ruby/gems/prometheus-client-mmap/-/issues/43


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

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

[Alf]

As  Thomas Viehweger wrote, DVB support ist missing since upgrade to v 0.35.*.
It can be clearly seen by executing
mpv --list-protocols
"dvb://" is no longer included.
I searched all change.logs on Debian and also Upstream 
(https://github.com/mpv-player/mpv/releases) and I could not find any entry regarding 
removal/depreciation of dvb protocol. So it is definitely a regression and the severity 
of the bug should be raised to "serious".

Regards,
Alf

Bug#1034564: debbugs: "There is no record of Bug" after getting confirmation e-mail

[Askar Safin]

Package: debbugs
Severity: normal

I just reported bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034563 .

After some minutes I got confirmation e-mail titled "Bug#1034563:
Acknowledgement (login: "su" doesn't put /sbin and /usr/sbin to PATH)"

This e-mail contained a link " https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1034563 "

I clicked the link. And I saw a text:
==
Debian Bug report logs - #1034563
There is no record of Bug #1034563. Try the search page instead.
==
Then I updated the page and saw proper bug report page.

So I didn't saw bug report page immediately after clicking link from mail. This
is a bug



-- System Information:
Debian Release: 9.13
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: amd64 (x86_64)

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

Bug#1034230: fail2ban: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Pirate Praveen]

Control: tags -1 patch

On Tue, 11 Apr 2023 15:43:51 +0200 Andreas Henriksson 
 wrote:

> Wrong path is used at:
> https://sources.debian.org/src/fail2ban/1.0.2-1/debian/rules/#L50
>
> Note that the path will likely change again in the future, so rather
> than hard-coding a path please consider finding the path via:
> pkg-config --variable=systemdsystemunitdir systemd
>
> (Note: you'll need to build-dep on pkg-config and systemd, for
> systemd.pc)
>
> Regards,
> Andreas Henriksson
>
>

Attaching a patch, the git repo seems to be in an inconsistent 
state/diverged from the archive.


diff --git a/debian/control b/debian/control
index fe386199..0b8c5421 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,8 @@ Build-Depends:
  , python3-pyinotify
  , sqlite3
  , 2to3
+ , pkg-config
+ , systemd
 Homepage: https://www.fail2ban.org
 Vcs-Git: https://salsa.debian.org/python-team/packages/fail2ban.git
 Vcs-Browser: https://salsa.debian.org/python-team/packages/fail2ban
diff --git a/debian/rules b/debian/rules
index a2dd769c..3c0391ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,7 +16,7 @@ export PYBUILD_DISABLE_python2=1
 
 DESTDIR=$(CURDIR)/debian/fail2ban
 PYVERSION=$(shell py3versions -dv)
-
+SYSTEMD_SYSTEM_UNIT_DIR = $(shell pkg-config --variable=systemdsystemunitdir systemd)
 override_dh_clean:
 	rm -rf fail2ban.egg-info
 	-rm debian/fail2ban.init
@@ -45,11 +45,11 @@ override_dh_install:
 	install -d $(DESTDIR)/usr/share/bash-completion/completions
 	install -m 644 files/bash-completion $(DESTDIR)/usr/share/bash-completion/completions/fail2ban
 	: # Install systemd files
-	install -d $(DESTDIR)/usr/lib/systemd/system/
+	install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	install -d $(DESTDIR)/usr/lib/tmpfiles.d
-	install -m 644 build/fail2ban.service $(DESTDIR)/usr/lib/systemd/system
+	install -m 644 build/fail2ban.service $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	install -m 644 files/fail2ban-tmpfiles.conf $(DESTDIR)/usr/lib/tmpfiles.d
-	install -d $(DESTDIR)/usr/lib/systemd/system
+	install -d $(DESTDIR)$(SYSTEMD_SYSTEM_UNIT_DIR)
 	: # Install default jail enabler
 	install -m 644 debian/debian-files/jail.d_defaults-debian.conf $(DESTDIR)/etc/fail2ban/jail.d/defaults-debian.conf
 	dh_install

Bug#1034563: login: "su" doesn't put /sbin and /usr/sbin to PATH

[Askar Safin]

Package: login
Version: 1:4.13+dfsg1-1
Severity: normal
X-Debbugs-Cc: safinas...@gmail.com

Steps to reproduce:


user@92fe0070d0e9:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
user@92fe0070d0e9:~$ su
Password: 
root@92fe0070d0e9:/home/user# echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games


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

Kernel: Linux 5.10.0-0.deb9.21-amd64 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages login depends on:
ii  libaudit1   1:3.0.7-1.1+b3
ii  libc6   2.36-8
ii  libcrypt1   1:4.4.33-2
ii  libpam-modules  1.5.2-6
ii  libpam-runtime  1.5.2-6
ii  libpam0g1.5.2-6

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1034526: azure-cli: Better collaboration with upstream

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Mon, 17 Apr 2023 19:02:54 +0200 Gregor Riepl 
wrote:
> Package: azure-cli
> Version: 2.45.0-1
> Severity: important
> X-Debbugs-Cc: onit...@gmail.com
> 
> Dear Maintainer,
> 
> Upstream has had lots of bug reports due to discrepancies between the
version
> packaged in Debian and Ubuntu and Microsoft's own "official" Debian
packages:
> https://github.com/Azure/azure-cli/issues/19640

The only official Debian packages are what you find on debian.org and
its mirrors, third party repositories are unofficial by definition and
are to be used at one's own risk, especially like in this case where
due to very dubious and poor security practices employed means they are
basically attack vectors, that nobody who cares about security of their
systems should ever touch.

> Virtually all of these bugs were reported upstream instead of the
Debian
> project, causing fallout on their side, whilst the Debian packages
remain
> broken.

Debian packages are not broken, they are working fine, to the extent
permitted by extremely broken and messy upstream sources. Due to
upstream bugs outside of our control at times some subfeature might not
work, but there's nothing we can do about it, there's always something
broken in the upstream code.

> Please consider working closer together with upstream to reach the
same release
> quality, or (possibly) fix the bug reporting channel, so bugs
specific to the
> Debian version are reported where they belong (i.e. BTS and not
upstream's
> Github).

That is a bit rich, given upstream routinely ignores bug reports, pull
requests and so on, to the extent that I have given up even trying. The
"azure-sdk-for-python" upstream repository is an absolute disaster of a
dumpster fire, with no attempt whatsoever at even a semblance of
functional release engineering, which causes enough pain already to us.

> As an alternative, please consider renaming the Debian packages, so
there is
> less ambiguity which version is installed.

Absolutely not, the official Debian packages are following Debian
policy and best practices as they should, while upstream is a gigantic
mess and a security nightmare, so ask them instead.

-- 
Kind regards,
Luca Boccassi


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

Bug#969171: Again, not even looked at the real problem.

[Hefee]

Hey,

On Sonntag, 11. April 2021 20:18:51 CEST Eric Valette wrote:
> > I think it is not a bug of the package. But it is definitely not severity
> > grave as Akonadi is perfectly usable here in exact the same version
> > (usable to the extent Akonadi works reliable, but that is an upstream
> > issue). So downgrading severity to normal.
> 
> When only akonadi-backend-sqlite is installed as you can see in
> installed packages I find normal that the default config file is changed
> to use sqlite by default as I would expect that removing
> akonadi-backend-mysql would remove the mysql backend if it was used with
> a warning.
> 
> But apparently, you are more interested in having the package without
> bug than working to simplify your user's life.

We see this as a bug, too. Otherwise we would close this bug as invalid ;) 

Debian can't easily distinguish, if you only installed one backend or differnt 
ones. Well we could add logic to detect this, but that would be very error 
prune.

So the proper solution needs to be done upstream aka in Akonadi directly. 
Akonadi has no support to check what different backends are available but 
simply try to start mysql. And if you tried it once, than Akonadi has created 
a user config that selects the mysql database and it is outside our control to 
switch the backend. Because Debian packages are not allowed to touch any stuff 
in $HOME.

Never the less in future for trixie the situation needs to be improved, as 
Akonadi switched its default backend over to SQLite (see #1034561). Detecting 
available backends is becoming a bigger issue.

Any help from your side to fix the problem is highly welcome: merge request, 
upstream bug report, patch etc. Unfortunately the Debian maintainers team is a 
lot of work and not enough resources, to do all work.

Regards,

hefee

#1034561: https://bugs.debian.org/1034561

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

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

[Rod Webster]

Thanks for a prompt response. We used the alpha 2 ISO release. I had
checked sources.list. The two of us working on this were unaware that there
was a difference between non-free-firmware and non-free. non-free-firmware
is not mentioned as a component on the debian wiki
https://wiki.debian.org/SourcesList   But
the examples for bookworm show the use of non-free-firmware so it's no
wonder we were confused. Could the documentation team amend the wiki to
clarify the changes and the differences between non-free and
non-free-firmware components? I'm sure this will be a source of confusion
moving forward.

In any case, this is a side issue and we await a response from the kernel
team in relation to the latency issue with the R8169 module under
PREEMPT_RT.





On Tue, 18 Apr 2023 at 18:13, Andreas Beckmann  wrote:

> Control: tag -1 - newcomer
> Control: retitle -1 excessive network latency with PREEMPT_RT kernel
> without the r8168-dkms driver
> Control: reassign -1 src:linux
>
> On 18/04/2023 04.12, Rod Webster wrote:
> > Package: r8168-dkms
>
> > We are linuxcnc users which is packaged in Bookworm. Linuxcnc requires
> the
> > PREEMPT_RT real time kernel as a prerequisite. We have found excessive
> latency
> > in the real time environment since Debian moved to the 5.x kernels.  We
> note
> ...
>
> I'm reassigning this bug to the linux kernel package, as this is not an
> issue in the r8168 driver.
>
> > We are no longer able to locate the R8168-dkms driver in the
> repositories,
> > despite it being listed as available in package search. We have
> downloaded a
> > .deb file from the Sid packages to install the correct driver.
>
> >   3. The R8168-dkms driver to continue to be made available in the
> Bookworm
> > repositories.
>
> The r8168-dkms package is in non-free - do you have that enabled?
>
>
> Andreas
>

Bug#1034551: kmod: Include iwlwifi.conf from Ubuntu

[Marco d'Itri]

On Apr 18, Jamie Bainbridge  wrote:

I would like to have feedback from the kernel team about this proposed 
change.

> I have a laptop with iwlwifi wireless card:
> 
>  $ sudo lspci -nn | grep Net
>  Network controller [0280]: Intel Corporation Wireless 7265 [8086:095a] (rev 
> 59)
> 
> This hardware requires the firmware-iwlwifi package, and the firmware
> works fine. However, on nonfree install or nonfree Live, the wireless
> interface repeatedly dies as soon as it's used with "Microcode SW error
> detected. Restarting" in dmesg and long firmware dump from the driver.
> it's not possible to even "apt update" because the interface dies.
So does the firmware work or not?

> Ubuntu ships a file in its kmod package with the following contents:
> 
>  # /etc/modprobe.d/iwlwifi.conf
>  # iwlwifi will dyamically load either iwldvm or iwlmvm depending on the
>  # microcode file installed on the system.  When removing iwlwifi, first
>  # remove the iwl?vm module and then iwlwifi.
>  remove iwlwifi \
>  (/sbin/lsmod | grep -o -e ^iwlmvm -e ^iwldvm -e ^iwlwifi | xargs
>  /sbin/rmmod) \
>  && /sbin/modprobe -r mac80211
But why then also unload mac80211?

> Adding this file to Debian resolves the problem.
But why? At no point you described something or somebody requesting that
iwlwifi is unloaded.

> This is a request to include the above iwlwifi.conf file in Debian's
> kmod package too.
> 
> I can only assume from the massive Ubuntu install base that this file
> doesn't cause any problems for devices which don't need the modules
> loaded in this order, while also resolving whatever problem requires
> that modules are loaded in the order which the above file forces.
> 
> I could not find any previous bug with this request. I also couldn't
> find Ubuntu's history of this package to find why it was included there
> in the first place. It's been there for a very long time, at least since
> kmod 9 from over 10 years ago.
So I am not very comfortable with adding code whose purpose and origin 
is unclear.

> Given that Ubuntu has shipped this file for so long, the risk of any
> regression in Debian seems extremely low.
Given also that Debian never shipped this, I would like to better 
understand why we should do it now.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1034392: Acknowledgement (tomcat9: jstack/jcmd broken for non-root users with tomcat9+jdk11 or greater)

[Per Lundberg]

Hi,

A short update on this. This is a known regression in more recent 
versions of Java: https://bugs.openjdk.org/browse/JDK-8226919


One of my colleagues (thanks, Sebastian!) managed to workaround this by 
patching the JDK 17 sources to make it use plain /tmp in this case (when 
ns_pid == pid), and also added some better error handling in case this 
fails.


We are currently working on getting this submitted upstream to OpenJDK, 
but I wanted to share it with you as well. One option would be to 
include this in Debian's set of local JDK patches 
(https://salsa.debian.org/openjdk-team/openjdk/-/tree/master/debian/patches), 
but I don't know how conservative the project is re. fixes like this? 
I'll leave this up to the debian-java maintainers to decide.


Best regards,
Per--- a/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
+++ b/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
@@ -209,11 +209,8 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 }
 
 // Return the socket file for the given process.
-private File findSocketFile(int pid, int ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-String root = "/proc/" + pid + "/root/" + tmpdir;
+private File findSocketFile(int pid, int ns_pid) throws IOException {
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 return new File(root, ".java_pid" + ns_pid);
 }
 
@@ -229,21 +226,33 @@ public class VirtualMachineImpl extends HotSpotVirtualMachine {
 // Do not canonicalize the file path, or we will fail to attach to a VM in a container.
 f.createNewFile();
 } catch (IOException x) {
-String root;
-if (pid != ns_pid) {
-// A process may not exist in the same mount namespace as the caller.
-// Instead, attach relative to the target root filesystem as exposed by
-// procfs regardless of namespaces.
-root = "/proc/" + pid + "/root/" + tmpdir;
-} else {
-root = tmpdir;
-}
+String root = findTargetProcessTmpDirectory(pid, ns_pid);
 f = new File(root, fn);
 f.createNewFile();
 }
 return f;
 }
 
+private String findTargetProcessTmpDirectory(int pid, int ns_pid) throws IOException {
+String root;
+if (pid != ns_pid) {
+// A process may not exist in the same mount namespace as the caller.
+// Instead, attach relative to the target root filesystem as exposed by
+// procfs regardless of namespaces.
+String procRootDirectory = "/proc/" + pid + "/root";
+if (!Files.isReadable(Path.of(procRootDirectory))) {
+throw new IOException(
+String.format("Unable to access root directory %s " +
+  "of target process %d", procRootDirectory, pid));
+}
+
+root = procRootDirectory + "/" + tmpdir;
+} else {
+root = tmpdir;
+}
+return root;
+}
+
 /*
  * Write/sends the given to the target VM. String is transmitted in
  * UTF-8 encoding.

Bug#1034524: libretro-bsnes-mercury: uses invalid architecture wildcards

[Graham Inggs]

Hi Jonathan

On Tue, 18 Apr 2023 at 09:36, Jonathan McDowell  wrote:
> This is an unfortunate mistake on my part, but given the stage we're at
> in the release process, the fact these are leaf packages and the fact
> the packages didn't ship as part of bullseye I don't think this counts
> as release critical.

It's your call, but if you uploaded a fix for this issue, I would
gladly unblock it.

Please consider this a release team unblock pre-approval.

Regards
Graham

Bug#1034561: akonadi-server: Switch default Akonadi backend to SQLite

[Hefee]

Package: akonadi-server
Version: 4:22.12.3-1
Severity: normal
X-Debbugs-Cc: he...@debian.org


Hey,

Upstream has changed their support for akonadi backends. Nowadays they
recommend to use SQLite, Postgres and MySQL/MariaDB is not really
recommend anymore. So we should change the Depends line for
akonadi-server, after bullseye has been released.


--  Forwarded Message  --

Subject: Re: Is SQLite3 still not recommended?
Date: Tuesday, 4. April 2023, 09:25:31 CEST
Link: https://mail.kde.org/pipermail/kde-pim/2023-April/049426.html

Hi,

I think SQLite is a good choice these days. SQLite has made huge
progress in the past many years since its support has been introduced to
Akonadi. The documentation on wiki is certainly not up-to-date.

While I was a big advocate for pushing PostgreSQL as the default backend
for Akonadi in the past, I think nowadays going for anything else than
SQLite as the default backend is silly. Especially with today's fast SSD
drives, I don't think a regular user will notice any difference, it
might actually turn out to be the fastest solution overall.

Coincidentally, I recently learned that the SQLite shared cache mode,
which Akonadi uses, has been deprecated for a while and WAL mode is now
recommended for most usecases, so that's something to look into. There
might be more new features in SQLite that have been introduced in the
past years that Akonadi could leverage for better performance.

Bug#1034560: ITP: juicefs -- A distributed POSIX file system built on top of Redis and S3.

[Herald Yu]

Package: wnpp
Severity: wishlist
Owner: Herald Yu 
X-Debbugs-Cc: debian-de...@lists.debian.org, yuhr...@gmail.com

* Package name: juicefs
  Version : 1.0.4
  Upstream Author : Juicedata 
* URL : https://juicefs.com/
* License : Apache-2.0
  Programming Lang: Go
  Description : JuiceFS is a high-performance POSIX file system released 
under Apache License 2.0, particularly designed for the cloud-native 
environment. The data, stored via JuiceFS, will be persisted in object storage 
(e.g. Amazon S3), and the corresponding metadata can be persisted in various 
database engines such as Redis, MySQL, and TiKV based on the scenarios and 
requirements.


 - JuiceFS is a popular open-source software on Github, with over 7800 stars. 
Its value lies in its ability to combine object storage and databases into a 
massive file system that can be accessed through interfaces such as FUSE, S3 
API, HDFS API, WebDAV, etc. It has a good caching mechanism that can solve the 
network latency problem of object storage.
 - JuiceFS does not rely on any third-party software packages. When mounted 
through the POSIX API, it will depend on FUSE that is already pre-installed in 
the system.
 - Similar software to JuiceFS includes S3FS, Alluxio, CephFS, and S3QL. Each 
has its own strengths in terms of functionality and features. There is a 
detailed comparison available in its documentation at 
https://github.com/juicedata/juicefs
 - I am willing to maintain this software package, but this is my first time 
participating in Debian's package maintenance and I have applied to join the Go 
packaging team.
 - Meanwhile, I hope to find a sponsor.

Bug#1034559: ITP: sphinx-favicon -- Sphinx Extension adding support for custom favicons

[Gianfranco Costamagna]

Package: wnpp
Severity: wishlist
Owner: Gianfranco Costamagna 

* Package name: sphinx-favicon
  Version : 1.0.1
  Upstream Author :  >
* URL :
* License : MIT
  Programming Lang: Python
  Description : Sphinx Extension adding support for custom favicons

Binary package names: python3-sphinx-favicon


 A Sphinx extension to add custom favicons
 .
 With Sphinx Favicon, you can add custom favicons to your Sphinx html
 documentation quickly and easily.
 .
 You can define favicons directly in your `conf.py`, with different `rel`
 attributes such as [`"icon"`]
 or [`"apple-touch-icon"`] and any favicon size.
 .
 The Sphinx Favicon extension gives you more flexibility than the standard
 `favicon.ico` supported by Sphinx. It provides a quick and easy way to add
 the most important favicon formats for different browsers and devices.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034524: libretro-bsnes-mercury: uses invalid architecture wildcards

[Jonathan McDowell]

Control: severity -1 important

On Mon, Apr 17, 2023 at 05:32:06PM +0100, Graham Inggs wrote:
> Source: libretro-bsnes-mercury
> Version: 094+git20220807-6
> Severity: serious
> 
> Hi Maintainer
> 
> Since the upload of 094+git20220807-6, the
> kodi-game-libretro-bsnes-mercury-* binary packages are no longer built
> on armel and armhf [1][2][3].  This is due to the use of invalid
> architecture wildcards 'any-armel' and 'any-armhf'.  These should be
> replaced by 'any-arm' for each of three

This is an unfortunate mistake on my part, but given the stage we're at
in the release process, the fact these are leaf packages and the fact
the packages didn't ship as part of bullseye I don't think this counts
as release critical.

> kodi-game-libretro-bsnes-mercury-* binary packages in debian/control,
> as follows:
> 
> -Architecture: any-amd64 any-arm64 any-armel any-armhf any-i386
> any-powerpc any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64
> 
> +Architecture: any-amd64 any-arm64 any-arm any-i386 any-powerpc
> any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64
> 
> Regards
> Graham
> 
> 
> [1] 
> https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-accuracy
> [2] 
> https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-balanced
> [3] 
> https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-performance

J.

-- 
... If we sleep together, will you like me better?

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

[Andreas Beckmann]

Control: tag -1 - newcomer
Control: retitle -1 excessive network latency with PREEMPT_RT kernel without 
the r8168-dkms driver
Control: reassign -1 src:linux

On 18/04/2023 04.12, Rod Webster wrote:

Package: r8168-dkms



We are linuxcnc users which is packaged in Bookworm. Linuxcnc requires the
PREEMPT_RT real time kernel as a prerequisite. We have found excessive latency
in the real time environment since Debian moved to the 5.x kernels.  We note

...

I'm reassigning this bug to the linux kernel package, as this is not an
issue in the r8168 driver.


We are no longer able to locate the R8168-dkms driver in the repositories,
despite it being listed as available in package search. We have downloaded a
.deb file from the Sid packages to install the correct driver.



  3. The R8168-dkms driver to continue to be made available in the Bookworm
repositories.


The r8168-dkms package is in non-free - do you have that enabled?


Andreas

Bug#1034256: Workaround

[Elcan Osmanov]

After further investigation I have found two workarounds.

go into /home/username/.config/mpv/mpv.conf and add either --ao=pulse or
--pulse-latency-hacks=yes it will solve the problem.

I hope the devs will solve the problem before the stable release.

source. 

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Hi,

Am Dienstag 18 April 2023 04:55:35 schrieb Lisandro Damián Nicanor Pérez 
Meyer:
> On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter  
wrote:

> > Konqueror is advertised as web browser, which means it will (offer to)
> > open URLs from different sources, e.g. when clicked from emails which
> > means external URLs and data.
>
> Same goes with KMail too :-)

not really, KMail protects against just displaying external HTML
code from mails, you need to explicitely enable it, e.g. by clicking.

> Whatever uses webengine/webkit/ has the same
> issue. Well, for as long as they are a pile of embedded code, at least
> to start with.

Only if they are exposed to unfiltered external data and having active code 
elements enabled like 

Bug#1034558: rnp: CVE-2023-29479 VE-2023-29480

[Salvatore Bonaccorso]

Source: rnp
Version: 0.16.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 




*** /tmp/rnp.reportbug
Package: rnp
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for rnp, [0] and [1]. The
first one was as well affecting mentioned in the recent thunderbird
mfsa.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-29479
https://www.cve.org/CVERecord?id=CVE-2023-29479
[1] https://security-tracker.debian.org/tracker/CVE-2023-29480
https://www.cve.org/CVERecord?id=CVE-2023-29480
[2] https://www.rnpgp.org/blog/2023-04-13-rnp-release-0-16-3/

Regards,
Salvatore

Bug#1034557: ITP: node-juggle-resize-observer -- Minimal JavaScript library which polyfills the ResizeObserver API

[Yadd]

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

* Package name: node-juggle-resize-observer
  Version : 3.4.0
  Upstream Contact: https://juggle.studio/resize-observer/issues
* URL : https://juggle.studio/resize-observer/
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Minimal JavaScript library which polyfills the 
ResizeObserver API

@juggle/resize-observer provides a minimal library which polyfills the
ResizeObserver API and is entirely based on the latest Draft Specification.

It immediately detects when an element resizes and provides accurate sizing
information back to the handler.

node-juggle-resize-observer is a dependency of @blueprintjs/* modules,
which are dependencies of JupyterLab.

This package will be maintained under JS Team umbrella.

Bug#862077: Is pngnq-s9 still active ?

[肖盛文]

Hi,

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


https://sf.net/projects/pngnqs9  also has no update for many years.

Is pngnq-s9 still active ?

--
肖盛文 xiao sheng wen
https://www.atzlinux.com  《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa:https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034555: unblock: fluidsynth/2.3.1-2

[Fabian Greffrath]

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

Please unblock package fluidsynth

[ Reason ]
This revision fixes a regression that was introduced upstream between
the 2.3.0 and 2.3.1 releases and has been fixed in the 2.3.2 release.

[ Impact ]
The regression introduced a multi-second gap between looping MIDI
tracks. Since fluidsynth is the default renderer for MIDI music in
SDL2, this will affect *a lot* of games in Debian.

[ Tests ]
n/a

[ Risks ]
None, I'd say. The fix has been backported from the upstream GIT
repository and is in the 2.3.2 version, which has already been
released. The output of `git show -w c0e2ef` on the commit in question
has three lines of code changes, the rest is indentation:

--- a/src/midi/fluid_midi.c
+++ b/src/midi/fluid_midi.c
@@ -2179,6 +2179,8 @@ fluid_player_callback(void *data, unsigned int msec)
 fluid_atomic_int_set(>seek_ticks, -1); /* clear seek_ticks 
*/
 }
 
+if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+{
 /* Once we've run out of MIDI events, keep playing until no voices 
are active */
 if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
 {
@@ -2207,6 +2209,7 @@ fluid_player_callback(void *data, unsigned int msec)
 {
 status = FLUID_PLAYER_PLAYING;
 }
+}
 
 /* Once there's no reason to keep playing, we're actually done */
 if(status == FLUID_PLAYER_DONE)


[ 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 ]
n/a

unblock fluidsynth/2.3.1-2
diff -Nru fluidsynth-2.3.1/debian/changelog fluidsynth-2.3.1/debian/changelog
--- fluidsynth-2.3.1/debian/changelog   2022-12-30 16:10:11.0 +0100
+++ fluidsynth-2.3.1/debian/changelog   2023-04-18 07:48:30.0 +0200
@@ -1,3 +1,11 @@
+fluidsynth (2.3.1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Apply patch from upstream to fix seamless looping between MIDI
+files.
+
+ -- Fabian Greffrath   Tue, 18 Apr 2023 07:48:30 +0200
+
 fluidsynth (2.3.1-1) unstable; urgency=medium
 
   * New upstream version 2.3.1
diff -Nru 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
--- 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
  1970-01-01 01:00:00.0 +0100
+++ 
fluidsynth-2.3.1/debian/patches/0046-Fix-seamless-looping-between-MIDI-files.patch
  2023-04-18 07:47:25.0 +0200
@@ -0,0 +1,76 @@
+From c0e2ef4243b83f29620b2078fc0f1198bafd7d90 Mon Sep 17 00:00:00 2001
+From: derselbst 
+Date: Sun, 2 Apr 2023 17:31:24 +0200
+Subject: [PATCH 46/49] Fix seamless looping between MIDI files
+
+Fixes #1227
+---
+ src/midi/fluid_midi.c | 45 +++
+ 1 file changed, 24 insertions(+), 21 deletions(-)
+
+diff --git a/src/midi/fluid_midi.c b/src/midi/fluid_midi.c
+index 0676c452..b72c3914 100644
+--- a/src/midi/fluid_midi.c
 b/src/midi/fluid_midi.c
+@@ -2178,34 +2178,37 @@ fluid_player_callback(void *data, unsigned int msec)
+ player->start_msec = msec;  /* should be the (synth)-time of 
the last tempo change */
+ fluid_atomic_int_set(>seek_ticks, -1); /* clear 
seek_ticks */
+ }
+-
+-/* Once we've run out of MIDI events, keep playing until no voices 
are active */
+-if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
++
++if(fluid_list_next(player->currentfile) == NULL && player->loop == 0)
+ {
+-/* The first time we notice we've run out of MIDI events but 
there are still active voices, disable all hold pedals */
+-if(!player->end_pedals_disabled)
++/* Once we've run out of MIDI events, keep playing until no 
voices are active */
++if(status == FLUID_PLAYER_DONE && 
fluid_synth_get_active_voice_count(player->synth) > 0)
+ {
+-for(i = 0; i < synth->midi_channels; i++)
++/* The first time we notice we've run out of MIDI events but 
there are still active voices, disable all hold pedals */
++if(!player->end_pedals_disabled)
+ {
+-fluid_synth_cc(player->synth, i, SUSTAIN_SWITCH, 0);
+-fluid_synth_cc(player->synth, i, SOSTENUTO_SWITCH, 0);
++for(i = 0; i < synth->midi_channels; i++)
++{
++fluid_synth_cc(player->synth, i, SUSTAIN_SWITCH, 0);
++

Bug#1034554: internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[Mathieu Malaterre]

Source: gcc-13
Version:  13-20230411-1

I cannot compile highway on riscv/rv64gcv1p0 with gcc-13.

Compilation fais with:

% /usr/bin/g++-13 -freport-bug -DHWY_SHARED_DEFINE
-I"/home/malat/highway-1.0.4~git20230317.8681eb8" -g -O2
-ffile-prefix-map=/home/malat/highway-1.0.4~git20230317.8681eb8=.
-fstack-protector-strong -Wformat -Werror=format-security
-DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE
-fvisibility=hidden -fvisibility-inlines-hidden
-Wno-builtin-macro-redefined -D__DATE__=\"redacted\"
-D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\"
-fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion
-Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions
-march=rv64gcv1p0 -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD
-MT CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o
-MF CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o.d
-o CMakeFiles/transform_test.dir/hwy/contrib/algo/transform_test.cc.o
-c 
'/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc'
during RTL pass: vsetvl
/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc:
In function 'void
hwy::N_RVV::ForeachCountAndMisalign::operator()(T, D) const
[with T = unsigned char; D = hwy::N_RVV::Simd;
Test = hwy::N_RVV::TestGenerate]':
/home/malat/highway-1.0.4~git20230317.8681eb8/hwy/contrib/algo/transform_test.cc:133:3:
internal compiler error: in finalize_new_accesses, at
rtl-ssa/changes.cc:471
  133 |   }
  |   ^
0xf4b18d rtl_ssa::function_info::finalize_new_accesses(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:471
0xf4c0a7 
rtl_ssa::function_info::change_insns(array_slice)
../../src/gcc/rtl-ssa/changes.cc:659
0xb4f1e7 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&)
../../src/gcc/rtl-ssa/changes.cc:717
0xb4f1e7 change_insn
../../src/gcc/config/riscv/riscv-vsetvl.cc:1028
0xb4f1e7 pass_vsetvl::cleanup_insns() const
../../src/gcc/config/riscv/riscv-vsetvl.cc:3951
0xb59891 pass_vsetvl::lazy_vsetvl()
../../src/gcc/config/riscv/riscv-vsetvl.cc:4211
0xb59a7d pass_vsetvl::execute(function*)
../../src/gcc/config/riscv/riscv-vsetvl.cc:4241
0xb59a7d pass_vsetvl::execute(function*)
../../src/gcc/config/riscv/riscv-vsetvl.cc:4222
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

Bug#1034553: libplist FTCBFS for arm32: wrong python library directory

[Helmut Grohne]

Source: libplist
Version: 2.2.0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libplist fails to cross build from source for arm32, because it gets the
python library directory wrong and uses the build architecture one. It
extracts it from sysconfigdata, so we need to export
_PYTHON_SYSCONFIGDATA_NAME to fix that. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru libplist-2.2.0/debian/changelog 
libplist-2.2.0/debian/changelog
--- libplist-2.2.0/debian/changelog 2021-02-03 13:59:02.0 +0100
+++ libplist-2.2.0/debian/changelog 2023-04-18 07:53:04.0 +0200
@@ -1,3 +1,10 @@
+libplist (2.2.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix arm32 FTCBFS: Export _PYTHON_SYSCONFIGDATA_NAME. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 18 Apr 2023 07:53:04 +0200
+
 libplist (2.2.0-6) unstable; urgency=medium
 
   [ Dylan Aïssi ]
diff --minimal -Nru libplist-2.2.0/debian/rules libplist-2.2.0/debian/rules
--- libplist-2.2.0/debian/rules 2021-02-03 13:59:02.0 +0100
+++ libplist-2.2.0/debian/rules 2023-04-18 07:53:02.0 +0200
@@ -10,6 +10,7 @@
 
 include /usr/share/dpkg/default.mk
 
+export 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}
 PYVER=$(shell py3versions -vd)
 
 %:

Bug#1030223: gobject-introspection mini-policy: separate GIR XML from -dev package to make cross-compilation possible?

[Helmut Grohne]

Hi Simon,

On Wed, Feb 01, 2023 at 10:39:30AM +, Simon McVittie wrote:
> Ideally, when cross-compiling Flatpak, we'd prefer to build it with
> a build profile like cross or nogir that has the effect of building it with
> ./configure --disable-introspection, which disables the generation of the
> files marked [*]. However, that would make this build profile cause a
> functional change to the contents of libflatpak-dev, which is strongly
> discouraged.

I agree in principle. The problem with changing the contents of
libflatpak-dev is twofold. For one thing, a binary package name (such as
libflatpak-dev) implicitly defines an interface and a contract between
cooperating packages. The present interface includes the gir files and
having them vanish from libflatpak-dev on specifying a nogir profile
would break the interface contract. The other reason for the
discouragement is being able to validate profiles using reproducible
builds.

> If we separated the GIR XML into a new binary package, perhaps named
> gir1.2-flatpak-1.0-dev or something like that, then we would be able to
> turn off both gir1.2-flatpak-1.0 and gir1.2-flatpak-1.0-dev under the
> nogir build profile (similar to how the noudeb, nocil and noinsttest
> profiles work), making cross-compilation possible (as long as you don't
> care about GObject-Introspection-based language bindings).

Such separation solves both the interface contract and the
reproducibility aspect. Let me propose another alternative. Rather than
have gir1.2-flatpak-1.0-dev be a real binary package, we can provide it
as a virtual one from libflatpak-dev. The mini-policy would then have to
be updated such that using the gir files requires depending on a
gir*-dev package and that a dependency on the regular lib*-dev package
is insufficient. When enabling the nogir profile, the virtual package is
removed thus no interface is broken. This variant still breaks
reproducibility of course.

> I think this would require changes to dependent packages if they make
> use of the GIR XML (because build-depending on libflatpak-dev would
> no longer be enough, and it would also be necessary to build-depend on
> gir1.2-flatpak-1.0-dev  or similar). If so, this would have to
> be done on a package-by-package basis, with dependent packages changed
> before their dependency. A migration path would be to add
> Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) on libflatpak-dev.

In essence, I am saying that this migration path could be the final
result thus eliminating the NEW trip, but not eliminating the need to
update dependent packages. Note that dpkg resolves profiles in binary
package relations at build time, so you can write:

Provides: gir1.2-flatpak-1.0-dev (= ${binary:Version}) 

> A side benefit of this would be that we could separate out the GIR XML
> that is provided by src:gobject-introspection (#859013) into one or more
> similar gir1.2-*-dev packages.

Of course, a separation by real binary packages would not be prohibited.

In your second mail, you propose storing pre-built gir files in debian/.
I dislike this proposal, because it poses continuous extra effort for
maintainers. We already struggle with symbols files and shouldn't add
another variant of them. I understand that this looks attractive from a
cross builder's point of view, but I think cross building should bear
the effort here, not gnome package maintainers. I hope you can agree
with that.

Given this, would you agree that nogir would make sense right now as a
non-reproducible profile? It still requires updating all reverse
dependencies, yeah, but we can do so in parallel. For the migration
period, we would have missing dependencies in the presence of nogir
profiles, but these would solely affect users of the nogir profile,
which would be the ones to report and fix such missing dependencies.
Regular users (and buildds in particular) would never experience issues
due to such missing dependencies.

Helmut