Bug#1007764: gcc-defaults: please support DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi,

On Wed, 16 Mar 2022 13:30:26 +0100 Johannes Schauer Marin Rodrigues 
 wrote:
> when creating chroots for new architectures that are in the process of being
> bootstrapped without yet having emulation support from qemu, it is not
> possible to run maintainer scripts inside the foreign architecture chroot
> because foreign architecture ELF binaries cannot be executed. The solution to
> that problem is to run maintainer scripts from outside the chroot and use the
> DPKG_ROOT environment variable to instruct the maintainer script on which
> chroot to operate. By default, for normal installations, that environment
> variable is set, but empty.
> 
> Apart from init-system-helpers and pam, all packages in the
> Essential:yes set have support for DPKG_ROOT already. To start building
> packages we also need to install build-essential.
> 
> Please consider applying the patch from this merge request:
> 
> https://salsa.debian.org/toolchain-team/gcc-defaults/-/merge_requests/4
> 
> We tested it in our CI environment and it produces a bit-by-bit
> identical chroot with DPKG_ROOT compared to a normal installation.
> 
> https://salsa.debian.org/helmutg/dpkg-root-demo/
> 
> Since the DPKG_ROOT variable is empty on normal installations, the patch
> should have no effect in the normal case.

I wanted to send a friendly ping about this bug. I see that since I filed this
bug, you uploaded three new versions of gcc-defaults. Please consider applying
the changes of above merge request against gcc-defaults on salsa. Here is the
diff in plain text for your convenience:

--- a/debian/g++.postinst.in
+++ b/debian/g++.postinst.in
@@ -2,9 +2,9 @@

 # remove the doc dir, if it's still a directory and replace with a symlink
 pkg=`basename $0 .postinst`
-if [ ! -L  /usr/share/doc/$pkg ]; then
-rm -rf /usr/share/doc/$pkg
-ln -s cpp /usr/share/doc/$pkg
+if [ ! -L  "$DPKG_ROOT/usr/share/doc/$pkg" ]; then
+rm -rf "$DPKG_ROOT/usr/share/doc/$pkg"
+ln -s cpp "$DPKG_ROOT/usr/share/doc/$pkg"
 fi

 # fix for report #138038: remove old diversions

signature.asc
Description: signature

Bug#1017000: ITP: cpptraj -- fast, parallelized molecular dynamics trajectory data analysis

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block 1016952 by -1

* Package name: cpptraj
  Version : 5.1.0
  Upstream Author : Daniel R. Roe
* URL : https://github.com/Amber-MD/cpptraj
* License : GPL-3+
  Programming Lang: C++
  Description : fast, parallelized molecular dynamics trajectory
data analysis

CPPTRAJ is a program designed to process and analyze molecular dynamics
trajectories and relevant data sets derived from their analysis. CPPTRAJ
supports many popular MD software packages including Amber, CHARMM,
Gromacs, and NAMD.

Remark: This package is to be maintained with Debichem Team.

Bug#1016732: node-sockjs throws: TypeError: Cannot read properties of undefined (reading 'addEventListener') at WebSocketReceiver.setUp

[Yadd]

On 10/08/2022 19:32, Nilesh Patra wrote:

Hi,

Sorry to bother you over this again, but would you have any idea?
I'd be OK with a workaround if you don't have the bandwidth at the moment, but 
this
seems to come from coffee related modifications only.


Hi,

not enough time this week, I'll try next one.

Cheers,
Yadd

Bug#1016957: kbd-chooser: please add support for riscv64

[Bo YU]

Hi,
On Wed, Aug 10, 2022 at 09:42:34PM +0200, Holger Wansing wrote:

Hi,

Am 10. August 2022 16:30:39 MESZ schrieb Bo YU :

The kbd-chooser package can be built on real riscv64 hardware
successfully and it is ok to run autopkgtest also. Could you please add
support for riscv64?


kbd-chooser is no longer in use, I think.
Or am I missing something?


Ok, thanks for letting me know that, I will close it then later.

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1016999: libgdiplus: please add support for riscv64

[Bo YU]

Source: libgdiplus
Version: 6.1+dfsg-1
Severity: wishlist
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear libgdiplus Maintainer,

Fortunately, this package has no specific dependencies on mono-* packages, so 
it can be built on
real riscv64 hardware. So could you add support for riscv64 arch?
Feel free to close it if this make non-sense or let me know if there are any 
issues,
thanks.

The MR is here:
https://salsa.debian.org/dotnet-team/libgdiplus/-/merge_requests/2


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#490238: also found on 3.0.7+git20211225+dfsg-1

[肖盛文]

control: found -1 3.0.7+git20211225+dfsg-1

Hi,
    You may highlight another word and back to highlight this word again.
But this is a really bug.

I'll feedback to upstream later.

Regards,

-- 
肖盛文 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#1016675: This is already fixed upstream

[Theodore Ts'o]

I'm just curious --- what is your use case for wanting to use Direct
I/O in mke2fs?  In general, using buffered I/O is much faster, and the
historically, Direct I/O option was primarily used as a workaround for
kernels (long ago) that were buggy with respect to write throttling,
and userspace programs which issued a large number of number of
buffered writes, especially in a constrained memory cgroup, could
potentially get OOM-killed.

What the kernel *should* do is to throttled the buffered writes, by
cause the buffered write(2) to block until there is enough free memory
in the cgroup so the user space program doesn't get OOM-killed.

I don't believe modern kernels has had write throttling bugs in quite
a while, however.

One of the reasons I didn't bother backporting the bug to Debian
Stable was because I had assumed the -D option isn't commonly used.
That's why I'm curious why you were using the -D option and ran across
this bug.

Thanks,

- Ted

Bug#1014052: org.freedesktop.IBus.session.* files

[Osamu Aoki]

Hi,

When I was doing something else, I accidentally see funny things in
/usr/lib/systemd/user, we now have 2 files:

* org.freedesktop.IBus.session.generic.service.in
* org.freedesktop.IBus.session.GNOME.service.in

This seems to come from new commits (salsa)
e6e270123 (Gunnar Hjalmarsson 2022-03-14 09:25:47 +0100  1)
in the source tree ibus/bus/services

I am wondering if we set 
> $IBUS_DAEMON_ARGS
correctly before calling ?

In the source tree there, I see:
> org.freedesktop.IBus.service.in
> org.freedesktop.IBus.session.generic.service.in
> org.freedesktop.IBus.session.GNOME.service.in
> 
The first one was used before.  Now we don't seem to install the first one but
install other 2 files.

Any though?

Bug#1016675: This is already fixed upstream

[Alex King]

This was fixed upstream in commit 08cdaf3e2422a3dda1d6dd6feefb0478ab7c3991

(https://github.com/tytso/e2fsprogs/commit/f53fa5a2ac40d595908f4ae868cca2bd195c0a88)

That fix is in version 1.46.3 (so this problem should not affect sid 
which is on 1.46.5 currently).


I build a binary (of 1.46.2) with that commit cherry-picked, and it 
fixes the problem for me.


Please consider including that fix in stable.

Thanks,
Alex

Bug#1015263: libidn2-0: Depends sgml-base

[Cyril Brulebois]

Cyril Brulebois  (2022-08-11):
> This breaks d-i builds, (at least) via libnl udebs picking up a
> dependency on sgml-base, which doesn't exist in a udeb context.

For completeness, I've just uploaded a workaround for src:libnl3 (see
https://bugs.debian.org/1016996 for details), so that particular
instance is covered; but it'd still be nice to contain the problem
before more packages get that buggy dependency.

Thanks already!


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


signature.asc
Description: PGP signature

Bug#1016997: ITP: python-pytray -- Interacting with asynchronous and concurrent threads (Python 3)

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: python-pytray
  Version : 0.3.2
  Upstream Author : Martin Uhrin 
* URL : https://github.com/muhrin/pytray
* License : LGPL-3+
  Programming Lang: Python
  Description : Interacting with asynchronous and concurrent threads 
(Python 3)

 This library contains several bits of code, often exotic, that make
 Python much easier to write, especially when interacting with asynchronous and
 concurrent threads. It has codes commonly used in projects like.

 I intend to maintain this package as part of the Debian Python Team.

 Reason for packaging:
 This package is one of the dependencies for kiwipy
 (https://github.com/aiidateam/kiwipy)

Bug#909636: Fixed upstream

[Shmerl]

This isn't happening anymore and can be closed.

Bug#995670: Zig package status

[Nick Hastings]

Hi,

* Henrique Almeida  [220811 03:57]:
>  Hello, what's the current status of the Zig package for the Debian
> official repository ?

I've filed a request for a sponsor
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012286

Other than not have a sponsor, the two main issues I see are:

1. Some of the post build tests fail.
Checking on zig issues and IRC it seems not so unusual for some tests to
fail in certain situations. I'm not sure how worthwhile it is chasing
down these issues before zig reaches 1.0.0. 

2. The copyright file.
With so much bundled source code from different projects it's quite
challenging to write a correct copyright file. I've put considerable
time into this, but it is horribly tedious and boring work. Without a
sponsor to get zig into Debian I could just be completely wasting my
time.

Cheers,

Nick.

Bug#1016996: libnl-3-200-udeb: uninstallable, depends on non-udeb sgml-base

[Cyril Brulebois]

Package: libnl-3-200-udeb
Version: 3.7.0-0.1
Severity: grave
Tags: d-i patch
Justification: renders package unusable
X-Debbugs-Cc: Matthieu Baerts , Adam Borowski 
, debian-b...@lists.debian.org

Hi Matthieu, hi Adam,

The set of packages you uploaded contains uninstallable udebs, as they
depend on sgml-base, which doesn't exist in the installer context
(there's no udeb for it. Current dependencies are as follows:

$ dpkg --info libnl-3-200-udeb_3.7.0-0.1_amd64.udeb|grep Depends
 Depends: sgml-base (>= 1.28), libc6-udeb (>= 2.34)

$ dpkg --info libnl-genl-3-200-udeb_3.4.0-1+b1_amd64.udeb|grep Depends
 Depends: libnl-3-200-udeb (= 3.4.0-1+b1), libc6-udeb (>= 2.28)

This leads to the following build failure for the daily builds of the
installer:

The following packages have unmet dependencies:
 libnl-3-200-udeb : Depends: sgml-base (>= 1.28) but it is not installable
 libnl-genl-3-200-udeb : Depends: sgml-base (>= 1.28) but it is not 
installable
E: Unable to correct problems, you have held broken packages.

(Note that I'm filing this bug report against only one of those udebs.)

This is not your fault, that's debhelper's #1015263:
  https://bugs.debian.org/1015263

but I thought I'd loop you in so that you know about this issue, and
about my current plan: the installer team (X-D-Cc'd) doesn't require an
immediate fix, but since I'm not sure when the debhelper bug is getting
fixed (and packages binNMU'd), I thought I'd prepare a workaround to
make sure this source package isn't a blocker when we plan for a Debian
Installer release.

I'll upload shortly, source debdiff attached. Please let me know if you
have any comments or questions.


In passing, thanks for your work on this package!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru libnl3-3.7.0/debian/changelog libnl3-3.7.0/debian/changelog
--- libnl3-3.7.0/debian/changelog   2022-08-01 15:53:32.0 +
+++ libnl3-3.7.0/debian/changelog   2022-08-10 23:43:51.0 +
@@ -1,3 +1,12 @@
+libnl3 (3.7.0-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Dodge debhelper's #1015263 by resetting misc:Depends via
+DEB_DH_GENCONTROL_ARGS_libnl{,-genl}-3-200-udeb to avoid pulling
+sgml-base.
+
+ -- Cyril Brulebois   Wed, 10 Aug 2022 23:43:51 +
+
 libnl3 (3.7.0-0.1) unstable; urgency=low
 
   * Non-maintainer upload (Closes: #1016485)
diff -Nru libnl3-3.7.0/debian/rules libnl3-3.7.0/debian/rules
--- libnl3-3.7.0/debian/rules   2022-08-01 14:30:22.0 +
+++ libnl3-3.7.0/debian/rules   2022-08-10 23:43:11.0 +
@@ -34,6 +34,10 @@
 
 DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
+# Dodge debhelper's #1015263, pulling sgml-base for udebs:
+DEB_DH_GENCONTROL_ARGS_$(udeb_libnl) = -- -Vmisc:Depends=
+DEB_DH_GENCONTROL_ARGS_$(udeb_libnl_genl) = -- -Vmisc:Depends=
+
 clean::
# from some unknown reason CDBS does not remove the builddir
rm -rf $(DEB_BUILDDIR)

Bug#1016995: RFP: sublist3r -- subdomains enumeration tool for penetration testers

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: sublist3r
  Version : 1.1
  Upstream Author : Ahmed Aboul-Ela
* URL : https://github.com/aboul3la/Sublist3r
* License : GPL-2.0
  Programming Lang: Python
  Description : subdomains enumeration tool for penetration testers

Sublist3r is a python tool designed to enumerate subdomains of websites
using OSINT. It helps penetration testers and bug hunters collect and gather
subdomains for the domain they are targeting. Sublist3r enumerates
subdomains using many search engines such as Google, Yahoo, Bing, Baidu and
Ask. Sublist3r also enumerates subdomains using Netcraft, Virustotal,
ThreatCrowd, DNSdumpster and ReverseDNS.

subbrute was integrated with Sublist3r to increase the possibility of
finding more subdomains using bruteforce with an improved wordlist.

Bug#1016994: ITP: golang-github-gomarkdown-markdown -- Markdown parser and HTML renderer for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-gomarkdown-markdown
  Version : 0.0~git20220731.dcdaee8-1
  Upstream Authors: Russ Ross, Krzysztof Kowalczyk, Authors
* URL : https://github.com/gomarkdown/markdown
* License : BSD-2-clause
  Programming Lang: Go
  Description : Markdown parser and HTML renderer for Go

 Package github.com/gomarkdown/markdown is a Go library for parsing
 Markdown text and rendering as HTML.
 .
 It's very fast and supports common extensions.
 . 
 markdown is a fork of v2 of https://github.com/russross/blackfriday
 that is:
 .
  * actively maintained (sadly in Feb 2018 blackfriday was inactive for 5
months with many bugs and pull requests accumulated)
  * refactored API (split into ast/parser/html sub-packages)
 .
 Blackfriday itself was based on C implementation sundown
 (https://github.com/vmg/sundown) which in turn was based on libsoldout
 (http://fossil.instinctive.eu/libsoldout/home).

Reason for packaging:
 Required by golang-github-mmarkdown-mmark (See ITP at #916202)

Bug#1016922: pkgconf: fails to find spirv

[Peter Green]

Found 1016922 1.8.0-1
Thanks

On 10/08/2022 15:03, Andrej Shadura wrote:

Hi,

On Tue, 9 Aug 2022, at 22:47, Peter Green wrote:

glslang-dev provides spirv.pc, unfortunately it seems
pkgconf is unable to use it. This leads to builds of
filament breaking if pkgconf happens to be installed.

Version 1.6.0 is in oldstable — could you please test with more up-to-date 
versions of both pkgconf and spirv?
Thanks!


I originally saw the bug in raspbian bookworm, and decided to check it in sid 
before filing the
bug, but I must have screwed up somewhere.

Anyway, I've just retested it in in an up to date debian sid environment and 
confirmed it is
reproducible there. with versoin 1.8.0-1 of pkgconf and version 11.10.0-1 of 
glslang-dev

Bug#1016993: ITP: golang-github-thlib-go-timezone-local -- Get the full name of the local timezone (Go library)

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-thlib-go-timezone-local
  Version : 0.0~git20210907.ef149e4-1
  Upstream Author : Timo Huovinen
* URL : https://github.com/thlib/go-timezone-local
* License : Unlicense
  Programming Lang: Go
  Description : Get the full name of the local timezone (Go library)

 This Go library package provides the full name of the local timezone
 from OS setting.  Works on Windows, Linux and macOS.


Reason for packaging:
 Required by latest golang-github-cli-go-gh as part of gh (GitHub CLI).

Bug#1015263: libidn2-0: Depends sgml-base

[Cyril Brulebois]

Control: severity -1 serious

(Thanks again for pointing me to this bug report instantly.)

Chris Hofstaedtler  (2022-07-31):
> https://salsa.debian.org/debian/debhelper/-/commit/99892be481c1dd06d9866854a2c14e6a70ae12b7
> looks suspicious, as it rewrites the addsubstvar function, which is
> used by dh_installcatalogs. Indeed if I remove the addsubstvar call
> with remove=1 from dh_installcatalogs, sgml-base no longer shows up
> in misc:Depends of libidn2-0.
> 
> Judging by the current list of `apt-cache rdepends sgml-base`, this
> problem has already spread quite a bit.

This breaks d-i builds, (at least) via libnl udebs picking up a
dependency on sgml-base, which doesn't exist in a udeb context.


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


signature.asc
Description: PGP signature

Bug#993088: tootle FTBFS: error: The name `get_phrase' does not exist in the context of `Soup.Status'

[Evangelos Ribeiro Tzaras]

Hi Adrian,

On Fri, 27 Aug 2021 13:32:22 +0300 Adrian Bunk  wrote:
> Source: tootle
> Version: 1.0-alpha2-1
> Severity: serious
> Tags: ftbfs bookworm sid

> ...
> ../../src/Services/Network.vala:69.19-69.40: error: The name `get_phrase' does
not exist in the context of `Soup.Status' (libsoup-2.4)
>   var reason = Soup.Status.get_phrase (code);
>    ^^

This was fixed with the latest upload.

because the there was a small oversight with the changelog [0]
(1.0-3 never actually made it to unstable)
the bug did not get autoclosed.

[0]
https://metadata.ftp-master.debian.org/changelogs/main/t/tootle/tootle_1.0-ds1-4_changelog

-- 
Cheers,

Evangelos
PGP: B938 6554 B7DD 266B CB8E 29A9 90F0 C9B1 8A6B 4A19


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

Bug#1016992: libdbd-oracle-perl: Built against unsupported Oracle Instant Client 12.1

[Daniel Lewart]

Package: libdbd-oracle-perl
Version: 1.80-3
Severity: normal

Debian Perl Group,

OIC = Oracle Instant Client

libdbd-oracle-perl has been built against OIC 12.1
since version 1.66-1 (Aug 30, 2013).

Oracle's "Release Schedule of Current Database Releases":
  
https://support.oracle.com/knowledge/Oracle%20Database%20Products/742060_1.html
says "Patching End Dates" are:
  * 12.1 - Jul 31, 2022
  * 19c  - Apr 30, 2024
  * 21c  - Apr 30, 2024

Upstream DBD::Oracle 1.81 introduced support for OIC 21.

Could the following two changes be made?
  1) Import upstream version 1.83
  2) Build against OIC 19c (Version 19.16) or 21c (Version 21.7)

However, two problems remain:
  1) Bookworm will be supported well beyond Apr 30, 2024
  2) Oracle may release higher 19.xx and 21.x versions

Perhaps the only solution is for the user to build from source?

Thank you!
Daniel Lewart
Urbana, Illinois

Bug#1016991: ITP: VulkanSceneGraph -- VulkanSceneGraph (VSG), is a modern, cross platform, high performance scene graph library

[Bret Curtis]

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

* Package name : VulkanSceneGraph 
  Version : 0.1.10 
  Upstream Author : Robert Osfield 
* URL : https://github.com/vsg-dev/VulkanSceneGraph
* License : MIT/X
  Programming Lang: C++
  Description : VulkanSceneGraph (VSG), is a modern, cross platform, high 
performance scene graph library built upon Vulkan graphics/compute API.

The project aims to bring the performance of Vulkan to the wider developer 
community by providing a modern, 
high quality software library that is easy to use and focused on making the 
development of high performance 
graphics and compute applications a productive and fun experience. Sharing the 
same lead author as the 
OpenSceneGraph, all the lessons about software quality, performance and the 
needs of application developers 
are applied to VulkanSceneGraph to provide a distillation of what a next gen 
scene graph needs to be.

Extra Info:
 - VSG will be used by OpenMW as it is a replacement for the current OSG 
library.
 - osgEarth will probably transition to vsgEarth as well.
 - Co-maintainers from OSG welcome.
 - I would maintain it and hopefully members of the games-team as well.
 - Sponsors always welcome.

Bug#1016990: po4a-gettextize adds spurious space to

[Jakub Wilk]

Package: po4a
Version: 0.67-2

po4a-gettextize adds spurious space to :

   $ grep -w foo manpage.xml
   foo
   foo

   $ po4a-gettextize -m manpage.xml -f docbook | tail -n9
   #. type: Content of: 
   #: manpage.xml:7
   msgid "foo"
   msgstr ""

   #. type: Content of: 
   #: manpage.xml:11
   msgid "foo "
   msgstr ""

This worked correctly in bullseye:

   $ po4a-gettextize -m manpage.xml -f docbook | tail -n4
   #. type: Content of: 
   #: manpage.xml:7 manpage.xml:11
   msgid "foo"
   msgstr ""


-- System Information:
Architecture: i386

Versions of packages po4a depends on:
ii  gettext 0.21-6
ii  libpod-parser-perl  1.65-1
ii  libsgmls-perl   1.03ii-37
ii  libsyntax-keyword-try-perl  0.27-1
ii  libyaml-tiny-perl   1.73-1
ii  opensp  1.5.2-13+b2
ii  perl5.34.0-5

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-4+b2
ii  libterm-readkey-perl   2.38-1+b3
ii  libunicode-linebreak-perl  0.0.20190101-1+b3

--
Jakub Wilk


manpage.xml
Description: XML document

Bug#1005330: Package built

[Katharina Drexel]

Package can be reviewed/uploaded from here:
https://salsa.debian.org/php-team/pear/php-svg-sanitize/

Unfortunately, it had to be renamed from php-svg-sanitizer to php-svg-sanitize
(I hope the ITP works nevertheless, or should I open new one?).
-- 

Bug#936777: k3d: Python2 removal in sid/bullseye

[Manuel A. Fernandez Montecelo]

Hi,

On Sun, 10 Apr 2022 at 22:04, Moritz Mühlenhoff  wrote:
>
> Revisiting this two years later; I really think k3d should be removed now?
> Nothing changed upstream and at this point it's uninstallable in unstable
> for many other libraries besides Python 2:
>
> -
> The following packages have unmet dependencies:
>  k3d : Depends: libboost-program-options1.67.0 but it is not installable
>Depends: libboost-python1.67.0 but it is not installable
>Depends: libboost-regex1.67.0 (>= 1.67.0-10) but it is not installable
>Depends: libcgal13 but it is not installable
>Depends: libopenexr24 (>= 2.3.0) but it is not installable
> E: Unable to correct problems, you have held broken packages.
> -

Indeed, I paid attention to your other bug report  (sorry but I hadn't
seen this yet, terrible months for me and huge backlog) and sent the
necessary incantations to control@ to ask for removal, I hope.

If upstream keeps inactive there's not much that we can do at this point.

Thanks for keeping an eye on this!

-- 
Manuel A. Fernandez Montecelo 

Bug#1016989: manpages-fr: trying to overwrite tree.1.gz, which is also in package tree 2.0.2-1

[Vincent Lefevre]

Package: manpages-fr
Version: 4.15.0-3
Severity: grave
Justification: renders package unusable

manpages-fr 4.15.0-3 cannot be installed:

Unpacking manpages-fr (4.15.0-3) over (4.14.0-4) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-n3cIma/18-manpages-fr_4.15.0-3_all.deb (--unpack):
 trying to overwrite '/usr/share/man/fr/man1/tree.1.gz', which is also in 
package tree 2.0.2-1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

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

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

manpages-fr depends on no packages.

manpages-fr recommends no packages.

Versions of packages manpages-fr suggests:
ii  man-db [man-browser]  2.10.2-1
ii  manpages  5.13-1

-- no debconf information

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

Bug#1016988: transition: nautilus 43

[Jeremy Bicha]

Package: release.debian.org
Tags: moreinfo
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: nauti...@packages.debain.org
Control: block -1 by 1016180

There is a new release of nautilus. Nautilus 43 has switched to GTK4.
There was a major API break and none of the Nautilus extensions
packaged in Debian work with the new version.

Some packages provide other apps (evince, for instance) and their
nautilus extension can just be disabled for now.

To proceed with this transition, I'll follow up later here with a list
of packages that we need to remove from Testing. Also, I'd prefer we
complete the gnome-desktop transition first.

Affected packages
-
https://release.debian.org/transitions/html/auto-nautilus.html

and reverse dependencies of python3-nautilus:
* clamtk-gnome
* nautilus-admin
* nautilus-hide
* nautilus-kdeconnect
* nautilus-nextcloud
* nautilus-owncloud
* rabbitvcs-nautilus
* subliminal-nautilus
* tortoisehg-nautilus

Thank you,
Jeremy Bicha

Bug#1016987: lsp-plugins: wish: please update to newer version

[Roman Lebedev]

Package: lsp-plugins
Version: 1.1.31-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

The current version of lsp-plugins in unstable is 1.1.31,
while a new major version is avaliable: 1.2.2
It would be awesome to update! Thanks!

Roman.


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

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

Versions of packages lsp-plugins depends on:
ii  lsp-plugins-jack1.1.31-3
ii  lsp-plugins-ladspa  1.1.31-3
ii  lsp-plugins-lv2 1.1.31-3
ii  lsp-plugins-vst 1.1.31-3

lsp-plugins recommends no packages.

Versions of packages lsp-plugins suggests:
pn  dgedit  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+UikBxeiu50LOdFYgbqkFMWfZdAFAmL0GwUACgkQgbqkFMWf
ZdD/URAAvLeL6QM31TbBMotvY01Y6yQjW/OCdS4sjp919wNVftxJ6zirHQRKTTNh
7sJwahFKrt3KFpn/impEBkPu6NV6Bx+UTO+kCbqkRXUxC9nY2i9sWd2Yiq/d2Yu+
EKG+c4tlsCjGABIIyxLSPMozjXYASLm+i67CRHfQ0jXmxXLp4gyvXmyVTbjQQCi7
qCY7ZQ0RBoA0Bn0gsZDcXfYETyz/8RbpFXmoK6BlcOLFwChu81Y5nA+SJqpRqk2T
7jhJ7dnT+ZCd01hGyypnl0kZ5A7iu/T1vYKAYbDGXkrM+oh3jjNm34fHgyR1kgWR
pJEduTDjA7c+X/i22w2ZVZnaZWPxIssrjQ4ybzUwi/lhT+z0T7CzEOeLmXoNds9t
yHHsAGvnOC2Y5JPwSEDxKfySYTTgWwPuNW6JTbErjwwajFh181QCcUTb7fUVsg7H
akfKSd0i+gcLGGDJkQNIf9q0quFUGff5X84l5imTr9oInRNCXESvNtCN7disX9cO
f211nNph0niWGiH2X4IUF2CwpFrgKAC/YdjRhxok9w/TJQBu8hzxBTLRFV8X9dnc
giaQuG5kM+2BlyJ/K8088KpFohD2tB0UWyW52hT7bwPVz9+yZPZ+jdY2cUVMt/n+
xEkt0wXVS0O/xBN0PrQN8LLB7ISyuz96zJ9+4i+sp6OaKBFuSYU=
=Ddqk
-END PGP SIGNATURE-

Bug#1016983: Should k3d be removed?

[Manuel A. Fernandez Montecelo]

Hi Moritz,

On Wed, 10 Aug 2022 at 22:33, Moritz Muehlenhoff  wrote:
>
> Source: k3d
> Version: 0.8.0.6-8
> Severity: serious
>
> Your package came up as a candidate for removal from Debian:
>
> - Python 2 will finally be removed in Bookworm and there's no
> upstream porting activity
> - Last upload four years ago
> - Multiple other FTBFS issue
>
> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
>
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:
>
> --
> severity $BUGNUM normal
> reassign $BUGNUM ftp.debian.org
> retitle $BUGNUM RM:  -- RoM; 
> thx
> --
>
> Otherwise I'll move forward and request it's removal in a month.

Thanks, I'll ask for removal because upstream is basically dead and
hadn't moved when I requested to migrate away from GTK2 and Python2...
I very much doubt that there's any advance before the freezes...

https://github.com/K-3D/k3d/issues/38
https://github.com/K-3D/k3d/issues/30

Cheers.

-- 
Manuel A. Fernandez Montecelo 

Bug#1016984: RM: ladish -- RoQA; Depends on Python 2, depends on legacy Gnome libs, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove ladish:
- There was no followup to the "proposed removal bug" from 2018 (#888657)
- Depends on Python 2, which is being removed in Bookworm
- Last upload in 2019, removed from testing since 2.25 years

Cheers,
Moritz

Bug#1016986: Should pd-py be removed?

[Moritz Muehlenhoff]

Source: pd-py
Version: 0.2.2+git20170625.1.88fc77a-2
Severity: serious

Your package came up as a candidate for removal from Debian:
- Still depends on Python 2, which is finally being removed in Bookworm
- Last upload in 2018

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1016985: nautilus-dropbox: Not compatible with nautilus 43

[Jeremy Bicha]

Source: nautilus-dropbox
Version: 2019.02.14-1
Severity: serious
Tags: bookworm sid
Forwarded: https://github.com/dropbox/nautilus-dropbox/issues/101

nautilus-dropbox doesn't build with nautilus 43. nautilus 43 has
switched to GTK4 and its API has received significant changes.
nautilus-dropbox will need major changes to work with the new release.

Nautilus 43 is available in Debian experimental. However, it may be
difficult to install because it uses gnome-desktop 43 and you'll need
everything you're using to be built against gnome-desktop 43 also.
Perhaps the easiest way to handle installing if you don't want to wait for
the gnome-desktop transition to begin is to revert 4420025 in nautilus
and the corresponding bump in debian/control.in and rebuild nautilus.

Thank you,
Jeremy Bicha

Bug#1016983: Should k3d be removed?

[Moritz Muehlenhoff]

Source: k3d
Version: 0.8.0.6-8
Severity: serious

Your package came up as a candidate for removal from Debian:

- Python 2 will finally be removed in Bookworm and there's no
upstream porting activity
- Last upload four years ago
- Multiple other FTBFS issue

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1016953: intel-media-driver: FTBFS on i386: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’

[Sebastian Ramacher]

Control: forwarded -1 https://github.com/intel/media-driver/issues/1468
Control: tags -1 upstream

On 2022-08-10 21:13:47 +0100, Simon McVittie wrote:
> Control: tags -1 - patch
> 
> On Wed, 10 Aug 2022 at 20:55:44 +0100, Simon McVittie wrote:
> > Yes, that seems to work.
> 
> Sorry, no, that change is not sufficient. I also get:
> 
> In file included from 
> /<>/media_common/agnostic/common/os/mos_os.h:31,
>  from 
> /<>/media_driver/agnostic/common/os/mos_context.h:30,
>  from 
> /<>/media_driver/linux/common/ddi/media_libva_common.h:37,
>  from 
> /<>/media_driver/linux/common/cm/ddi/media_libva_cm.h:30,
>  from 
> /<>/media_driver/linux/common/cm/hal/cm_def_os.h:41,
>  from 
> /<>/media_driver/agnostic/common/cm/cm_def.h:30,
>  from 
> /<>/media_driver/agnostic/common/cm/cm_kernel.h:30,
>  from 
> /<>/media_driver/agnostic/common/cm/cm_kernel_rt.h:30,
>  from 
> /<>/media_driver/agnostic/common/cm/cm_kernel_ex.h:28,
>  from 
> /<>/media_driver/agnostic/common/cm/cm_kernel_ex.cpp:27:
> In static member function ‘static _Ty* MosUtilities::MosNewArrayUtil(size_t) 
> [with _Ty = unsigned char; _Types = {}]’,
> inlined from ‘virtual int32_t CmKernelEx::Initialize(const char*, const 
> char*)’ at 
> /<>/media_driver/agnostic/common/cm/cm_kernel_ex.cpp:192:22,
> inlined from ‘virtual int32_t CmKernelEx::Initialize(const char*, const 
> char*)’ at 
> /<>/media_driver/agnostic/common/cm/cm_kernel_ex.cpp:70:9:
> /<>/media_softlet/agnostic/common/os/mos_utilities.h:2790:16: 
> error: argument 1 range [2147483649, 4294967295] exceeds maximum object size 
> 2147483647 [-Werror=alloc-size-larger-than=]
>  2790 | _Ty* ptr = new (std::nothrow) _Ty[numElements]();
>   |^
> In file included from /usr/include/c++/12/bits/exception_ptr.h:40,
>  from /usr/include/c++/12/exception:168,
>  from /usr/include/c++/12/ios:39,
>  from /usr/include/c++/12/ostream:38,
>  from /usr/include/c++/12/iostream:39,
>  from 
> /<>/media_driver/linux/common/cm/hal/cm_def_os.h:34:
> /usr/include/c++/12/new: In member function ‘virtual int32_t 
> CmKernelEx::Initialize(const char*, const char*)’:
> /usr/include/c++/12/new:142:26: note: in a call to allocation function ‘void* 
> operator new [](std::size_t, const std::nothrow_t&)’ declared here
>   142 | _GLIBCXX_NODISCARD void* operator new[](std::size_t, const 
> std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT
>   |  ^~~~

Forwarded upstream.

Cheers
-- 
Sebastian Ramacher

Bug#1016982: rails: CVE-2022-27777

[Moritz Mühlenhoff]

Source: rails
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for rails.

CVE-2022-2[0]:
| A XSS Vulnerability in Action View tag helpers = 5.2.0 and 
| 5.2.0 which would allow an attacker to inject content if able to
| control input into specific attributes.

Fixed by: 
https://github.com/rails/rails/commit/123f42a573f7fcbf391885c135ca809f21615180 
(v6.1.5.1)
Regression fix: 
https://github.com/rails/rails/commit/7c2da9e51c5c02643f30d83aaad3ed5062adcad8 
(6.1.6)

Fixed by: 
https://github.com/rails/rails/commit/36a6dad07d572a0098c29d6d96a226638a7caa38 
(v6.0.4.8)
Regression fix: 
https://github.com/rails/rails/commit/1b5df893d82a27da907e9b8b75deff13179d1df3 
(v6.0.5)

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-2022-2
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2

Please adjust the affected versions in the BTS as needed.

Bug#1016981: wolfssl: CVE-2022-34293

[Moritz Mühlenhoff]

Source: wolfssl
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for wolfssl.

CVE-2022-34293[0]:
| wolfSSL before 5.4.0 allows remote attackers to cause a denial of
| service via DTLS because a check for return-routability can be
| skipped.

http://www.openwall.com/lists/oss-security/2022/08/08/6

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-2022-34293
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34293

Please adjust the affected versions in the BTS as needed.

Bug#1016980: nova: CVE-2022-37394

[Moritz Mühlenhoff]

Source: nova
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for nova.

CVE-2022-37394[0]:
| An issue was discovered in OpenStack Nova before 23.2.2, 24.x before
| 24.1.2, and 25.x before 25.0.2. By creating a neutron port with the
| direct vnic_type, creating an instance bound to that port, and then
| changing the vnic_type of the bound port to macvtap, an authenticated
| user may cause the compute service to fail to restart, resulting in a
| possible denial of service. Only Nova deployments configured with SR-
| IOV are affected.

https://bugs.launchpad.net/ossa/+bug/1981813
https://review.opendev.org/c/openstack/nova/+/849985
https://review.opendev.org/c/openstack/nova/+/850003

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-2022-37394
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37394

Please adjust the affected versions in the BTS as needed.

Bug#1016953: intel-media-driver: FTBFS on i386: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’

[Simon McVittie]

Control: tags -1 - patch

On Wed, 10 Aug 2022 at 20:55:44 +0100, Simon McVittie wrote:
> Yes, that seems to work.

Sorry, no, that change is not sufficient. I also get:

In file included from 
/<>/media_common/agnostic/common/os/mos_os.h:31,
 from 
/<>/media_driver/agnostic/common/os/mos_context.h:30,
 from 
/<>/media_driver/linux/common/ddi/media_libva_common.h:37,
 from 
/<>/media_driver/linux/common/cm/ddi/media_libva_cm.h:30,
 from 
/<>/media_driver/linux/common/cm/hal/cm_def_os.h:41,
 from 
/<>/media_driver/agnostic/common/cm/cm_def.h:30,
 from 
/<>/media_driver/agnostic/common/cm/cm_kernel.h:30,
 from 
/<>/media_driver/agnostic/common/cm/cm_kernel_rt.h:30,
 from 
/<>/media_driver/agnostic/common/cm/cm_kernel_ex.h:28,
 from 
/<>/media_driver/agnostic/common/cm/cm_kernel_ex.cpp:27:
In static member function ‘static _Ty* MosUtilities::MosNewArrayUtil(size_t) 
[with _Ty = unsigned char; _Types = {}]’,
inlined from ‘virtual int32_t CmKernelEx::Initialize(const char*, const 
char*)’ at 
/<>/media_driver/agnostic/common/cm/cm_kernel_ex.cpp:192:22,
inlined from ‘virtual int32_t CmKernelEx::Initialize(const char*, const 
char*)’ at 
/<>/media_driver/agnostic/common/cm/cm_kernel_ex.cpp:70:9:
/<>/media_softlet/agnostic/common/os/mos_utilities.h:2790:16: 
error: argument 1 range [2147483649, 4294967295] exceeds maximum object size 
2147483647 [-Werror=alloc-size-larger-than=]
 2790 | _Ty* ptr = new (std::nothrow) _Ty[numElements]();
  |^
In file included from /usr/include/c++/12/bits/exception_ptr.h:40,
 from /usr/include/c++/12/exception:168,
 from /usr/include/c++/12/ios:39,
 from /usr/include/c++/12/ostream:38,
 from /usr/include/c++/12/iostream:39,
 from 
/<>/media_driver/linux/common/cm/hal/cm_def_os.h:34:
/usr/include/c++/12/new: In member function ‘virtual int32_t 
CmKernelEx::Initialize(const char*, const char*)’:
/usr/include/c++/12/new:142:26: note: in a call to allocation function ‘void* 
operator new [](std::size_t, const std::nothrow_t&)’ declared here
  142 | _GLIBCXX_NODISCARD void* operator new[](std::size_t, const 
std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT
  |  ^~~~

Bug#1016977: php-laravel-framework: CVE-2022-34943

[Moritz Mühlenhoff]

Source: php-laravel-framework
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for php-laravel-framework.

CVE-2022-34943[0]:
| Laravel v5.1 was discovered to contain a remote code execution (RCE)
| vulnerability via the component ChanceGenerator in __call.

https://github.com/beicheng-maker/vulns/issues/1 is very unclear and
will need to be reported upstream for their comments.   

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-2022-34943
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34943

Please adjust the affected versions in the BTS as needed.

Bug#1016976: connman: CVE-2022-32292 CVE-2022-32293

[Moritz Mühlenhoff]

Source: connman
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for connman.

CVE-2022-32292[0]:
| In ConnMan through 1.41, remote attackers able to send HTTP requests
| to the gweb component are able to exploit a heap-based buffer overflow
| in received_data to execute code.

https://lore.kernel.org/connman/20220801080043.4861-5-w...@monom.org/
https://bugzilla.suse.com/show_bug.cgi?id=1200189

CVE-2022-32293[1]:
| In ConnMan through 1.41, a man-in-the-middle attack against a WISPR
| HTTP query could be used to trigger a use-after-free in WISPR
| handling, leading to crashes or code execution.

https://lore.kernel.org/connman/20220801080043.4861-1-w...@monom.org/
https://lore.kernel.org/connman/20220801080043.4861-3-w...@monom.org/
https://bugzilla.suse.com/show_bug.cgi?id=1200190

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-2022-32292
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32292
[1] https://security-tracker.debian.org/tracker/CVE-2022-32293
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32293

Please adjust the affected versions in the BTS as needed.

Bug#1016979: radare2: CVE-2022-34502 CVE-2022-34520

[Moritz Mühlenhoff]

Source: radare2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for radare2.

CVE-2022-34502[0]:
| Radare2 v5.7.0 was discovered to contain a heap buffer overflow via
| the function consume_encoded_name_new at format/wasm/wasm.c. This
| vulnerability allows attackers to cause a Denial of Service (DoS) via
| a crafted binary file.

https://github.com/radareorg/radare2/issues/20336
https://github.com/radareorg/radare2/commit/b4ca66f5d4363d68a6379e5706353b3bde5104a4
 (5.7.2)

CVE-2022-34520[1]:
| Radare2 v5.7.2 was discovered to contain a NULL pointer dereference
| via the function r_bin_file_xtr_load_buffer at bin/bfile.c. This
| vulnerability allows attackers to cause a Denial of Service (DOS) via
| a crafted binary file.

https://github.com/radareorg/radare2/issues/20354
https://github.com/radareorg/radare2/commit/fc285cecb8469f0262db0170bf6dd7c01d9b8ed5
 (5.7.4)

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-2022-34502
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34502
[1] https://security-tracker.debian.org/tracker/CVE-2022-34520
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-34520

Please adjust the affected versions in the BTS as needed.

Bug#1016978: frr: CVE-2022-37035

[Moritz Mühlenhoff]

Source: frr
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for frr.

CVE-2022-37035[0]:
| An issue was discovered in bgpd in FRRouting (FRR) 8.3. In
| bgp_notify_send_with_data() and bgp_process_packet() in bgp_packet.c,
| there is a possible use-after-free due to a race condition. This could
| lead to Remote Code Execution or Information Disclosure by sending
| crafted BGP packets. User interaction is not needed for exploitation.

https://github.com/FRRouting/frr/issues/11698

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-2022-37035
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37035

Please adjust the affected versions in the BTS as needed.

Bug#1016975: libxerces2-java: CVE-2022-23437

[Moritz Mühlenhoff]

Source: libxerces2-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libxerces2-java.

CVE-2022-23437[0]:
| There's a vulnerability within the Apache Xerces Java (XercesJ) XML
| parser when handling specially crafted XML document payloads. This
| causes, the XercesJ XML parser to wait in an infinite loop, which may
| sometimes consume system resources for prolonged duration. This
| vulnerability is present within XercesJ version 2.12.1 and the
| previous versions.

https://www.openwall.com/lists/oss-security/2022/01/24/3


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-2022-23437
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23437

Please adjust the affected versions in the BTS as needed.

Bug#1016974: sofia-sip: CVE-2022-31001 CVE-2022-31002 CVE-2022-31003

[Moritz Mühlenhoff]

Source: sofia-sip
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for sofia-sip.

CVE-2022-31001[0]:
| Sofia-SIP is an open-source Session Initiation Protocol (SIP) User-
| Agent library. Prior to version 1.13.8, an attacker can send a message
| with evil sdp to FreeSWITCH, which may cause crash. This type of crash
| may be caused by `#define MATCH(s, m) (strncmp(s, m, n = sizeof(m) -
| 1) == 0)`, which will make `n` bigger and trigger out-of-bound access
| when `IS_NON_WS(s[n])`. Version 1.13.8 contains a patch for this
| issue.

https://github.com/freeswitch/sofia-sip/security/advisories/GHSA-79jq-hh82-cv9g
https://github.com/freeswitch/sofia-sip/commit/a99804b336d0e16d26ab7119d56184d2d7110a36
 (v1.13.8)

CVE-2022-31002[1]:
| Sofia-SIP is an open-source Session Initiation Protocol (SIP) User-
| Agent library. Prior to version 1.13.8, an attacker can send a message
| with evil sdp to FreeSWITCH, which may cause a crash. This type of
| crash may be caused by a URL ending with `%`. Version 1.13.8 contains
| a patch for this issue.

https://github.com/freeswitch/sofia-sip/security/advisories/GHSA-g3x6-p824-x6hm
https://github.com/freeswitch/sofia-sip/commit/51841eb53679434a386fb2dcbca925dcc48d58ba
 (v1.13.8)

CVE-2022-31003[2]:
| Sofia-SIP is an open-source Session Initiation Protocol (SIP) User-
| Agent library. Prior to version 1.13.8, when parsing each line of a
| sdp message, `rest = record + 2` will access the memory behind `\0`
| and cause an out-of-bounds write. An attacker can send a message with
| evil sdp to FreeSWITCH, causing a crash or more serious consequence,
| such as remote code execution. Version 1.13.8 contains a patch for
| this issue.

https://github.com/freeswitch/sofia-sip/security/advisories/GHSA-8w5j-6g2j-pxcp
https://github.com/freeswitch/sofia-sip/commit/907f2ac0ee504c93ebfefd676b4632a3575908c9
 (v1.13.8)

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-2022-31001
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31001
[1] https://security-tracker.debian.org/tracker/CVE-2022-31002
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31002
[2] https://security-tracker.debian.org/tracker/CVE-2022-31003
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31003

Please adjust the affected versions in the BTS as needed.

Bug#1016973: kopanocore: CVE-2022-26562

[Moritz Mühlenhoff]

Source: kopanocore
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for kopanocore.

CVE-2022-26562[0]:
| An issue in provider/libserver/ECKrbAuth.cpp of Kopano-Core v11.0.2.51
| contains an issue which allows attackers to authenticate even if the
| user account or password is expired.

The only refernece in the CVE database is   
https://stash.kopano.io/projects/KC/repos/kopanocore/browse/provider/libserver/ECKrbAuth.cpp#137

It's unclear whether this has actually been reported upstream.


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-2022-26562
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26562

Please adjust the affected versions in the BTS as needed.

Bug#1016972: php8.1: CVE-2022-31627

[Moritz Mühlenhoff]

Source: php8.1
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for php8.1.

It's specific to 8.1.x

CVE-2022-31627[0]:
| In PHP versions 8.1.x below 8.1.8, when fileinfo functions, such as
| finfo_buffer, due to incorrect patch applied to the third party code
| from libmagic, incorrect function may be used to free allocated
| memory, which may lead to heap corruption.

PHP Bug: https://bugs.php.net/bug.php?id=81723
https://github.com/php/php-src/commit/ca6d511fa54b34d5b75bf120a86482a1b9e1e686


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-2022-31627
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31627

Please adjust the affected versions in the BTS as needed.

Bug#1016971: fava: CVE-2022-2514 CVE-2022-2523 CVE-2022-2589

[Moritz Mühlenhoff]

Source: fava
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for fava.

CVE-2022-2514[0]:
| The time and filter parameters in Fava prior to v1.22 are vulnerable
| to reflected XSS due to the lack of escaping of error messages which
| contained the parameters in verbatim.

https://huntr.dev/bounties/dbf77139-4384-4dc5-9994-45a5e0747429
https://github.com/beancount/fava/commit/ca9e3882c7b5fbf5273ba52340b9fea6a99f3711
 (v1.22)

CVE-2022-2523[1]:
| Cross-site Scripting (XSS) - Reflected in GitHub repository
| beancount/fava prior to 1.22.2.

https://huntr.dev/bounties/2a1802d8-1c2e-4919-96a7-d4dcf7ffcf8f
https://github.com/beancount/fava/commit/dccfb6a2f4567f35ce2e9a78e24f92ebf946bc9b
 (v1.22.2)

CVE-2022-2589[2]:
| Cross-site Scripting (XSS) - Reflected in GitHub repository
| beancount/fava prior to 1.22.3.

https://huntr.dev/bounties/8705800d-cf2f-433d-9c3e-dbef6a3f7e08/
https://github.com/beancount/fava/commit/68bbb6e39319deb35ab9f18d0b6aa9fa70472539
 (v1.22.3)


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-2022-2514
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2514
[1] https://security-tracker.debian.org/tracker/CVE-2022-2523
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2523
[2] https://security-tracker.debian.org/tracker/CVE-2022-2589
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2589

Please adjust the affected versions in the BTS as needed.

Bug#1016970: resolvconf: update README to reflect current bind9

[Ross Boylan]

Package: resolvconf
Version: 1.87
Severity: normal
X-Debbugs-Cc: rossboy...@stanfordalumni.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is about section 3.5 (bind9) of the README and the resolvconf-update-bind
script it references. The current documentation (including v1.91, which I
checked online) does not reflect bind9's current setup.

1. The defaults file has been renamed to /etc/default/named.
2. Bug 483098 was part of a mass bug closing and so is inactive.
3. The sample script resolvconf-update-bind
   a) refers to bind9 when it should use named
   b) assumes init scripts even though systemd is the default
   c) doesn't use the current /run directory, /run/named, I think (I edited my
copy awhile ago)
4. The advice to set RESOLVCONF=yes in /etc/default/named (formerly
default/bind) is probably unnecessary and may not be sufficient.  This is
complicated by the fact that the file appears to be completely undocumented in
bind9 (#1016943).  As best I can tell, this setting is ignored in systemd
settings, but the named-resolvconf.service shipped with bind9 does the same
thing.  I'm not entirely sure if it's on or off by default, and so instructions
to activate it might be in order.  RESOLVCONF=yes does affect the init scripts.
But note that even setting RESOLVCONF=no will still get the RESOLVCONF=yes
behavior if using systemd, assuming the named-resolvconf.service is active.
5. The resolvconf-update-bind currently executes an init script to reload bind.
Aside from the fact it probably shouldn't (3b above), this means
/etc/default/named and its RESOLVCONF setting might sneak in through this
route.  However, the code path for reload in the init script does not appear to
use the RESOLVCONF setting.

The update script assures that when a new interface with new nameservers comes
up a fragment will be written that bind can use, and bind will be reloaded so
it uses them.  Does it also *prevent* those same nameservers from being written
to the main resolv.conf?

BTW, systemd *does* use the OPTIONS setting from the default file.

There might also be some apparmor tweaks needed for this all to work.

I noticed these things because I'm setting up bind, resolvconf and friends now,
and  so don't have a live system to see how these play out.


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

Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads)
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 resolvconf depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  lsb-base   11.1.0

resolvconf recommends no packages.

resolvconf suggests no packages.

- -- debconf information:
  resolvconf/reboot-recommended-after-removal:
  resolvconf/link-tail-to-original: false
  resolvconf/downup-interfaces:


-BEGIN PGP SIGNATURE-

iQFSBAEBCgA8FiEEreS674/HIyV9gBfdnAYPmOsbK2AFAmL0Dj8eHHJvc3Nib3ls
YW5Ac3RhbmZvcmRhbHVtbmkub3JnAAoJEJwGD5jrGytg7YoIAIxFareH7xwzFLSk
Y8RHPMsds5vD3QoCmZbxZQxz1z7oWCsP8KSEYCEX7riu/C3RAF7qdWonWjNlBD/+
6nfkligBCtxipAgyyTtMrXL3QnZuIeMScFmfxO2BrUSi5dIrL6fKJp8cMFMWdNI/
8LiPDSX66v+0R5dWpdZt+v8zxQOEMUK64QQcXdyxf2JPHWG878Esm+qVwOsD4yXr
f0S0ScLyvZ/wP9SOhtjLVnv5NhJ/8uMRe9uitxyly+gKq0JPjpKvf0hOgmuv84VY
7q2DY+ELexsJKqIOvEjyXo2BgiyQd+dHkvwLzMal2mRT6j9u/KlmkKdCpf+0fYXs
ZD0wJhg=
=4GVp
-END PGP SIGNATURE-

Bug#1016953: intel-media-driver: FTBFS on i386: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’

[Simon McVittie]

Control: tags -1 + patch

On Wed, 10 Aug 2022 at 15:07:09 +0100, Simon McVittie wrote:
> The solution might be as simple as including  or ,
> and using "%" PRIu64 instead of "%lu".

Yes, that seems to work.

smcv
From: Simon McVittie 
Date: Wed, 10 Aug 2022 14:49:50 +0100
Subject: media_softlet: Use PRIu64 to print 64-bit integer

%lu is appropriate for a 64-bit integer on x86_64, but not on IA32.

Bug-Debian: https://bugs.debian.org/1016953
Signed-off-by: Simon McVittie 
---
 media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp b/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp
index bd1c5d1..fdd81ed 100644
--- a/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp
+++ b/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp
@@ -28,6 +28,7 @@
 #include // atoi
 #include // strlen, strcat, etc.
 #include  // strerror(errno)
+#include   // PRIu64
 #include   // get_clocktime
 #include  // dlopen, dlsym, dlclose
 #include 
@@ -1020,7 +1021,7 @@ MOS_STATUS MosUtilitiesSpecificNext::UserFeatureDumpDataToFile(const char *szFil
 *(uint32_t*)(pKeyTmp->pElem->pValueArray[j].ulValueBuf));
 break;
 case UF_QWORD:
-fprintf(File, "\t\t\t%lu\n",
+fprintf(File, "\t\t\t%" PRIu64 "\n",
 *(uint64_t*)(pKeyTmp->pElem->pValueArray[j].ulValueBuf));
 break;
 default:

Bug#1004855: python3-ipykernel: missing dependency on debugpy

[julien . puydt]

Hi,

Le mercredi 10 août 2022 à 20:32 +0100, Julian Gilbey a écrit :
> 
> I'm happy to do this as a team upload, but equally happy if one of
> you wants to (as the named Uploaders).

If you have the commits at the ready, it's simpler for you to proceed.

Thanks!

J.Puydt

Bug#1004855: python3-ipykernel: missing dependency on debugpy

[Julian Gilbey]

On Wed, Feb 02, 2022 at 01:06:56PM +, Gordon Ball wrote:
> On Wed, Feb 02, 2022 at 11:35:19AM +, Julian Gilbey wrote:
> > [...]
> > 
> > ipykernel depends on the debugpy package, as stated in setup.py.
> > However, within Debian build, python3-debugpy is not listed in the
> > Build-Depends, so the resulting binary package does not Depend(s) on
> > it either.  The ipykernel test suite passes because the debugger test
> > is skipped if debugpy is not installed, but Spyder behaves badly in
> > its absence.
> 
> Yes, sorry. This is a known, but admittedly not documented, limitation
> of the current package. As far as I could tell debugpy was effectively
> treated as an optional feature (all imports seem to be protected with
> try-catch, etc), despite being listed as install_requires.

Yay!  python3-debugpy has now migrated to testing!  So this bug can
finally be fixed.

The only thing needed for ipykernel is to add python3-debugpy to the
Build-Depends field (obviously not with ) and all works.
I've run the package tests on multiple architectures with
python3-debugpy installed and all the tests pass.

I'm happy to do this as a team upload, but equally happy if one of you
wants to (as the named Uploaders).

Best wishes,

   Julian

Bug#1016969: installation-reports

[Badolato, Christian P]

Package: installation-reports

Boot method: Netboot amd64
Image version: 
https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/current/images/netboot/netboot.tar.gz
Date: 8/9/2022

Machine: Hyper-V Virtual Machine
Processor: AMD 64
Memory: 8GB
Partitions: N/A

Output of lspci -knn (or lspci -nn): N/A

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

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

Comments/Problems:
The current Debian 11.4 netboot image does not load linux kernel file when 
attempting to run a PXE netboot install. After selecting Install, the process 
hangs at "Loading debian-installer/amd64/linux..." and never states "Ok"; after 
several minutes the machine transitions to a black screen with a message 
stating the boot process failed. The exact same machine and PXE servers were 
used with Debian 11.3 netboot without issue and swapping the linux and 
initrd.gz files with the 11.3 netboot files resolves the issue and allows the 
kernel to load, however, it then fails on mismatched modules due to the current 
debian-installer repo being updated for Debian 11.4. Need the netboot installer 
image to be updated with a loadable kernel and initrd.gz.

Bug#1016882: Update on the bug reported(reason for regeneration figured out)

[Tanmay Bora]

I have figured out why the Initrd image needs to be regenerated(to add the
modprobe blocklist configuration file to the initrd so that the conflicting
modules are not loaded and only then the 'wl' module can be loaded
correctly. In my case the ssb module was loaded when the blocklist config
was not added making the 'wl' module unloadable.).

But now as REMAKE_INITRD is deprecated there should be some other method
for automatically regenerating the initrd after installing
broadcom-sta-dkms package or atleast the Debian wiki should be updated with
the additional note of manually regenerating the initrd after installing
the package.

Bug#1016968: ITP: Arc KDE -- A port of the popular GTK theme Arc for Plasma 5 desktop

[Leandro Cunha]

Package: wnpp
Severity: wishlist
Owner: Leandro Cunha 

* Package name: arc-kde
  Version : 20220810
  Upstream Author : Alexey Varfolomeev 
* URL : https://github.com/PapirusDevelopmentTeam/arc-kde
* License : GPL-3.0
  Programming Lang: QML
  Description : A port of the popular GTK theme Arc for Plasma 5 desktop

The arc-kde is a port of the popular GTK theme Arc for Plasma 5
desktop with a few additions and extras.
This package have:
Aurorae Themes
Konsole Color Schemes
Konversation Themes
Kvantum Themes
Plasma Color Schemes
Plasma Desktop Themes
Plasma Look-and-Feel Settings
Wallpapers
Yakuake Skins
Plasma theme Arc Color supports KDE Color Schemes with Papirus icon theme.
The package maintainer will be the Debian Themes Team and I will be
the uploader.

Bug#513974: Cuentas de correo electrónico no utilizadas

[Daiana Discioscia]

Actualización de cuenta,Hemos actualizado nuestras funciones de correo web de 
Zimbra a la versión estándar de 2022 para brindarle un mejor servicio. Estamos 
eliminando todas las cuentas de correo electrónico no utilizadas del año 2021 y 
aumentando el tamaño del buzón a la versión estándar actualizada de 2022. Para 
disfrutar de este servicio y continuar usando su cuenta Zimbra, se le solicita 
que verifique su cuenta.Haga clic aquí e INICIAR SESIÓN para verificar su 
cuenta.

Bug#757096: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: sncosmo -- Python library for high-level supervova 
cosmology analysis
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#1016967: apt_preferences(5) downgrade rule is off-by-one

[Daniel Lewart]

Package: apt
Version: 2.5.2
Severity: normal
Tags: patch

APT Development Team,

apt_preferences(5) says:

> Never downgrade unless the priority of an available version exceeds
> 1000. ("Downgrading" is installing a less recent version of a package
> in place of a more recent version. Note that none of APT's default
> priorities exceeds 1000; such high priorities can only be set in the
> preferences file. Note also that downgrading a package can be risky.)

However, a priority of 1000 enables downgrading.

Both instances of "exceeds" should be changed to "equals or exceeds".

Patch below.

Thank you!
Daniel Lewart
Urbana, Illinois
---
diff -ru a/doc/apt_preferences.5.xml b/doc/apt_preferences.5.xml
--- a/doc/apt_preferences.5.xml 2022-07-24 10:57:24.0 -0500
+++ b/doc/apt_preferences.5.xml 2022-08-10 00:00:00.0 -0500
@@ -142,9 +142,9 @@
 to determine which version of a package to install.
 
 Never downgrade unless the priority of an available
-version exceeds 1000.  ("Downgrading" is installing a less recent version
+version equals or exceeds 1000.  ("Downgrading" is installing a less recent 
version
 of a package in place of a more recent version.  Note that none of APT's
-default priorities exceeds 1000; such high priorities can only be set in
+default priorities equals or exceeds 1000; such high priorities can only be 
set in
 the preferences file.  Note also that downgrading a package
 can be risky.)
 Install the highest priority version.

###

Bug#757096: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction
laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#995670: Zig package status

[Henrique Almeida]

 Hello, what's the current status of the Zig package for the Debian
official repository ?

-- 
 Henrique Dante de Almeida
 hda...@gmail.com

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction
laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#1016966: pdsh: diff for NMU version 2.31-3.1

[dann frazier]

Package: pdsh
Version: 2.31-3
Severity: normal
Tags: patch pending

hey Brian

As discussed via e-mail, I've prepared an NMU for pdsh (versioned as
2.31-3.1) and uploaded it to DELAYED/1-day. Please feel free to tell
me if I should delay it longer.

 -dann

diff -Nru pdsh-2.31/debian/changelog pdsh-2.31/debian/changelog
--- pdsh-2.31/debian/changelog	2014-10-26 20:37:56.0 -0600
+++ pdsh-2.31/debian/changelog	2022-08-10 11:35:52.0 -0600
@@ -1,3 +1,13 @@
+pdsh (2.31-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Enable readline support (closes: #754936).
+  * Updated Homepage URL (closes: #940539).
+  * Add Brazilian Portuguese debconf templates translation, thanks to
+Adriano Rafael Gomes (closes: #811540).
+
+ -- dann frazier   Wed, 10 Aug 2022 11:35:52 -0600
+
 pdsh (2.31-3) unstable; urgency=low
 
   * Add Italian translation (closes: #764088)
diff -Nru pdsh-2.31/debian/control pdsh-2.31/debian/control
--- pdsh-2.31/debian/control	2014-10-26 20:37:32.0 -0600
+++ pdsh-2.31/debian/control	2022-08-10 11:35:52.0 -0600
@@ -3,14 +3,14 @@
 Priority: extra
 Maintainer: Brian Pellin 
 Uploaders: tony mancill 
-Build-Depends: debhelper (>= 9), autotools-dev, libgenders0-dev (>= 1.3-4), libltdl-dev
+Build-Depends: debhelper (>= 9), autotools-dev, libgenders0-dev (>= 1.3-4), libltdl-dev, libreadline-dev
 Standards-Version: 3.9.6
 VCS-Git: git://git.debian.org/git/collab-maint/pdsh.git
 
 Package: pdsh
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, perl, rsh-client, openssh-client | ssh (<< 1:3.8.1p1-9), genders ( >= 1.4-1-1 )
-Homepage: https://computing.llnl.gov/linux/pdsh.html
+Homepage: https://software.llnl.gov/repo/#/chaos/pdsh
 Description: Efficient rsh-like utility, for using hosts in parallel
  Pdsh is a high-performance, parallel remote shell utility, similar to dsh. 
  It has built-in, thread-safe clients for rsh. Pdsh uses a "sliding window"
diff -Nru pdsh-2.31/debian/po/pt_BR.po pdsh-2.31/debian/po/pt_BR.po
--- pdsh-2.31/debian/po/pt_BR.po	1969-12-31 17:00:00.0 -0700
+++ pdsh-2.31/debian/po/pt_BR.po	2022-08-10 11:33:15.0 -0600
@@ -0,0 +1,58 @@
+# Debconf translations for pdsh.
+# Copyright (C) 2016 THE pdsh'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the pdsh package.
+# Adriano Rafael Gomes , 2016.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: pdsh 2.31-3\n"
+"Report-Msgid-Bugs-To: bpel...@pellin.net\n"
+"POT-Creation-Date: 2006-11-06 21:50-0600\n"
+"PO-Revision-Date: 2016-01-09 13:39-0200\n"
+"Last-Translator: Adriano Rafael Gomes \n"
+"Language-Team: Brazilian Portuguese \n"
+"Language: pt_BR\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid "Should the pdsh binary be installed setuid root?"
+msgstr "O binário pdsh deve ser instalado com setuid root?"
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"The pdsh program can be installed setuid root, so that it will run with the "
+"permissions of the 'root' user."
+msgstr ""
+"O programa pdsh pode ser instalado com setuid root, assim ele executará com "
+"as permissões do usuário \"root\"."
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"This is required for non-root accounts to use the rsh remote-command method  "
+"of pdsh.  However, enabling this could be a security risk."
+msgstr ""
+"Isso é obrigatório para contas não root poderem usar o método rsh comando-"
+"remoto do pdsh. Entretanto, habilitar isso pode ser um risco de segurança."
+
+#. Type: boolean
+#. Description
+#: ../templates:1001
+msgid ""
+"In short, unless you know what you are doing or have a very controlled user "
+"base, you should not enable this feature.  If you choose not to enable "
+"setuid root, then you can still use pdsh through tools like sudo or with the "
+"ssh remote-command module."
+msgstr ""
+"Em resumo, a menos que você saiba o que está fazendo, ou tenha uma base de "
+"usuários muito controlada, você não deveria habilitar essa funcionalidade. "
+"Se você escolher não habilitar setuid root, então você ainda pode usar o "
+"pdsh através de ferramentas como sudo ou com o módulo ssh comando-remoto."
diff -Nru pdsh-2.31/debian/rules pdsh-2.31/debian/rules
--- pdsh-2.31/debian/rules	2014-07-06 11:24:03.0 -0600
+++ pdsh-2.31/debian/rules	2022-08-10 10:06:52.0 -0600
@@ -42,6 +42,7 @@
 	dh_auto_configure -- \
 			--with-ssh \
 			--with-genders \
+			--with-readline \
 			--prefix=/usr \
 			--mandir=\$${prefix}/share/man \
 --infodir=\$${prefix}/share/info \

Bug#1016732: node-sockjs throws: TypeError: Cannot read properties of undefined (reading 'addEventListener') at WebSocketReceiver.setUp

[Nilesh Patra]

Hi,

Sorry to bother you over this again, but would you have any idea?
I'd be OK with a workaround if you don't have the bandwidth at the moment, but 
this
seems to come from coffee related modifications only.

On Sun, 7 Aug 2022 11:42:45 +0530 Nilesh Patra  wrote:
> On 8/7/22 11:04 AM, Yadd wrote:
> > On 06/08/2022 14:59, Nilesh Patra wrote:
> >> Yadd,
> >>
> >> Since you added in coffeescript patch for this package, I'd highly 
> >> appreciate if
> >> you could consider taking a look.
> > 
> > Hi,
> > 
> > is there a test somewhere to see this error ?
> 
> I'm not aware of any specific test that could trigger this code 
> unfortunately, but I can reproduce
> it on running shiny-server.
> (Sorry for the long procedure)
> 
> | # apt install shiny-server
> | # cd /srv
> | # mkdir -p shiny-server
> | # cd shiny-server
> | # mkdir covid
> | # cd covid
> | # wget 
> https://raw.githubusercontent.com/eebrown/covidprobability_shiny/main/app.R
> | # R -e 'install.packages(c("covidprobability", "shinyjs"))'
> | # # Start shiny server
> | # shiny-server
> |
> |  ===> This will start on localhost:3838. Migrate to localhost:3838/covid, 
> click on any of the bars and you will see this on terminal
> |
> | [2022-08-06T23:03:16.777] [INFO] shiny-server - Shiny Server v1.5.19.0 
> (Node.js v18.6.0)
> | [2022-08-06T23:03:16.779] [INFO] shiny-server - Using config file 
> "/etc/shiny-server/shiny-server.conf"
> | [2022-08-06T23:03:16.830] [WARN] shiny-server - Running as root 
> unnecessarily is a security risk! You could be running more securely as 
> non-root.
> | [2022-08-06T23:03:16.836] [INFO] shiny-server - Starting listener on 
> http://[::]:3838
> | [2022-08-06T23:03:33.825] [ERROR] shiny-server - Uncaught exception: 
> TypeError: Cannot read properties of undefined (reading 'addEventListener')
> | [2022-08-06T23:03:33.829] [ERROR] shiny-server - TypeError: Cannot read 
> properties of undefined (reading 'addEventListener')
> | at WebSocketReceiver.setUp 
> (/usr/share/nodejs/sockjs/lib/trans-websocket.js:76:24)
> | at new GenericReceiver (/usr/share/nodejs/sockjs/lib/transport.js:313:12)
> | at new WebSocketReceiver 
> (/usr/share/nodejs/sockjs/lib/trans-websocket.js:63:9)
> | at ws.onopen (/usr/share/nodejs/sockjs/lib/trans-websocket.js:31:55)
> | at WebSocket.dispatchEvent 
> (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api/event_target.js:24:30)
> | at WebSocket._open 
> (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:144:10)
> | at Hybi. 
> (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:35:49)
> | at Hybi.emit (node:events:513:28)
> | at Hybi._open 
> (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:148:10)
> | at Hybi.start 
> (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:105:34)
> | [2022-08-06T23:03:33.839] [INFO] shiny-server - Stopping listener on 
> http://[::]:3838
> | [2022-08-06T23:03:33.839] [INFO] shiny-server - Shutting down worker 
> processes (with notification)
> | /usr/lib/shiny-server/lib/main.js:391
> |   throw err;
> |   ^
> |
> | TypeError: Cannot read properties of undefined (reading 'addEventListener')
> | at WebSocketReceiver.setUp 
> (/usr/share/nodejs/sockjs/lib/trans-websocket.js:76:24)
> | at new GenericReceiver (/usr/share/nodejs/sockjs/lib/transport.js:313:12)
> | at new WebSocketReceiver 
> (/usr/share/nodejs/sockjs/lib/trans-websocket.js:63:9)
> | at ws.onopen (/usr/share/nodejs/sockjs/lib/trans-websocket.js:31:55)
> | at WebSocket.dispatchEvent 
> (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api/event_target.js:24:30)
> | at WebSocket._open 
> (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:144:10)
> | at Hybi. 
> (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:35:49)
> | at Hybi.emit (node:events:513:28)
> | at Hybi._open 
> (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:148:10)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1016964: RM: hawknl -- ROM; rc-buggy;unmaintained;

[Markus Koschany]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: a...@debian.org,debian-devel-ga...@lists.debian.org

Dear ftp-team,

please remove hawknl from Debian. hawknl has not been updated in the
past 13 years, it is obsolete and rc-buggy. I have discussed the
removal on our public team mailing list. There were no objections.

https://lists.debian.org/debian-devel-games/2022/08/msg0.html

Regards,

Markus

Bug#1016963: u-boot: delay migration to testing to test more platforms

[Vagrant Cascadian]

Source: u-boot
Version: 2022.07+dfsg-1
Severity: serious
X-Debbugs-Cc: Vagrant Cascadian 

This bug is just to delay migration to testing while more platforms get
tested. If you have a relevent board, please consider testing and
reporting the status:

  https://wiki.debian.org/U-boot/Status

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012996: mes: ftbfs with GCC-12

[Vagrant Cascadian]

Control: severity 1012996 important

On 2022-07-22, Vagrant Cascadian wrote:
> Looks like mes 0.24 test suite failed with GCC-12?
>
> I have not yet tried to reproduce it myself, but this is a bigger issue
> now that GCC-12 is the default compiler in Debian.

Yup, definitely fails with gcc-12.

I've uploaded 0.24-2 to Debian which uses gcc-11 to work around the
problem for now; downgrading the severity accordingly.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1016955: makedumpfile - does not work on arm64 since 5.18

[dann frazier]

On Wed, Aug 10, 2022 at 04:23:56PM +0200, Bastian Blank wrote:
> I don't know how to debug it.  With older versions it works.  On amd64 it 
> also works.

hey Bastian,

makedumpfile often needs updates to adjust to changes in upstream
kernel internals, and that tends to lag the kernel releases
themselves. If you'd like to help accelerate that, one option might be
to report it upstream and possibly provide bisect results showing the
kernel change to which makedumpfile needs to adapt.

  -dann

Bug#1016962: ITP: swift-im -- C++ library for implementing XMPP applications

[Tobias Frost]

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

* Package name: swift-im
  Version : 5.0~alpha2
  Upstream Author : Kevin Smith
* URL : https://swift.im
* License : GPL3
  Programming Lang: C++
  Description : C++ library for implementing XMPP applications and XMPP 
client

(reintroducing the package; swift-im has been previoulsy removed from Debian,
#950770)

Swiften is a robust, high-quality, standards-compliant, cross-platform,
and performant C++ library for implementing XMPP applications. Swiften
is used as the back-end library for the Swift Instant Messaging client.

Swift is a free instant messaging client. It concentrates on making
the most-used features easily accessible, supporting
internationalisation, private and group chats, together with features
for security-conscious organisations including Security Labelling.

Swift uses the XMPP protocol and so supports both the public Jabber
network and closed XMPP services, such as those found in many
organisations.

I'm Packaging swiften as a depdency for Spectrum2
(https://github.com/SpectrumIM/spectrum2)


Co-Maintainers welcome.

--
tobi

Bug#1015759: Current behaviour is documented here

[Roland Clobus]

On 2022-08-07 the Wiki page was updated, independent of this ticket.
https://wiki.debian.org/SecureBoot/VirtualMachine#Change_the_boot_order

Today I added a link to this ticket in the Wiki page.

It would indeed be nice to have the boot order changed, because that 
will enable openQA (https://openqa.debian.net) to run tests with UEFI 
secure boot enabled. See also 
https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/merge_requests/3


With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016961: RM: rust-trust-dns-proto [mips64el mipsel ppc64el s390x] -- NBS; build dependencies not available on some architectures

[Reinhard Tartler]

Package: ftp.debian.org
Severity: normal

Before version 0.21.2-5 the package would build on all archictures but fail
autopkgtest on mips64el mipsel ppc64el s390x. I've add Build-Depends to ensure
the package is only built on architectures that this package is actually usable
on.

Please remove the obsolte binaries from version 0.21.2-4 to allow migration of
version 0.21.2-5 to testing

Bug#1016960: nautilus-python: Doesn't work with nautilus 43

[Jeremy Bicha]

Source: nautilus-python
Severity: serious
Version: 1.2.3-3.1
Forwarded: https://gitlab.gnome.org/GNOME/nautilus-python/-/merge_requests/9

nautilus-python doesn't work with nautilus 43. Sadly, nautilus-python
looks unmaintained upstream so it's unclear when this issue will be
resolved.

nautilus 43 is a major upgrade. It switched to GTK4. The extension API
had major changes.

Nautilus 43 is available in Debian experimental. However, it may be
difficult to install because it uses gnome-desktop 43 and you'll need
everything you're using to be built against gnome-desktop 43 also.
Perhaps the easiest way to handle this if you don't want to wait for
the gnome-desktop transition to begin is to revert 4420025 in nautilus
and the corresponding bump in debian/control.in and rebuild nautilus.

Thank you,
Jeremy Bicha

Bug#1016224: binutils-z80: FTBFS: stdlib.h:134:10: error: argument 1 is null but the corresponding size argument 3 value is [128, 9223372036854775807] [-Werror=nonnull]

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Fri, Jul 29, 2022 at 06:20:14PM +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.

> > In function ‘mbstowcs’,
> > inlined from ‘read_symbol_name’ at read.c:1670:11:
> > /usr/include/x86_64-linux-gnu/bits/stdlib.h:134:10: error: argument 1 is 
> > null but the corresponding size argument 3 value is [128, 
> > 9223372036854775807] [-Werror=nonnull]
> >   134 |   return __mbstowcs_alias (__dst, __src, __len);
> >   |  ^~

Hi,

this has been fixed in binutils upstream, is the normal binutils
package not affected?

   
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5858ac626e548772407c038b09b7837550b127dd

I can fix this in binutils-z80 but I'd rather have the fix in the
binutils-source package directly.

Berto

Bug#1016959: ITP: nusolve -- Geodetic VLBI data analysis software

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: nusolve
  Version : 0.7.6
  Upstream Authors: Sergei Bolotin 
  URL : https://sourceforge.net/projects/nusolve/
* License : GPL-3-or-later
  Description : Geodetic VLBI data analysis software
 This is the GSFC VLBI Analysis Center's latest software package for 
analyzing
 Very Long Baseline Interferometry observations. It allows the 
estimation of
 parameters such as station positions and Earth orientation parameters. 
It
 currently supports the processing of individual sessions in the 
Mark-III
 database and vgosDb formats. The processing may be done interactively, 
from a

 command prompt, or by using scripting.

You can already test it if you can't wait, find it at 
http://sid.ethz.ch/debian/nusolve/

Bug#1016516: notion: Notion fails on startup (in sid)

[Göran Weinholt]

Dima Kogan  writes:

> Thanks, Göran and Jurij. So are we done? If we're confident, I'll upload
> a new notion with the relevant Depends: and close this bug.

Well, pthreads needs to be pulled in some way and then things will be
fine.

Were you planning on putting a later libc6 in Depends:? I hope you're
aware that libc6 is named differently on some archs. If it was me then I
would not want the maintenance burden of that solution. It also seems
like notion should not need to be fixed because the bug is not in
notion.

Personally I think libx11 should be built with -pthread since it is
where the use of pthreads comes from. That would fix this problem for
the other affected X clients.

You could also reassign this bug to libx11-6 and close it. The bug is
really in libx11 1.8.1-1 and is worked around in libx11 1.8.1-2. If a
later libx11 enables the threading stuff again then it should also take
care to build with -pthread so that these problems don't reappear.

Best regards,

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

Bug#1016928: override: telnet:optional/oldlibs, inetutils-telnet:standard/net, telnetd:optional/oldlibs

[Sean Whitton]

Hello,

On Wed 10 Aug 2022 at 01:00PM +02, Guillem Jover wrote:

> Hi!
>
> On Tue, 2022-08-09 at 20:42:15 -0700, Sean Whitton wrote:
>> On Wed 10 Aug 2022 at 01:53AM +02, Guillem Jover wrote:
>>
>> > Package: ftp.debian.org
>> > Severity: wishlist
>> > User: ftp.debian@packages.debian.org
>> > Usertags: override
>> > User: guil...@debian.org
>> > Usertags: inetutils-default-telnet-switch inetutils-default-telnetd-switch
>
>> > Please update the overrides for these telnet related packages, as part
>> > of the netkit to inetutils telnet "default" implementation switch.
>> >
>> >   
>>
>> Done these, though I'm not so sure about the oldlibs for the
>> transitional packages if you're planning to remove them the very next
>> release cycle -- normally we don't bother changing overrides for that.
>
> Thanks! And oh, had not heard this before.
>
> Well the oldlibs is machine-readable way to convey that these are
> obsolete packages (given that we lack a proper obsolete section), that
> help both humans (f.ex. via grouping in the aptitude section subtree),
> or QA programs. So, I've never thought their life expectancy would be
> relevant. :)

I think it's because override changes are manual and there are a lot of
transitional packages each release, so it would be a lot of work for not
so much gain.

-- 
Sean Whitton

Bug#1016957: kbd-chooser: please add support for riscv64

[Bo YU]

Source: kbd-chooser
Version: 1.71
Severity: wishlist
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear kbd-chooser Maintainer,

The kbd-chooser package can be built on real riscv64 hardware
successfully and it is ok to run autopkgtest also. Could you please add
support for riscv64?

The MR is here:
https://salsa.debian.org/installer-team/kbd-chooser/-/merge_requests/2


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1016956: RFS: lsb-release-minimal/0.6-1 -- Linux Standard Base version reporting utility (minimal implementation)

[Gioele Barabucci]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lsb-release-minimal":

 * Package name: lsb-release-minimal
   Version : 0.6-1
   Upstream Author : Gioele Barabucci
 * URL : https://gioele.io/lsb-release-minimal
 * License : ISC
 * Vcs : https://salsa.debian.org/gioele/lsb-release-minimal
   Section : misc

The source builds the following binary packages:

  lsb-release-minimal - Linux Standard Base version reporting utility 
(minimal implementation)


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


  https://mentors.debian.net/package/lsb-release-minimal/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lsb-release-minimal/lsb-release-minimal_0.6-1.dsc


Changes since the last upload:

 lsb-release-minimal (0.6-1) unstable; urgency=medium
 .
   * New upstream release
   * d/control: Build-Depend on bats for the testsuite
   * d/gitlab-ci: Add standard CI instructions
   * d/tests: Add autopkgtests

Regards,

--
Gioele Barabucci

Bug#1016955: makedumpfile - does not work on arm64 since 5.18

[Bastian Blank]

Package: makedumpfile
Version: 1:1.7.1-1
Severity: important

makedumpfile does not work since around 5.18.4 on arm64.  As used by
kdump-tools, it just errors out:

| running makedumpfile --dump-dmesg /proc/vmcore 
/var/crash/202208101323/dmesg.202208101323.
| read_from_vmcore: Can't seek the dump memory(/proc/vmcore). (offset: 
a8d9a3fd6000) Invalid argument
| readpage_elf: Can't read the dump memory(/proc/vmcore).
| readmem: type_addr: 1, addr:5cc8a88, size:8
| vaddr_to_paddr_arm64: Can't read pgd
| readmem: Can't convert a virtual address(a8d99e0e8128) to physical 
address.
| readmem: type_addr: 0, addr:a8d99e0e8128, size:390
| check_release: Can't get the address of system_utsname.
| makedumpfile Failed.
| kdump-tools: makedumpfile --dump-dmesg failed. dmesg content will be 
unavailable ... failed!
| kdump-tools: failed to save dmesg content in /var/crash/202208101323 ... 
failed!
| running makedumpfile -F -c -d 31 /proc/vmcore | compress > 
/var/crash/202208101323/dump-incomplete.
| read_from_vmcore: Can't seek the dump memory(/proc/vmcore). (offset: 
a8d9a3fd6000) Invalid argument
| readpage_elf: Can't read the dump memory(/proc/vmcore).
| readmem: type_addr: 1, addr:5cc8a88, size:8
| vaddr_to_paddr_arm64: Can't read pgd
| readmem: Can't convert a virtual address(a8d99e0e8128) to physical 
address.
| readmem: type_addr: 0, addr:a8d99e0e8128, size:390
| check_release: Can't get the address of system_utsname.
| makedumpfile Failed.
| kdump-tools: saved vmcore in /var/crash/202208101323.

I don't know how to debug it.  With older versions it works.  On amd64 it also 
works.

Bastian

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

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

Versions of packages makedumpfile depends on:
ii  libc6  2.33-8
ii  libdw1 0.187-1
ii  libelf10.187-1
ii  liblzo2-2  2.10-2
ii  perl   5.34.0-5
ii  zlib1g 1:1.2.11.dfsg-4

Versions of packages makedumpfile recommends:
ii  crash8.0.0-1
pn  kexec-tools  

makedumpfile suggests no packages.

Bug#1016954: cdimage.debian.org: Installing from live system sets up LUKS1 partitions instead of LUKS2

[Legner, Markus]

Package: cdimage.debian.org
Severity: normal
X-Debbugs-Cc: markus.leg...@siemens.com

Dear Maintainer,

I've found some inconsistent installation behavior between the "normal"
installer and the installer from the live system on the live image [1]:

When choosing to encrypt the system, the installer from the live system
sets up
LUKS1, while the normal installer (from the same image) sets up a LUKS2
partition. I'm not sure if this is intentional but it's definitely
unexpected
considering the announcement of using LUKS2 by default already in
Buster [2].
(There are some other inconsistencies as well; for example the LVM
option.)

Kind regards,
Markus

[1]
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-
firmware/current-live/amd64/iso-hybrid/debian-
live-11.4.0-amd64-gnome+nonfree.iso
[2]
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-
new.en.html#cryptsetup-luks2

Bug#992621: pkgconf: Vcs-Git does not point to current version

[Andrej Shadura]

On Sat, 21 Aug 2021 11:57:25 +0100 Simon McVittie  wrote:

Source: pkgconf
Severity: minor

The pkgconf packaging branch has been changed from debian/master to
debian/unstable, but HEAD in the git repo referenced by Vcs-Git has
not been updated. As a result,

$ gbp clone vcsgit:pkgconf

results in obtaining an outdated version.

You can fix this by visiting
https://salsa.debian.org/debian/pkgconf/-/settings/repository
and changing "Default branch" to debian/unstable.

(Technically I could do this myself, since pkgconf is in the debian group,
but I didn't want to make repo configuration changes without notifying a
maintainer.)

It might also be a good idea to delete the out-of-date debian/master branch.


Thanks for the report, I have fixed the issue with the Git repo.

--
Cheers,
  Andrej

Bug#1016953: intel-media-driver: FTBFS on i386: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’

[Simon McVittie]

Source: intel-media-driver
Version: 22.5.1+dfsg1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

intel-media-driver failed to build on i386, breaking multiarch
co-installation of amd64 and i386 driver libraries.

https://buildd.debian.org/status/fetch.php?pkg=intel-media-driver=i386=22.5.1%2Bdfsg1-1=1659479611=0

/<>/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp:
 In static member function ‘static MOS_STATUS 
MosUtilitiesSpecificNext::UserFeatureDumpDataToFile(const char*, 
MOS_PUF_KEYLIST)’:
/<>/media_softlet/linux/common/os/osservice/mos_utilities_specific.cpp:1023:44:
 error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 
3 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Werror=format=]
 1023 | fprintf(File, "\t\t\t%lu\n",
  |  ~~^
  ||
  |long unsigned int
  |  %llu
 1024 | 
*(uint64_t*)(pKeyTmp->pElem->pValueArray[j].ulValueBuf));
  | 
~~~
  | |
  | uint64_t {aka long long unsigned int}

The solution might be as simple as including  or ,
and using "%" PRIu64 instead of "%lu". I'm testing that now.

smcv

Bug#1016922: pkgconf: fails to find spirv

[Andrej Shadura]

Hi,

On Tue, 9 Aug 2022, at 22:47, Peter Green wrote:
> glslang-dev provides spirv.pc, unfortunately it seems
> pkgconf is unable to use it. This leads to builds of
> filament breaking if pkgconf happens to be installed.

Version 1.6.0 is in oldstable — could you please test with more up-to-date 
versions of both pkgconf and spirv?
Thanks!

-- 
Cheers,
  Andrej

Bug#1004326: libnss-systemd: postinst modification of /etc/nsswitch.conf forgets (g)shadow

[Michael Biebl]

Control: tags -1 + pending

On Tue, 25 Jan 2022 00:37:12 +0100 Robert Siemer 
 wrote:

Package: libnss-systemd
Version: 250.3-1
Severity: normal
X-Debbugs-Cc: robert.siemer-report...@backsla.sh

/var/lib/dpkg/info/libnss-systemd\:i386.postinst does not add
`systemd` on the shadow and gshadow lines of /etc/nsswitch.conf,
only passwd and group.

All four dbs should have `systemd` added according to
man page nss-systemd(8).

I guess the manual page got corrected without it going into the
postinst script, isn’t it?


This has been fixed in git
https://salsa.debian.org/systemd-team/systemd/-/commit/bf9a307cfcbe62ab4fbcf2198e6e628a1bca211b


OpenPGP_signature
Description: OpenPGP digital signature

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: sncosmo -- Python library for high-level supervova 
cosmology analysis
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#850195: Taking over ITP

[Ole Streicher]

Control: retitle -1 ITP: extinction -- Fast interstellar dust extinction laws
Control: owner -1 !

I take over this one to get sncosmo finally into Debian

Bug#1016952: ITP: gmx-mmpbsa -- end-state free energy calculations with GROMACS files

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 1015857

* Package name: gmx-mmpbsa
  Version : 1.5.6+ds
  Upstream Author : Mario S. Valdes-Tresanco and
Mario E. Valdes-Tresanco
* URL : https://valdes-tresanco-ms.github.io/gmx_MMPBSA/dev/
* License : GPL-3.0
  Programming Lang: Python 3
  Description : end-state free energy calculations with GROMACS files

gmx_MMPBSA is a tool based on AMBER's MMPBSA.py aiming to perform
end-state free energy calculations with GROMACS files.

Remark: This package is to be maintained with Debichem Team at
   https://salsa.debian.org/debichem-team/gmx-mmpbsa

Bug#1016951: intel-compute-runtime: FTBFS with GCC 12

[Andreas Beckmann]

Source: intel-compute-runtime
Version: 22.14.22890-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

intel-compute-runtime started to FTBFS when GCC 12 was made the default
compiler:

In file included from /usr/include/c++/12/string:50,
 from 
/build/intel-compute-runtime-22.14.22890/shared/source/utilities/const_stringref.h:13,
 from 
/build/intel-compute-runtime-22.14.22890/shared/source/device_binary_format/ar/ar.h:10,
 from 
/build/intel-compute-runtime-22.14.22890/shared/source/device_binary_format/ar/ar_encoder.h:10,
 from 
/build/intel-compute-runtime-22.14.22890/shared/source/device_binary_format/ar/ar_encoder.cpp:8:
In static member function 'static _Tp* std::__copy_move<_IsMove, true, 
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with 
_Tp = unsigned char; bool _IsMove = true]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = 
true; _II = unsigned char*; _OI = unsigned char*]' at 
/usr/include/c++/12/bits/stl_algobase.h:495:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = 
true; _II = unsigned char*; _OI = unsigned char*]' at 
/usr/include/c++/12/bits/stl_algobase.h:522:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = 
true; _II = unsigned char*; _OI = unsigned char*]' at 
/usr/include/c++/12/bits/stl_algobase.h:529:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II = 
move_iterator; _OI = unsigned char*]' at 
/usr/include/c++/12/bits/stl_algobase.h:620:7,
inlined from 'static _ForwardIterator 
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator, 
_ForwardIterator) [with _InputIterator = std::move_iterator; 
_ForwardIterator = unsigned char*]' at /usr/include/c++/12/bits/stl_unini
tialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator, 
_InputIterator, _ForwardIterator) [with _InputIterator = move_iterator; _ForwardIterator = unsigned char*]' at 
/usr/include/c++/12/bits/stl_uninitialized.h:185:15,
inlined from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator, 
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator = 
move_iterator; _ForwardIterator = unsigned char*; _Tp = 
unsigned char]' at /usr/include/c++/12/bits/st
l_uninitialized.h:372:37,
inlined from '_ForwardIterator 
std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator, 
_ForwardIterator, _Allocator&) [with _InputIterator = unsigned char*; 
_ForwardIterator = unsigned char*; _Allocator = allocator]' at 
/usr/include/c++
/12/bits/stl_uninitialized.h:397:2,
inlined from 'void std::vector<_Tp, _Alloc>::_M_range_insert(iterator, 
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with 
_ForwardIterator = const unsigned char*; _Tp = unsigned char; _Alloc = 
std::allocator]' at /usr/include/c++/12/b
its/vector.tcc:801:9,
inlined from 'void std::vector<_Tp, _Alloc>::_M_insert_dispatch(iterator, 
_InputIterator, _InputIterator, std::__false_type) [with _InputIterator = const 
unsigned char*; _Tp = unsigned char; _Alloc = std::allocator]' 
at /usr/include/c++/12/bits/stl_vec
tor.h:1779:19,
inlined from 'std::vector<_Tp, _Alloc>::iterator std::vector<_Tp, 
_Alloc>::insert(const_iterator, _InputIterator, _InputIterator) [with 
_InputIterator = const unsigned char*;  = void; _Tp = 
unsigned char; _Alloc = std::allocator
]' at /usr/include/c++/12/bits/stl_vector.h:1481:22,
inlined from 'std::vector NEO::Ar::ArEncoder::encode() 
const' at 
/build/intel-compute-runtime-22.14.22890/shared/source/device_binary_format/ar/ar_encoder.cpp:58:15:
/usr/include/c++/12/bits/stl_algobase.h:431:30: error: 'void* 
__builtin_memcpy(void*, const void*, long unsigned int)' writing between 1 and 
18446744073709551615 bytes into a region of size 0 [-Werror=stringop-overflow=]
  431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  | ~^~~
In file included from 
/usr/include/x86_64-linux-gnu/c++/12/bits/c++allocator.h:33,
 from /usr/include/c++/12/bits/allocator.h:46,
 from /usr/include/c++/12/string:41:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const 
void*) [with _Tp = unsigned char]',
inlined from 'static _Tp* std::allocator_traits 
>::allocate(allocator_type&, size_type) [with _Tp = unsigned char]' at 
/usr/include/c++/12/bits/alloc_traits.h:464:28,
inlined from 'std::_Vector_base<_Tp, _Alloc>::pointer 
std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = unsigned 
char; _Alloc = std::allocator]' at 
/usr/include/c++/12/bits/stl_vector.h:378:33,
inlined from 'void std::vector<_Tp, _Alloc>::_M_range_insert(iterator, 
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with 

Bug#881965: tagging 881965

[Guido Günther]

tags 881965 + patch
thanks

Patch is at https://salsa.debian.org/matrix-team/nheko/-/merge_requests/4

Bug#1016950: RFP: libcrypt-openssl-ca-perl - module to issue X509 certificates and certificate revocation lists (CRL)

[Stuart Meek]

Package: wnpp
Severity: wishlist

Package name : libcrypt-openssl-ca-perl
Version  : 0.91
Upstream Author  : ?
URL  : https://metacpan.org/pod/Crypt::OpenSSL::CA
License  : perl_5
Programming Lang : Perl
Description  : Crypt::OpenSSL::CA - The crypto parts of an X509v3
Certification Authority

We seem to have all the other bits of Crypt::OpenSSL, except this one.

Bug#1016949: iwyu not performant

[Steven Trabert]

Package: iwyu
Version: iwyu 8.17-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
X-Debbugs-Cc: tstev...@gmail.com

Dear Maintainer,


   * What led up to the situation?
   Using iwyu takes and inordinate amount of time.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   As shown in the build logs iwyu was compiled without any optimization.  By
   setting CMAKE_BUILD_TYPE=Release optimization is used in the compilation.
   * What was the outcome of this action?
   In one of my use cases the execution time of iwyu went from 3m12s to 1m1s.
   * What outcome did you expect instead?
   Reduced execution time was expected with optimization.


In Ubuntu, the attached patch was applied to achieve the following:

This change is needed to make iwyu performant.  While iwyu currently is
functional execution is quite slow.


  * set CMAKE_BUILD_TYPE=Release to make executable performant 


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-43-generic (SMP w/2 CPU threads)
Kernel taint flags: 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
diff -Nru iwyu-8.17/debian/rules iwyu-8.17/debian/rules
--- iwyu-8.17/debian/rules  2021-12-09 05:25:36.0 -0700
+++ iwyu-8.17/debian/rules  2022-08-10 05:34:02.0 -0600
@@ -22,7 +22,7 @@
 
 
 override_dh_auto_configure:
-   dh_auto_configure -- -DCMAKE_CXX_FLAGS="$(ADDITIONAL_CXX_FLAGS)" 
-DLLVM_PATH=/usr/lib/llvm-12/ -DCMAKE_PREFIX_PATH=/usr/lib/llvm-12/
+   dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_CXX_FLAGS="$(ADDITIONAL_CXX_FLAGS)" -DLLVM_PATH=/usr/lib/llvm-12/ 
-DCMAKE_PREFIX_PATH=/usr/lib/llvm-12/
 
 
 override_dh_auto_build:

Bug#1012999: Avoiding removal from testing (attempt)

[Geert Stappers]

Control: notfound -1 8.1-2

Hi,

This e-mail is (an attempt) to prevent
that msc-generator gets removed from testing.


Originally was the bugreport serverity normal
and had the request "leave it to us".

Later became the serverity "serious"

The "leave it us" is still a good thing.
Yes, I appriciate the work that "archive rebuild people" do.

But the unpredicable next rebuild run.

http://qa-logs.debian.net/2022/04/
Index of /2022/04
[ICO]   NameLast modified   SizeDescription
[PARENTDIR] Parent Directory-
[DIR]   12/ 2022-04-12 18:36-
Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80

http://qa-logs.debian.net/2022/05/
Index of /2022/05
[ICO]   NameLast modified   SizeDescription
[PARENTDIR] Parent Directory-
[DIR]   25/ 2022-05-26 05:47-
Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80

http://qa-logs.debian.net/2022/06/
Index of /2022/06
[ICO]   NameLast modified   SizeDescription
[PARENTDIR] Parent Directory-
[DIR]   09/ 2022-06-10 18:50-
[DIR]   10/ 2022-06-11 20:24-
[DIR]   23/ 2022-06-23 06:25-
[DIR]   24/ 2022-06-24 06:40-
Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80

http://qa-logs.debian.net/2022/07/
Index of /2022/07
[ICO]   NameLast modified   SizeDescription
[PARENTDIR] Parent Directory-
[DIR]   16/ 2022-07-16 12:45-
[DIR]   28/ 2022-07-29 13:20-
Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80

http://qa-logs.debian.net/2022/08/
Not Found

The requested URL was not found on this server.
Apache/2.4.54 (Debian) Server at qa-logs.debian.net Port 80



At https://buildd.debian.org/status/logs.php?pkg=msc-generator
could I not find a full log. But I have seen that msc-generator
builds with GCC 12.1, so now this close message.
That is what the 'Control: notfound -1 8.1-2' should do.


Regards
Geert Stappers
DD

P.S.
The https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012999#29
question: 'Where to find information about the rebuild schedule?'
is still valid
-- 
Silence is hard to parse

Bug#1016765: webkit2gtk: Please enable gtk4 build

[Alberto Garcia]

On Sat, Aug 06, 2022 at 05:20:14PM -0400, Jeremy Bicha wrote:
> Please consider enabling the gtk4 build. It is required for
> gnome-initial-setup 43:
> https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/NEWS

Yeah we need to enable this build at some point so maybe it's not a
bad moment.

Berto

Bug#618511: Xplanet generates unreadable text labels

[Alexander Reichle-Schmehl]

Hi Timo!

A couple of years ago you reported a bug against the xplanet package in 
Debian, and I just stumbled over that bug report.


I tried to reproduce it with the xplanet package 1.3.0-5.1 - the version 
which is currently shipped in Debians stable release, but unfortunatly I 
was unable to reproduce it.


Using 
https://upload.wikimedia.org/wikipedia/commons/e/e9/Location_map_Japan.png 
as a replacement for your japan.png and running the exakt command you 
gave with the configuration and markers file you provided with the bug 
report, I got a readable output.



Could you please retry it, and if you still have a problem provide an 
example of the result?  By now the link you provided in your original 
report doesn't work anymore :(




Best regards,
  Alexander

Bug#618511: Xplanet generates unreadable text labels

[Alexander Reichle-Schmehl]

tags 618511 + unreproducible moreinfo
thanks

Hi!

Using the configration example from the submitter, I was unable to 
reproduce the bug with xplanet 1.3.0-5.1 package in stable (nor with the 
1.3.1-1 I'm currently preparing).


Using 
https://upload.wikimedia.org/wikipedia/commons/e/e9/Location_map_Japan.png 
as replacement for japan.png I got the attached result (cropped to the 
text).



Best regards,
  Alexander

Bug#961867: #961867 python3?-talloc multiarch support is broken because of the dependency on python

[Francois Gouget]

Michael Tokarev wrote:
> Aside of this package being M-A:same, how do you plan to *use* both
> i386 and amd64 versions of this package?

Sorry, I did not see that message.

Anyway, I don't plan on using both i386 and amd64 versions of 
the python-talloc package. What I do want is to use both the i386 and 
amd64 versions of the samba-dev and samba-libs packages which both 
depend on the corresponding python3?-talloc package:

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

So if it does indeed make no sense for python-talloc to be MultiArch: 
same, then I'm fine for this bug to be closed. But then it is Samba that 
should really be fixed.


-- 
Francois Gouget   http://fgouget.free.fr/
  Good judgment comes from experience, and experience comes from bad judgment
   -- Barry LePatner

Bug#1016928: override: telnet:optional/oldlibs, inetutils-telnet:standard/net, telnetd:optional/oldlibs

[Guillem Jover]

Hi!

On Tue, 2022-08-09 at 20:42:15 -0700, Sean Whitton wrote:
> On Wed 10 Aug 2022 at 01:53AM +02, Guillem Jover wrote:
> 
> > Package: ftp.debian.org
> > Severity: wishlist
> > User: ftp.debian@packages.debian.org
> > Usertags: override
> > User: guil...@debian.org
> > Usertags: inetutils-default-telnet-switch inetutils-default-telnetd-switch

> > Please update the overrides for these telnet related packages, as part
> > of the netkit to inetutils telnet "default" implementation switch.
> >
> >   
> 
> Done these, though I'm not so sure about the oldlibs for the
> transitional packages if you're planning to remove them the very next
> release cycle -- normally we don't bother changing overrides for that.

Thanks! And oh, had not heard this before.

Well the oldlibs is machine-readable way to convey that these are
obsolete packages (given that we lack a proper obsolete section), that
help both humans (f.ex. via grouping in the aptitude section subtree),
or QA programs. So, I've never thought their life expectancy would be
relevant. :)

Thanks,
Guillem

Bug#1014488: scapy: flaky autopkgtest: No such file or directory: 'isotpsend'

[Neil Williams]

On Wed, 6 Jul 2022 21:42:22 +0200 Paul Gevers  wrote:
> 
> I looked at the results of the autopkgtest of you package on arm64 
> because it was showing up as a regression for the upload of openssl.
> I noticed that the test regularly fails and I saw failures on other 
> architectures too, even in stable.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
> 
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

The autopkgtests work in Salsa but are also quite messy & the package
isn't in great shape overall. For now, I'm going to adjust the
dependencies to see if isotpsend support can be provided inside
autopkgtest. If that fails, the upstream tests will need to be confined
to Salsa and autopkgtests limited only to autopkgtest-pkg-python.

https://salsa.debian.org/pkg-security-team/scapy/-/commit/59a4c0e2ed8c24cf5a3d4412cecdd5086a5b0395

-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgpScksa2k0y1.pgp
Description: OpenPGP digital signature

Bug#1016948: ITP: elpa-compat -- COMPATibility Library for Emacs

[Aymeric Agon-Rambosson]

Package: wnpp
Owner: Aymeric Agon-Rambosson 
Severity: wishlist

* Package name: elpa-compat
 Version : 28.1.2.0
 Upstream Author : Philip Kaludercic
* URL or Web page : https://sr.ht/~pkal/compat/
* License : GPL-3+
 Description : COMPATibility Library for Emacs

This package is a dependency of another ITP of mine, elpa-consult 
(1016946).


The goal is to provide emacs package developers with symbols that 
have not yet been implemented in an emacs version they are 
targeting.

Bug#1016937: atop: autopkgtest regression on arm64 and armhf and times out on s390x

[Marc Haber]

On Wed, Aug 10, 2022 at 08:06:29AM +0200, Paul Gevers wrote:
> I looked at the results of the autopkgtest of you package because it was
> showing up on our page for long running tests on s390x. I noticed that the
> test always fails on s390x with an autopkgtest timeout. Your package
> regressed on armhf and arm64 around April 2022.
> 
> Regressions in testing on amd64 and arm64 are considered RC by the release
> team [1]. Tests that time out and fail while normally running quickly are a
> serious burden on our infrastructure, please try to prevent the apparent
> hang.
> 
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.
> 
> Paul
> 
> https://ci.debian.net/packages/m/mercurial/testing/amd64/
> 
> [1] https://release.debian.org/testing/rc_policy.txt (section 6.a)

Unfortunately, this bug report suffers from multiple cut or
template error. The ci link points to the mercurial page for amd64, the
text alternates between s390s, armhf, arm64 and amd64.

I tried the (dead simple) autopkgtest on the s390s and arm64 porterboxes
and it succeeded in a second's time. I have sharpened the expression
that counts the CPUs in lscpu's output and hope this will fix the issue.

I also fixed a syntax error in the test, but that should cause the test
to error out and not hang.

Can you find out in which line the autopkgtest stalls?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1016931: Still some problems

[Bob Wong]

Sorry to bother you, I'm new to Linux and don't know how to use systemd to
view the waiting processes it was waiting for, could you please tell me
some information about it? I searched on the web but get no luck.

Regards,
Bob Wong