Bug#1019374: deb-scrub-obsolete crashes with AttributeError

[Marcin Owsiany]

Package: lintian-brush

Please see
https://janitor.debian.net/cupboard/pkg/apt-forktracer/b292a431-c8b4-421b-9c7f-b3555ead4046/

Removing run time and build time constraints unnecessary since
busterTraceback (most recent call last):  File
"/code/lintian-brush/scripts/deb-scrub-obsolete", line 4, in 
  main()  File "/code/lintian-brush/lintian_brush/scrub_obsolete.py",
line 712, in mainresult = scrub_obsolete(  File
"/code/lintian-brush/lintian_brush/scrub_obsolete.py", line 529, in
scrub_obsolete+ release_aliases(release))  File
"/code/lintian-brush/lintian_brush/scrub_obsolete.py", line 471, in
release_aliasesdebian_distro_info.unstable:
'unstable',AttributeError: 'DebianDistroInfo' object has no attribute
'unstable'. Did you mean: 'stable'?

Bug#1019373: evolution: Cannot send mail

[Michael Ott]

Package: evolution
Version: 3.45.3-2
Severity: important

Dear Maintainer,

I try to send a simple mail but it does not work with this following message:
The reported error was "Source "m...@address.org" doesn't support prompt for 
credentials"
I can get mails from this mail account


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (710, 'unstable'), (670, 'testing'), (660, 'experimental'), (600, 
'stable'), (500, 'stable-security'), (500, 'oldstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

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

Versions of packages evolution depends on:
ii  dbus [default-dbus-system-bus]  1.14.99~git20220715-1
ii  evolution-common3.45.3-2
ii  evolution-data-server   3.45.3-2
ii  libc6   2.35-0experimental2
ii  libcamel-1.2-64 3.45.3-2
ii  libecal-2.0-2   3.45.3-2
ii  libedataserver-1.2-27   3.45.3-2
ii  libevolution3.45.3-2
ii  libglib2.0-02.73.3-3
ii  libgtk-3-0  3.24.34-3
ii  libical33.0.14-1+b1
ii  libnotify4  0.8.1-1
ii  libxml2 2.9.14+dfsg-1+b1
ii  psmisc  23.5-3

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter3.45.3-2
ii  evolution-plugin-pstimport 3.45.3-2
ii  evolution-plugin-spamassassin  3.45.3-2
ii  evolution-plugins  3.45.3-2
ii  yelp   42.1-2

Versions of packages evolution suggests:
pn  evolution-ews   
ii  evolution-plugins-experimental  3.45.3-2
ii  gnupg   2.2.39-1
ii  network-manager 1.40.0-1

-- no debconf information

Bug#1018753: abiword: FTBFS on several platforms (test timeout)

[Jonas Smedegaard]

Quoting Jeremy Bicha (2022-09-07 22:21:57)
> I am uploading a NMU now with high urgency to allow the ongoing
> evolution-data-server transition to proceed smoothly.

Thanks you both, Eric and Jeremy,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#1019336: [Pkg-rust-maintainers] Bug#1019336: cargo: Cargo wrapper script adds additional '--target' command line parameter

[Seo Sanghyeon]

Note that PR to stabilize (for 1.64) -Zmultitarget was merged upstream
so this problem will solve itself.
https://github.com/rust-lang/cargo/pull/10766

-- 
Seo Sanghyeon

Bug#1019372: python-build: New Upstream version available

[Matthias Urlichs]

Source: python-build
Version: 0.1.0-3
Severity: minor
X-Debbugs-Cc: sm...@smurf.noris.de

Upstream has tagged 0.8.0. Please package.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (720, 'testing'), (700, 'stable'), (600, 'oldstable'), (500, 
'stable-security'), (500, 'unstable'), (450, 'focal'), (350, 'oldoldstable'), 
(300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

Bug#1019367: libreoffice: grep warnings on upgrade

[Rene Engelhard]

Hi,

Am 08.09.22 um 04:39 schrieb Rene Engelhard:

Am 08.09.22 um 01:34 schrieb Ash Joubert:
recent grep/egrep changes on sid cause many warnings on libreoffice 
upgrade:

Yes. saw it too. grep 3.8...


Also note there is also 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019335 with the 
release team (for now) blocking that grep to migrate to testing...


Regards,

Rene

Bug#1019371: fritzing: Forward startup script options to the real binary

[Celelibi]

Package: fritzing
Version: 0.9.6+dfsg-2+b1
Severity: minor

Dear Maintainer,

The command 'fritzing' is a shell script that copies and links a bunch
of files in $HOME/.local/lib.fritzing, and then starts the (copied)
binary.

The actual binary has a few command line options.
But the way the script run it, the options are forgotten and not passed
down to the binary.

The fix should be as simple as changing the last line to:

exec ${LOCAL_FRITZING}/app/Fritzing "$@"


Best regards,
Celelibi


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

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

Versions of packages fritzing depends on:
ii  fritzing-data0.9.6+dfsg-2
ii  fritzing-parts   0.9.6~unreleased-1
ii  libc62.34-7
ii  libgcc-s112.2.0-1
ii  libgit2-1.3  1.3.0+dfsg.1-3
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5gui5   5.15.4+dfsg-5
ii  libqt5network5   5.15.4+dfsg-5
ii  libqt5printsupport5  5.15.4+dfsg-5
ii  libqt5serialport55.15.4-2
ii  libqt5sql5   5.15.4+dfsg-5
ii  libqt5sql5-sqlite5.15.4+dfsg-5
ii  libqt5svg5   5.15.4-2
ii  libqt5widgets5   5.15.4+dfsg-5
ii  libqt5xml5   5.15.4+dfsg-5
ii  libstdc++6   12.2.0-1
ii  zlib1g   1:1.2.11.dfsg-4.1

fritzing recommends no packages.

fritzing suggests no packages.

-- no debconf information

Bug#848578: Also running into this problem

[Francois Marier]

On 2022-09-07 at 12:42:31, Nicolas Schier (nico...@fjasle.eu) wrote:
> Francois, might you be able to patch your ts with the attached patch 
> and re-check?  As August has gone, I used
> 
> echo test | faketime "2022-08-01" ./ts
> 
> for testing with your specified locale settings.

I've patched my /usr/bin/ts as you indicated and the above works well now:

  $ echo test | faketime "2022-01-04" ts
  jan 04 00:00:00 test
  $ echo test | faketime "2022-02-04" ts
  fév 04 00:00:00 test
  $ echo test | faketime "2022-07-04" ts
  jui 04 00:00:00 test
  $ echo test | faketime "2022-08-04" ts
  aoû 04 00:00:00 test

Also, faketime is really handy!

Thanks.

Francois

Bug#1019370: debian-maintainers: The maintainer Matthias Klose no longer has a valid email.

[Trent Robbins]

Package: debian-maintainers
Severity: normal

Dear Maintainer,

This maintainer is no longer reachable at the provided email
d...@debian.org. The email redirected to d...@18xx.org and bounced.

https://qa.debian.org/developer.php?email=doko%40debian.org

The package Python 3.7 needs a security update to 3.7.14.

Thanks,
Trent

Bug#1019368: cgit: Please add --no-parallel to dh_auto_test

[Paul Wise]

On Thu, 8 Sep 2022 07:46:02 +0800 Sakura286 wrote:

> Could you please add --no-parallel to dh_auto_test? Because the outputs 
> of testing are mixed. [1]

In general, all builds/tests should be done in parallel unless the
parallel=n tag is set in DEB_BUILD_OPTIONS.

https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-deb-build-options

Probably the best option here is to patch the upstream Makefiles to use
the parallel output synchronisation feature of GNU make, then you get
both parallel tests and non-mixed testing output.

https://www.gnu.org/software/make/manual/html_node/Parallel-Output.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1019369: cgit: FTBFS on riscv64: t0109-git-config test failed on riscv64

[Paul Wise]

On Thu, 8 Sep 2022 07:41:38 +0800 Sakura286 wrote:

> On riscv64, "strace -e access cgit-1.2.3+git2.25.1/cgit" returned 
> "strace: invalid system call 'access'". And when "strace cgit" on 
> riscv64, "faccessat(AT_FDCWD,xx,yy)" rather than "access(xx,yy)" is called.
> 
> According to the manual of "access"[2], if passed AT_FDCWD, "faccessat" 
> behaves same as "access" [2]. So I add "-e faccessat" for riscv64. I 
> have tested the patch on amd64 and riscv64.

It might be worth just passing both functions to -e, so that if other
new architectures also use faccessat or if existing architectures start
using faccessat then the tests will continue to work.

Reading the documentation, this should work, but please test it:

   strace -e access,faccessat

When creating riscv64 patches, please keep this general principle in
mind. Try to make the package more portable in general rather than just
making the specific change that is needed for RISC-V. Doing porting in
an arch-specific way usually means more work for other porters later,
while often it is possible to eliminate future work by redesigning
suboptimal portability efforts instead of just patching them.

You will thank yourself when you start working on riscv32/riscv128 ;)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1019369: cgit: FTBFS on riscv64: t0109-git-config test failed on riscv64

[Sakura286]

Source: cgit
Version: 1.2.3+git2.25.1-1
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

cgit failed on riscv64 due to t0109-git-config test [1].

On riscv64, "strace -e access cgit-1.2.3+git2.25.1/cgit" returned 
"strace: invalid system call 'access'". And when "strace cgit" on 
riscv64, "faccessat(AT_FDCWD,xx,yy)" rather than "access(xx,yy)" is called.


According to the manual of "access"[2], if passed AT_FDCWD, "faccessat" 
behaves same as "access" [2]. So I add "-e faccessat" for riscv64. I 
have tested the patch on amd64 and riscv64.


The patch is attached below.

Regards,

Sakura286.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=cgit=riscv64=1.2.3%2Bgit2.25.1-1=1660429218


[2] https://man7.org/linux/man-pages/man2/faccessat.2.html
--- a/tests/t0109-gitconfig.sh
+++ b/tests/t0109-gitconfig.sh
@@ -15,6 +15,17 @@
exit
 }
 
+# When 'strace cgit' on riscv64, 'faccessat(AT_FDCWD,xx,yy)' rather than
+# 'access(xx,yy)' is called. If passed AT_FDCWD, 'faccessat' behaves
+# samely as 'access'.
+
+if [ $(uname -m) != 'riscv64' ]
+then
+   syscall_access='access'
+else
+   syscall_access='faccessat'
+fi
+
 test_no_home_access () {
non_existent_path="/path/to/some/place/that/does/not/possibly/exist"
while test -d "$non_existent_path"; do
@@ -24,7 +35,7 @@
-E HOME="$non_existent_path" \
-E CGIT_CONFIG="$PWD/cgitrc" \
-E QUERY_STRING="url=$1" \
-   -e access -f -o strace.out cgit &&
+   -e $syscall_access -f -o strace.out cgit &&
test_must_fail grep "$non_existent_path" strace.out
 }
 

Bug#1019367: libreoffice: grep warnings on upgrade

[Ash Joubert]

Package: src:libreoffice
Version: libreoffice/1:7.4.1~rc1-3
Severity: minor
X-Debbugs-Cc: a...@transient.nz

Dear Maintainer,

recent grep/egrep changes on sid cause many warnings on libreoffice upgrade:

Upgrade:

   libreoffice-base-core (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-calc (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-core (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-draw (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-gtk3 (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-impress (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-math (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)
   libreoffice-writer (1:7.4.1~rc1-3 => 1:7.4.1~rc1-3+b1)

Console:

Setting up libreoffice-core (1:7.4.1~rc1-3+b1) ...
Setting up libreoffice-math (1:7.4.1~rc1-3+b1) ...
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
Setting up libreoffice-gtk3 (1:7.4.1~rc1-3+b1) ...
Setting up libreoffice-draw (1:7.4.1~rc1-3+b1) ...
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
Setting up libreoffice-impress (1:7.4.1~rc1-3+b1) ...
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
Setting up libreoffice-base-core (1:7.4.1~rc1-3+b1) ...
Setting up libreoffice-calc (1:7.4.1~rc1-3+b1) ...
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E
Setting up libreoffice-writer (1:7.4.1~rc1-3+b1) ...
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
grep: warning: stray \ before /
egrep: warning: egrep is obsolescent; using grep -E
egrep: warning: egrep is obsolescent; using grep -E

Kind regards,
Ash.



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

Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libreoffice depends on:
pn  libreoffice-base
ii  libreoffice-calc1:7.4.1~rc1-3+b1
ii  libreoffice-core1:7.4.1~rc1-3+b1
ii  libreoffice-draw1:7.4.1~rc1-3+b1
ii  

Bug#1019366: ratpoison: focus{up,down,left,right} weird behavior

[Christopher Cramer]

Package: ratpoison
Version: 1.4.9-1
Severity: normal
Tags: patch
X-Debbugs-Cc: tsuyo...@yumegakanau.org

The focusup, focusdown, focusleft, and focusright commands, which move
to an adjacent frame, have some unintuitive behavior. For example,
suppose you have a grid of four equally-sized frames, arrayed in two
rows and two columns, like so:

0   1

2   3

And then suppose the original frame is 3, and you execute the focusup
command. Part of the algorithm is: if the left side of the original frame
is either aligned with or to the right of a frame, and if the left side of
the original frame is aligned with or to the left of the frame, move to
that frame. Because the left corner is numbered 0 and encountered first,
and it satisfies those conditions, it will move to frame 0, rather than 1,
which is what I would expect.

The included patch changes the algorithm of these commands to instead seek out
the frame which has the nearest left side (in the case of focusup and 
focusdown),
or the nearest top side (in the case of focusleft and focusright). So using the
above grid:

focusright will move from 0 to 1 or 2 to 3
focusleft will move from 1 to 0 or 3 to 2
focusdown will move from 0 to 2 or 1 to 3
focusup will move from 2 to 0 or 3 to 1

Which is exactly what I would expect.

diff -ur ratpoison-1.4.9/src/split.c new/ratpoison-1.4.9/src/split.c
--- ratpoison-1.4.9/src/split.c 2022-09-07 14:43:12.0 -0700
+++ new/ratpoison-1.4.9/src/split.c 2022-09-07 14:34:04.685739525 -0700
@@ -23,6 +23,8 @@
 
 #include 
 #include 
+#include 
+#include 
 
 #include "ratpoison.h"
 
@@ -1288,8 +1290,8 @@
   rp_screen *s;
   rp_frame *cur;
 
-  rp_frame *best_frame_yet = NULL;
-  int best_x_yet = frame_right_abs(frame) + 1;
+  rp_frame *nearest_frame_yet = NULL;
+  int smallest_distance_yet = INT_MAX;
 
   list_for_each_entry (s, _screens, node)
 {
@@ -1297,18 +1299,18 @@
 {
   if (frame_top_abs (frame) == frame_bottom_abs (cur))
{
-  if (frame_left_abs (frame) >= frame_left_abs(cur) && 
frame_left_abs(frame) <= frame_right_abs(cur))
-return cur;
-  if (frame_left_abs(cur) >= frame_left_abs(frame) && 
frame_left_abs(cur) < best_x_yet )
-{
-  best_x_yet = frame_left_abs(cur);
-  best_frame_yet = cur;
-}
+ if (frame_left_abs (frame) == frame_left_abs (cur)) return cur;
+ int current_distance = abs(frame_left_abs (frame) - 
frame_left_abs (cur));
+ if (current_distance < smallest_distance_yet)
+   {
+ nearest_frame_yet = cur;
+ smallest_distance_yet = current_distance;
+   }
 }
 }
 }
 
-  return best_frame_yet;
+  return nearest_frame_yet;
 }
 
 rp_frame *
@@ -1317,8 +1319,8 @@
   rp_screen *s;
   rp_frame *cur;
 
-  rp_frame *best_frame_yet = NULL;
-  int best_x_yet = frame_right_abs(frame) + 1;
+  rp_frame *nearest_frame_yet = NULL;
+  int smallest_distance_yet = INT_MAX;
 
   list_for_each_entry (s, _screens, node)
 {
@@ -1326,18 +1328,18 @@
 {
   if (frame_bottom_abs (frame) == frame_top_abs (cur))
 {
-  if (frame_left_abs(frame) >= frame_left_abs(cur) && 
frame_left_abs(frame) < frame_right_abs(cur))
-return cur;
-  if (frame_left_abs(cur) >= frame_left_abs(frame) && 
frame_left_abs(cur) < best_x_yet)
-{
-  best_x_yet = frame_left_abs(cur);
-  best_frame_yet = cur;
-}
+ if (frame_left_abs (frame) == frame_left_abs (cur)) return cur;
+ int current_distance = abs(frame_left_abs (frame) - 
frame_left_abs (cur));
+ if (current_distance < smallest_distance_yet)
+   {
+ nearest_frame_yet = cur;
+ smallest_distance_yet = current_distance;
+   }
 }
 }
 }
 
-  return best_frame_yet;
+  return nearest_frame_yet;
 }
 
 rp_frame *
@@ -1346,8 +1348,8 @@
   rp_screen *s;
   rp_frame *cur;
 
-  rp_frame *best_frame_yet = NULL;
-  int best_y_yet = frame_bottom_abs(frame) + 1;
+  rp_frame *nearest_frame_yet = NULL;
+  int smallest_distance_yet = INT_MAX;
 
   list_for_each_entry (s, _screens, node)
 {
@@ -1355,18 +1357,18 @@
 {
   if (frame_left_abs (frame) == frame_right_abs (cur))
 {
-  if (frame_top_abs (frame) >= frame_top_abs(cur) && 
frame_top_abs(frame) < frame_bottom_abs(cur))
-return cur;
-  if (frame_top_abs(cur) >= frame_top_abs(frame) && 
frame_top_abs(cur) < best_y_yet)
-{
-  best_y_yet = frame_top_abs(cur);
-  best_frame_yet = cur;
-}
+ if (frame_top_abs (frame) == frame_top_abs (cur)) return cur;
+ int 

Bug#1019365: qml-module-lomiri-settings-fingerprint : Depends: qml-module-biometryd but it is not installable

[Steve Langasek]

Package: qml-module-lomiri-settings-fingerprint
Version: 1.0.0-3
Severity: grave
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

The qml-module-lomiri-settings-fingerprint package is uninstallable because
it depends on qml-module-biometryd which does not exist in unstable, nor has
it been uploaded to the NEW queue.

Please upload qml-module-biometryd, or drop the dependency, or drop the
binary package.

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


signature.asc
Description: PGP signature

Bug#1004832: ping qrpnxz

[Russell Hernandez Ruiz]

On Wed, 2022-09-07 at 23:44 +0200, Geert Stappers wrote:
> 
> Is it Salsa account qrpnxz for Russell Hernandez Ruiz 
> that is missing for continueing this ITP?

Gee, sorry I've let this sit so long. With the waiting I lost momentum
and got distracted with other things, but I would like to finish this
up.

I've got Salsa access now. I will push what I have in the next few
days. I'll check for newer versions, and add the bits necessary to
allow the automatic checking of updates.

Thanks a lot for persisting, Geert.

-- Russell

Bug#1018930: [Debian-ha-maintainers] Bug#1018930: marked as done (pcs: CVE-2022-2735: Obtaining an authentication token for hacluster user leads to privilege escalation)

[Valentin Vidic]

I checked pcs 0.10.1-2 in buster and it turns out it is not vulnerable
to CVE-2022-2735. Separate ruby daemon with a world writable UNIX socket
was introduced later in 0.10.5:

https://salsa.debian.org/ha-team/pcs/-/commits/master/pcsd/pcsd-ruby.service.in

Before that version python code runs ruby commands and they communicate
by sending json responses on stdin/stdout.

https://salsa.debian.org/ha-team/pcs/-/blob/38330deb0d849d6a1945856b24323043f6a7839b/pcs/daemon/ruby_pcsd.py

-- 
Valentin

Bug#1019364: gnome-software: Unable to install XXX as not supported

[Tyler Magee Shields]

Package: gnome-software
Version: 43~beta-1
Severity: important
Tags: upstream
X-Debbugs-Cc: tylermageeshie...@gmail.com

Dear Maintainer,

I cannot install anything with Software:
Unable to install XXX as not supported

where XXX is the name of the application.

This seems to be a bug. Tried using solutions from the web, didn't work.
Please fix this bug! Else I may have to keep using the command line or
GNOME Packages (older software) to install stuff.

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

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

Versions of packages gnome-software depends on:
ii  appstream0.15.5-1
ii  apt-config-icons 0.15.5-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gnome-software-common43~beta-1
ii  gsettings-desktop-schemas43~alpha-1
ii  libadwaita-1-0   1.2~beta-1
ii  libappstream40.15.5-1
ii  libc62.34-7
ii  libcairo21.16.0-6
ii  libfwupd21.8.4-2
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.72.3-1+b1
ii  libgtk-4-1   4.7.2+ds-3
ii  libgtk3-perl 0.038-1
ii  libgudev-1.0-0   237-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmalcontent-0-00.10.5-1
ii  libpackagekit-glib2-18   1.2.5-3
ii  libpango-1.0-0   1.50.9+ds-1
ii  libpolkit-gobject-1-00.105-33
ii  libsoup2.4-1 2.74.2-3
ii  libxmlb2 0.3.8-1
ii  packagekit   1.2.5-3
ii  software-properties-gtk  0.96.20.2-2.1

Versions of packages gnome-software recommends:
ii  fwupd  1.8.4-2

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#1019363: libheif: Broken homepage

[Jeremy Bicha]

I guess the homepage isn't completely wrong but it's not very useful
since it doesn't mention libheif at all currently.

Thank you,
Jeremy Bicha

Bug#1004832: ping qrpnxz

[Geert Stappers]

Is it Salsa account qrpnxz for Russell Hernandez Ruiz 
that is missing for continueing this ITP?

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1019362: RFP: Tryton stock location move module

[revans]

Package: tryton-modules-stock-location-move
Severity:wishlist
Package name:Tryton
Version:6.0
UpStream Author:?
URL:http://downloads.tryton.org/6.0/trytond_stock_location_move-6.0.0.tar.gz
License:GPL
Programming Lang:?
Description:Tryton inventory management module



It seems Debian has all the other Tryton modules available for install.
It would be nice to have this one as well.

Bug#1019363: libheif: Broken homepage

[Jeremy Bicha]

Source: libheif
Version: 1.13.0-1

The Homepage in debian/control isn't correct currently.

Maybe it's appropriate to point to the github repo instead.

Thank you,
Jeremy Bicha

Bug#768073: Status of package in the NEW queue

[Pierre-Elliott Bécue]

Per Lundberg  wrote on 06/09/2022 at 10:36:00+0200:

> Hi,
>
> I think we are probably a number of people excited to see this (soon!)
> finally making it into Debian proper. :) I am currently running LXD as
> a snap, but it would just be so much nicer and cleaner to be able to
> use the "real" packages for this.
>
> The package is currently in the Debian "new" queue, where it has been since 
> August 4: https://ftp-master.debian.org/new/lxd_5.0.0-1.html
>
> Are there any impediments from seeing this making its way into 
> unstable/experimental anytime soon, or is it just a matter of the FTP masters 
> not having had time to look into it yet?
>
> Best regards,

Something stays in NEW until a ftpmaster has time to review it. From
there, either it's accepted or rejected, but in both cases it gets out
from NEW.

Nothing can be done on our side, except asking ftpmasters to review
faster, but it's something to do only in urgent cases, and a new
package, even as exciting as LXD, is anything but urgent.

Cheers!
-- 
PEB


signature.asc
Description: PGP signature

Bug#1019331: systemd-resolved: Update breaks DNS resolution, should be `Recommends:`.

[Luca Boccassi]

On Wed, 7 Sep 2022 16:18:57 +0200 Michael Biebl 
wrote:
> 
> Hi Dirk
> 
> Am 07.09.22 um 15:28 schrieb Dirk Lehmann:
> > Package: systemd
> > Version: 251.4-3
> > Severity: grave
> > Tags: upstream
> > Justification: renders package unusable
> > 
> > Dear Maintainer,
> > 
> > On my system I am using `systemd-resolved` for DNS name resolution.
> > After updating to the current version of the package `systemd` my
DNS
> > name resolution goes down.
> > 
> > After that update an `apt-get install systemd-resolved` is not
> > possible anymore, due to missing DNS resolution.
> > 
> > I workaround it, by temporarily adding the DNS resolution of the
> > Debian Package Mirror manually to `/etc/hosts`, which is depending
on
> > the configuration in `/etc/apt/sources.list`.  After that it is
> > possible to `apt-get install systemd-resolved` and the changes in
> > `/etc/hosts` can be reverted.
> > 
> > For Systemd Maintainers I would recommend to add the package
> > `systemd-resolved` to `Recommends:` instead of `Suggests:`.  Then
it
> > should be installed automatically on a Debian system with a default
> > configured `apt` - as it was in the past.
> 
> We actually discussed this this very issue.
> Problem is: the new systemd-resolved package does enable resolved by 
> default (and this is a trait we wanted from the new, split-off 
> systemd-resolved package).
> So, by making systemd-resolved a Recommends we would basically enable
> systemd-resolved for everyone.
> This would be a much more intrusive change that would require further
> discussion and is not something we wanted to pursue at this point.
> 
> So instead, we opted to show a NEWS entry, which tells the (few)
users 
> that had systemd-resolved enabled manually, to explicitly install the
> systemd-resolved package [1]. We are also aware, that apt-listchanges
is 
> currently buggy [2] and doesn't always shows NEWS entries, so we
worked 
> around that [3].
> 
> We will also add a corresponding entry to the release notes of
bookworm [4].
> 
> We are aware that for users of systemd-resolved the upgrade
experience 
> is not perfect but given the current constraints, it's imho the best
we 
> can do. So I'm closing the bug report.
> If you have suggestions how the upgrade experience can be improved
with 
> the given constraints, please let us know.
> 
> Regards,
> Michael
> 
> 
> [1] 
>
https://salsa.debian.org/systemd-team/systemd/-/commit/5db8ba3017a000d4c338d88504fa48adcc6eaa63
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422

This reply somehow didn't make it to the mailing list, so I missed it
before sending mine:

https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2022-September/thread.html

-- 
Kind regards,
Luca Boccassi


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

Bug#1019331: systemd-resolved: Update breaks DNS resolution, should be `Recommends:`.

[Luca Boccassi]

Control: severity -1 wishlist
Control: tags -1 wontfix
Control: close -1

> For Systemd Maintainers I would recommend to add the package
> `systemd-resolved` to `Recommends:` instead of `Suggests:`.  Then it
> should be installed automatically on a Debian system with a default
> configured `apt` - as it was in the past.

No, we do not want to make resolved the default. The NEWS (and release
notes for Bookworm) mention this change, and that will be enough. If
you are using an unsupported setup it's up to you to keep up with
release notes.

-- 
Kind regards,
Luca Boccassi


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

Bug#1018994: qpdfview: fileopen.pdf.No pages were found in document, but couldnot open file, evince ok

[Louis-Philippe Véronneau]

Hi,

I can reproduce this issue.

Note that pdfinfo also fails with the same error message:

foo@bar: pdfinfo empty.pdf
Syntax Error (1385): Illegal character ')'
Syntax Error (1387): Dictionary key must be a name object
Syntax Error (1385): Illegal character ')'
Syntax Error (1387): Dictionary key must be a name object
Syntax Error (1385): Illegal character ')'
Syntax Error (1387): Dictionary key must be a name object
Syntax Error (1385): Illegal character ')'
Syntax Error (1387): Dictionary key must be a name object
Syntax Error (1385): Illegal character ')'
Syntax Error (1387): Dictionary key must be a name object
Syntax Error: Invalid XRef entry 3
Internal Error: xref num 3 not found but needed, try to reconstruct<0a>
Syntax Error: Invalid XRef entry 3
Syntax Error: Top-level pages object is wrong type (null)
Command Line Error: Wrong page range given: the first page (1) can not be after 
the last page (0).

I'm tempted to say that this is simply an invalid PDF. That would thus not be a 
bug in qpdfview.

Where did you find this PDF. Why should qpdfview be able to open it?

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#1018992: #1018992: qpdfview: "error: incorrect password" on console, password is correct

[Louis-Philippe Véronneau]

retitle 1018992 qpdfview: "error: incorrect password" on console, password is 
correct
severity 1018992 minor
thanks

I can indeed reproduce this issue. What happens on my side is the error message 
shows up
in the console, and then the "Unlock" window shows up in the GUI asking for the 
password.

When you enter the right password, the PDF can be decrypted.

Since this is pretty minor, I'm downgrading it.

Thanks for reporting this bug.

--
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
   ⠈⠳⣄

Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.

[Thorsten Glaser]

Thorsten Glaser dixit:

>I’ve recently been getting filesystem corruption on this system, which,
>incidentally, is a fresh-ish installation since I’ve been hit by the

I have somewhat reason to at least suspect the µSD card this was
installed on. But there was never anything in syslog/dmesg about
it, so the Linux kernel clearly didn’t find fault with it at all.

Suggestions how I can prove/disprove this welcome; I now swapped
the filesystem contents to a new fs on a new µSD card, so tests
that are destructive can be done, but they need to be doable from
a Grml live ISO and should be doable overnight (i.e. not block
the system for too long).

Thanks in advance,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (416 (445) bugs: 0 RC, 282 (302) I, 134 (143) M, 0 F) + 207
‣ src:dash (94 (109) bugs: 0 RC, 52 (55) I, 42 (54) M, 0 F) + 63 ubu
‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F)
dash has two RC bugs they just closed because they don’t care about quality…

Bug#1019361: clamav-daemon: cron job fails

[Tim McConnell]

Package: clamav-daemon
Version: 0.103.7+dfsg-1
Severity: normal

Dear Maintainer,
I get the following report:
× cron-tmick-tmick-0.service - [Cron] "59 23 * * * /usr/bin/clamscan --exclude-
dir=/home/tmick/.clamtk/viruses --exclude-dir=smb4k --exclude-
dir=/run/user/tmick/gvfs --exclude-dir=/home/tmick/.gvfs --exclude-
dir=.thunderbird --exclude-dir=.mozilla-thunderbird --exclude-dir=.evolution
--exclude-dir=Mail --exclude-dir=kmail -i --detect-pua -r /home/tmick
--log="$HOME/.clamtk/history/$(date +\%b-\%d-\%Y).log" 2>/dev/null # clamtk-
scan"
 Loaded: loaded (/var/spool/cron/crontabs/tmick; generated)
 Active: failed (Result: exit-code) since Wed 2022-09-07 04:39:26 CDT; 1s
ago
TriggeredBy: ● cron-tmick-tmick-0.timer
   Docs: man:systemd-crontab-generator(8)
Process: 25146 ExecStart=/bin/sh /run/systemd/generator/cron-tmick-
tmick-0.sh (code=exited, status=1/FAILURE)
   Main PID: 25146 (code=exited, status=1/FAILURE)
CPU: 3h 52min 16.894s

Sep 07 04:39:25 DebianTim sh[25149]: Data scanned: 56848.61 MB
Sep 07 04:39:25 DebianTim sh[25149]: Data read: 375263.33 MB (ratio 0.15:1)
Sep 07 04:39:25 DebianTim sh[25149]: Time: 16825.735 sec (280 m 25 s)
Sep 07 04:39:25 DebianTim sh[25149]: Start Date: 2022:09:06 23:59:00
Sep 07 04:39:25 DebianTim sh[25149]: End Date:   2022:09:07 04:39:25
Sep 07 04:39:26 DebianTim systemd[1]: cron-tmick-tmick-0.service: Main process
exited, code=exited, status=1/FAILURE
Sep 07 04:39:26 DebianTim systemd[1]: cron-tmick-tmick-0.service: Failed with
result 'exit-code'.
Sep 07 04:39:26 DebianTim systemd[1]: Failed to start [Cron] "59 23 * * *
/usr/bin/clamscan --exclude-dir=/home/tmick/.clamtk/viruses --exclude-dir=smb4k
--exclude-dir=/run/user/tmick/gvfs --exclude-dir=/home/tmick/.gvfs --exclude-
dir=.thunderbird --exclude-dir=.mozilla-thunderbird --exclude-dir=.evolution
--exclude-dir=Mail --exclude-dir=kmail -i --detect-pua -r /home/tmick
--log="$HOME/.clamtk/history/$(date +\%b-\%d-\%Y).log" 2>/dev/null # clamtk-
scan".
Sep 07 04:39:26 DebianTim systemd[1]: cron-tmick-tmick-0.service: Triggering
OnFailure= dependencies.
Sep 07 04:39:26 DebianTim systemd[1]: cron-tmick-tmick-0.service: Consumed 3h
52min 16.894s CPU time.

How do I fix the report/ cron job??


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
ConcurrentDatabaseReload = "yes"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertBrokenMedia disabled
AlertEncrypted disabled
StructuredCCOnly disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath 

Bug#1018753: abiword: FTBFS on several platforms (test timeout)

[Jeremy Bicha]

Control: tags -1 pending

I am uploading a NMU now with high urgency to allow the ongoing
evolution-data-server transition to proceed smoothly.

Thank you,
Jeremy Bicha

Bug#1019360: diffmon: unrouteable address

[Tim McConnell]

Package: diffmon
Version: 20020222-9
Severity: normal

Dear Maintainer,
I'm getting address unrouteable from the reports sent.
The undeliverable  report is showing an email address of:  password-diffmon-
repo...@debiantim.midcoip.net for a "To" address, I'm pretty sure it's wrong.
It probably should be root instead?


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

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

Versions of packages diffmon depends on:
ii  exim4-daemon-light [mail-transport-agent]  4.96-3

diffmon recommends no packages.

diffmon suggests no packages.

-- no debconf information

Bug#1016938: konclude: autopkgtest regression on armhf, flaky test on s390x (with timeout)

[Paul Gevers]

Hi Adrian, all,

On 06-09-2022 23:24, Adrian Bunk wrote:

Looking at the armhf regression, has there been any change in the
autopkgtest infrastructure when it regressed?


Yes, we upgraded the hosts to bullseye and we changed to our current host.


The autopkgtest passes for me on amdahl.

The tests are also run as part of the package build, and in reproducible
they have been reliably passing on armhf:
https://tests.reproducible-builds.org/debian/history/armhf/konclude.html


Considering that the regression happened around the migration to the 
current host it may be worth while to explicitly mention that the host 
that runs our armhf tests is very powerful, see

https://metal.equinix.com/product/servers/c3-large-arm64/
i.e. 80 cores, 256 GB RAM. I've seen other tests fail due to not 
handling that much cores or memory correctly.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019359: p.qa.d.o: bugs info not updated (+first analysis)

[Thorsten Glaser]

Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Look at https://packages.qa.debian.org/b/bash.html

bugs

   all [93]bug history graph
  [94]406 ([95]433)

   RC
  [96]0

   I
  [97]275 ([98]295)

   M
  [99]131 ([100]138)

   F
  [101]0

   [102]Ubu
  [103]208

The “bug history graph” 
is up-to-date, but the other numbers aren’t.

https://udd.debian.org/cgi-bin/ddpo-bugs.cgi shows:

bash:0(0) 282(302) 134(143) 0(0) 24(25)

That makes 416(445), 0, 282(302), 134(143), 0

I didn’t look at the ubu part.

Perhaps www/bin/other_to_xml.py throws errors?

Bug#1016937: Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Hi,

On 07-09-2022 21:57, Michael Biebl wrote:

I fail to see the connection between exempi and atop.
Have you copied the wrong bug report number?


Seems like this should have gone to 1016937 indeed (doing so now).

Paul



Michael

Am 07.09.22 um 19:00 schrieb Dipak Zope1:

Hi Paul,

Setting the environment variable ATOPACCT to empty value disables this 
issue.


Please use this workaround in the caller script of atop till we get a 
final fix.


export ATOPACCT=""

The behaviour is described in the source as below:

 /*

 ** when a particular environment variable is present, 
atop should


 ** use a specific accounting-file (as defined by the 
environment


 ** variable) or should use no process accounting at 
all (when


 ** contents of environment variable is empty)

 */

-Dipak

*From: *Dipak Zope1 
*Date: *Tuesday, 30 August 2022 at 3:28 PM
*To: *Paul Gevers , 1018...@bugs.debian.org 
<1018...@bugs.debian.org>, debian-s390 
*Subject: *[EXTERNAL] RE: src:exempi: fails to migrate to testing for 
too long: FTBFS on s390x


Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it 
further and will keep this thread updated. I am looking forward to 
have a fix for this for s390x. ‍ ‍ ‍ ‍ ‍


ZjQcmQRYFpfptBannerStart

*This Message Is From an External Sender *

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it 
further and will keep this thread updated.


I am looking forward to have a fix for this for s390x.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

[Michael Biebl]

Dipak,

I fail to see the connection between exempi and atop.
Have you copied the wrong bug report number?

Michael

Am 07.09.22 um 19:00 schrieb Dipak Zope1:

Hi Paul,

Setting the environment variable ATOPACCT to empty value disables this 
issue.


Please use this workaround in the caller script of atop till we get a 
final fix.


export ATOPACCT=""

The behaviour is described in the source as below:

     /*

     ** when a particular environment variable is present, 
atop should


     ** use a specific accounting-file (as defined by the 
environment


     ** variable) or should use no process accounting at all 
(when


     ** contents of environment variable is empty)

     */

-Dipak

*From: *Dipak Zope1 
*Date: *Tuesday, 30 August 2022 at 3:28 PM
*To: *Paul Gevers , 1018...@bugs.debian.org 
<1018...@bugs.debian.org>, debian-s390 
*Subject: *[EXTERNAL] RE: src:exempi: fails to migrate to testing for 
too long: FTBFS on s390x


Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it further 
and will keep this thread updated. I am looking forward to have a fix 
for this for s390x. ‍ ‍ ‍ ‍ ‍


ZjQcmQRYFpfptBannerStart

*This Message Is From an External Sender *

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it further 
and will keep this thread updated.


I am looking forward to have a fix for this for s390x.

-Dipak

On 30/08/22, 12:44 AM, "Paul Gevers"  wrote:

Hi Michael

On 29-08-2022 14:23, Michael Biebl wrote:

 > As you are probably aware, this issue is known and tracked in [1].

Which I added as a blocker and mentioned in my message, so yes.

 > The

 > package FTBFS after enabling the test suite. I raised this issue

 > upstream but there is no real interest/motivation [2] on their part to

 > address these (most likely endianess related) issues.

 > So I informed the s390x porters as well but got not feedback so far.

Ack, I saw the latter part.

 > To me it seems it's better to not continue ship a known broken package

 > on s390x and think a partial architecture removal is probably the better

 > alternative.

If you think the package indeed is severely broken, then removal sounds

best. If its broken in some less common use cases, it may be OK to leave

it for now (skipping those tests on 390x) and let the porters have a

look when they have time.

 > Let me know what you think

It all depends on how broken it is. If you would consider the bugs found

by the tests RC, then removal is the better choice unless a porter steps

up to fix it. If the bugs would be important at most, than skipping

broken tests on s390x sounds like the better option. Removal bugs are

hard to time predict.

Paul

PS: I would not disable building on s390x if you have the test suite

finding out severe problems (as the d/control file doesn't have negated

architecture fields yet). Just getting the binary removed and FTBFS will

prevent the architecture from building again.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019358: davs2: CVE-2022-36647

[Salvatore Bonaccorso]

Source: davs2
Version: 1.6-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/pkuvcl/davs2/issues/29
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for davs2.

CVE-2022-36647[0]:
| PKUVCL davs2 v1.6.205 was discovered to contain a global buffer
| overflow via the function parse_sequence_header() at
| source/common/header.cc:269.


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-36647
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36647
[1] https://github.com/pkuvcl/davs2/issues/29
[2] 
https://github.com/pkuvcl/davs2/commit/b41cf117452e2d73d827f02d3e30aa20f1c721ac

Regards,
Salvatore

Bug#1019357: tinygltf: CVE-2022-3008

[Salvatore Bonaccorso]

Source: tinygltf
Version: 2.5.0+dfsg-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/syoyo/tinygltf/issues/368
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 2.5.0+dfsg-3

Hi,

The following vulnerability was published for tinygltf.

CVE-2022-3008[0]:
| The tinygltf library uses the C library function wordexp() to perform
| file path expansion on untrusted paths that are provided from the
| input file. This function allows for command injection by using
| backticks. An attacker could craft an untrusted path input that would
| result in a path expansion. We recommend upgrading to 2.6.0 or past
| commit 52ff00a38447f06a17eab1caa2cf0730a119c751


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-3008
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3008
[1] https://github.com/syoyo/tinygltf/issues/368
[2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=49053
[3] 
https://github.com/syoyo/tinygltf/commit/52ff00a38447f06a17eab1caa2cf0730a119c751

Regards,
Salvatore

Bug#1018289: perl: FTBFS on hurd-i386: NDBM not getting linked against libgdbm-compat

[Niko Tyni]

Control: tag -1 patch
Control: forwarded -1 https://github.com/Perl/perl5/pull/20267

On Tue, Aug 30, 2022 at 11:54:25PM +0300, Niko Tyni wrote:
> On Sun, Aug 28, 2022 at 01:41:48PM +0200, Samuel Thibault wrote:
> > Package: perl
> > Version: 5.34.0-5
> > Severity: important
> 
> > perl currently FTBFS on hurd-i386: 
> 
> > # Error:  Can't load '../../lib/auto/NDBM_File/NDBM_File.so' for module 
> > NDBM_File: ../../lib/auto/NDBM_File/NDBM_File.so: undefined symbol: 
> > dbm_nextkey at ../../lib/XSLoader.pm line 93.
> > #   at ../../lib/NDBM_File.pm line 12.
> 
> I think this broke with
> 
>   https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/367
> 
> but nobody noticed until now.

> Something like this works but seems rather wordy and
> silly to repeat in all of those:
> 
> --
>   my $hint_file = 'hints/linux.pl';
>   open(my $fh, '<', $hint_file)
>   or die "Could not open $hint_file for read: $!";
>   eval join('', <$fh>);
>   die "Failed to load hint file $hint_file: $@" if $@;
> --
> 
> Guess I'll sleep on this and try to come up with something better.

Ended up proposing upstream just

-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;

Patch attached. We'll see how it goes.
-- 
Niko
>From 59cd40b841cc91dd8306ca9abcb3e7f5fafa50bd Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Wed, 31 Aug 2022 21:41:14 +0300
Subject: [PATCH] Fix GNU/{Hurd,kFreeBSD,kNetBSD} hint files in several modules

The idiom of

  do './hints/linux.pl' or die $@;

broke with https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/pull/367
which made $self a lexical variable so it is no longer visible in a file
loaded with 'do'.

This silently makes the loaded Linux hints a no-op, leading to missing
symbols, broken modules and test failures in at least NDBM_File
and ODBM_File on GNU/Hurd, as reported by Samuel Thibault in
https://bugs.debian.org/1018289 .

The replacement of eval `cat hints/linux.pl` is not very sophisticated
but should be enough for this, and alternatives seem overly verbose.

Bug-Debian: https://bugs.debian.org/1018289
---
 dist/Storable/hints/gnukfreebsd.pl  | 2 +-
 dist/Storable/hints/gnuknetbsd.pl   | 2 +-
 ext/DynaLoader/hints/gnukfreebsd.pl | 2 +-
 ext/DynaLoader/hints/gnuknetbsd.pl  | 2 +-
 ext/NDBM_File/hints/gnu.pl  | 2 +-
 ext/NDBM_File/hints/gnukfreebsd.pl  | 2 +-
 ext/NDBM_File/hints/gnuknetbsd.pl   | 2 +-
 ext/ODBM_File/hints/gnu.pl  | 2 +-
 ext/ODBM_File/hints/gnukfreebsd.pl  | 2 +-
 ext/ODBM_File/hints/gnuknetbsd.pl   | 2 +-
 ext/POSIX/hints/gnukfreebsd.pl  | 2 +-
 ext/POSIX/hints/gnuknetbsd.pl   | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/dist/Storable/hints/gnukfreebsd.pl b/dist/Storable/hints/gnukfreebsd.pl
index db6356796..013a2edc4 100644
--- a/dist/Storable/hints/gnukfreebsd.pl
+++ b/dist/Storable/hints/gnukfreebsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/dist/Storable/hints/gnuknetbsd.pl b/dist/Storable/hints/gnuknetbsd.pl
index db6356796..013a2edc4 100644
--- a/dist/Storable/hints/gnuknetbsd.pl
+++ b/dist/Storable/hints/gnuknetbsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/DynaLoader/hints/gnukfreebsd.pl b/ext/DynaLoader/hints/gnukfreebsd.pl
index db6356796..013a2edc4 100644
--- a/ext/DynaLoader/hints/gnukfreebsd.pl
+++ b/ext/DynaLoader/hints/gnukfreebsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/DynaLoader/hints/gnuknetbsd.pl b/ext/DynaLoader/hints/gnuknetbsd.pl
index db6356796..013a2edc4 100644
--- a/ext/DynaLoader/hints/gnuknetbsd.pl
+++ b/ext/DynaLoader/hints/gnuknetbsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/NDBM_File/hints/gnu.pl b/ext/NDBM_File/hints/gnu.pl
index db6356796..013a2edc4 100644
--- a/ext/NDBM_File/hints/gnu.pl
+++ b/ext/NDBM_File/hints/gnu.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/NDBM_File/hints/gnukfreebsd.pl b/ext/NDBM_File/hints/gnukfreebsd.pl
index db6356796..013a2edc4 100644
--- a/ext/NDBM_File/hints/gnukfreebsd.pl
+++ b/ext/NDBM_File/hints/gnukfreebsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/NDBM_File/hints/gnuknetbsd.pl b/ext/NDBM_File/hints/gnuknetbsd.pl
index db6356796..013a2edc4 100644
--- a/ext/NDBM_File/hints/gnuknetbsd.pl
+++ b/ext/NDBM_File/hints/gnuknetbsd.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;
diff --git a/ext/ODBM_File/hints/gnu.pl b/ext/ODBM_File/hints/gnu.pl
index db6356796..013a2edc4 100644
--- a/ext/ODBM_File/hints/gnu.pl
+++ b/ext/ODBM_File/hints/gnu.pl
@@ -1 +1 @@
-do './hints/linux.pl' or die $@;
+eval `cat hints/linux.pl` or die $@;

Bug#1019356: gnome-feeds: Update to 1.0.3

[Jeremy Bicha]

Source: gnome-feeds
Version: 0.16.2+dfsg1-1
Severity: wishlist
Control: block -1 by 1016765

There is a new version of gnome-feeds available. It switches to gtk4,
libadwaita, and webkitgtk 5.0. It also uses blueprint-compiler.

It switches to the Python3 bindings for
https://gitlab.com/gabmus/syndication-domination
which isn't packaged in Debian yet.

Thank you,
Jeremy Bicha

Bug#848578: Also running into this problem

[Nicolas Schier]

Thanks for the details, finally I can reproduce this now.  When adding 
three unicode related lines into 'ts' it _seems_ to me to be fixed, but 
my perl experience is quite degraded and I'd like to get some feedback 
from volunteer testers before forwarding the patch to upstream.

Francois, might you be able to patch your ts with the attached patch 
and re-check?  As August has gone, I used

echo test | faketime "2022-08-01" ./ts

for testing with your specified locale settings.

Kind regards,
Nicolas


On Sat, 6 Aug 2022 10:37:22 -0700 Francois Marier wrote:
> I can also reproduce this problem with `ts` while `date` works fine:
> 
>   $ date | ts
>   ao� 06 10:33:36 sam 06 aoû 2022 10:33:36 PDT
> 
>   $ date
>   sam 06 aoû 2022 10:35:39 PDT
> 
>   $ echo test | ts
>   ao� 06 10:36:04 test
> 
> This is what my locale is set to:
> 
>   $ locale
>   LANG=fr_CA.utf8
>   LANGUAGE=
>   LC_CTYPE="fr_CA.utf8"
>   LC_NUMERIC="fr_CA.utf8"
>   LC_TIME="fr_CA.utf8"
>   LC_COLLATE="fr_CA.utf8"
>   LC_MONETARY="fr_CA.utf8"
>   LC_MESSAGES="fr_CA.utf8"
>   LC_PAPER="fr_CA.utf8"
>   LC_NAME="fr_CA.utf8"
>   LC_ADDRESS="fr_CA.utf8"
>   LC_TELEPHONE="fr_CA.utf8"
>   LC_MEASUREMENT="fr_CA.utf8"
>   LC_IDENTIFICATION="fr_CA.utf8"
>   LC_ALL=
> 
>   $ cat /etc/locale.gen | grep -v '^#'
>   en_CA.UTF-8 UTF-8
>   en_NZ.UTF-8 UTF-8
>   fr_CA.UTF-8 UTF-8
> 
> Let me know if there's anything else I can provide to help reproduce the
> problem.
> 
> Francois
> 
> -- 
> https://fmarier.org/

-- 
epost|xmpp: nico...@fjasle.eu  irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb  c82b 7d97 0932 55a0 ce7f
 -- frykten for herren er opphav til kunnskap --
diff --git a/ts b/ts
index af23cf7..fbd5b1a 100755
--- a/ts
+++ b/ts
@@ -54,6 +54,11 @@ use strict;
 use POSIX q{strftime};
 no warnings 'utf8';
 
+# Ensure that text read or printed are converted from/to UTF-8.
+binmode STDIN, ':utf8';
+binmode STDOUT, ':utf8';
+binmode STDERR, ':utf8';
+
 $|=1;
 
 my $rel=0;

Bug#1019355: jest: please provide real (not virtual) package node-cjs-module-lexer

[Jérémy Lal]

Package: jest
Version: 28.1.3~ds+~cs70.48.29-1
Severity: important

nodejs also depends on cjs-module-lexer@1.2.2.

Both packages could benefit from a separate module, especially since
it would be easier to focus on the wasm version of it.



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

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

Versions of packages jest depends on:
ii  node-ansi-escapes5.0.0+really.4.3.1-1
ii  node-ansi-regex  5.0.1-1
ii  node-ansi-styles 6.1.0-2
ii  node-anymatch3.1.2+~cs4.6.1-1
pn  node-babel-code-frame
pn  node-babel-core  
pn  node-babel-generator 
pn  node-babel-plugin-syntax-typescript  
pn  node-babel-preset-current-node-syntax
pn  node-babel-traverse  
pn  node-babel-types 
ii  node-babel7 [node-types-babel-traverse]  7.18.13+~cs214.250.184-2
ii  node-camelcase   7.0.0-2
ii  node-chalk   5.0.1-2
ii  node-ci-info 3.3.2+~cs4.2.0-1
ii  node-co  4.6.0+~4.6.2-2
ii  node-convert-source-map  1.8.0+~1.5.2-2
ii  node-cosmiconfig 7.0.1+ds1-2
ii  node-deepmerge   4.2.2+~1.1.1-1
ii  node-detect-newline  3.1.0-2
ii  node-emittery0.12.1-1
ii  node-execa   6.1.0+dfsg1+~cs16.0.4-7
ii  node-exit0.1.2+~0.1.31-2
ii  node-glob8.0.3+~cs7.6.15-1
ii  node-graceful-fs 4.2.10-1
ii  node-is-generator-fn 2.1.0-2
ii  node-istanbul [node-v8-to-istanbul]  0.4.5+repack10+~cs97.25.57-3
ii  node-jest-debbundle  28.1.3~ds+~cs70.48.29-1
ii  node-jest-worker 28.1.3~ds+~cs70.48.29-1
ii  node-jsdom   20.0.0+repack1+~cs121.19.20-2
ii  node-json-stable-stringify   1.0.1+~cs5.2.33-1
ii  node-leven   4.0.0+~cs1.1.1-2
ii  node-micromatch  4.0.5+~4.0.2-1
ii  node-minimist1.2.6+~cs5.3.2-1
ii  node-p-limit 4.0.0+~cs4.0.0-5
ii  node-parse-json  5.2.0+~cs5.1.7-1
pn  node-pirates 
ii  node-prompts 2.4.2+~cs7.5.9-1
ii  node-react   18.2.0+dfsg+~cs87.31.26-2
ii  node-react-dom   18.1.0~18.2.0+dfsg+~cs87.31.26-2
ii  node-react-is18.1.0~18.2.0+dfsg+~cs87.31.26-2
ii  node-react-test-renderer 18.1.0~18.2.0+dfsg+~cs87.31.26-2
ii  node-read-pkg5.2.0-2
ii  node-read-pkg-up 7.0.1-2
ii  node-resolve 1.22.1+~cs5.31.10-1
ii  node-resolve-from5.0.0+~3.1.0+~3.3.0+~2.0.0-1
ii  node-rimraf  3.0.2-2
ii  node-sane [node-fb-watchman] 4.1.0+~cs18.17.38-1
ii  node-semver  7.3.5+~7.3.9-1
ii  node-sinclair-typebox0.23.4-2
ii  node-sinon   14.0.0+ds+~cs71.22.25-2
ii  node-slash   4.0.0-3
ii  node-source-map  0.7.0++dfsg2+really.0.6.1-12
ii  node-source-map-support  0.5.21+ds+~0.5.4-1
ii  node-stack-utils 2.0.5+~2.0.1-2
ii  node-strip-ansi  6.0.1-1
ii  node-strip-bom   4.0.0-2
ii  node-strip-json-comments 4.0.0-4
pn  node-types-babel-core
ii  node-which   2.0.2+~cs1.3.2-2
ii  node-write-file-atomic   4.0.2+~4.0.0-1
ii  node-yargs   16.2.0+~16.0.4-3
ii  nodejs   18.7.0+dfsg-5

jest recommends no packages.

jest suggests no packages.

-- no debconf information

Bug#1019335: Reconsider the egrep and fgrep deprecation

[Paul Gevers]

Hi all,

For transparency I'm letting you know that, with my Release Team manager 
hat on, I have just added a migration block on grep.


On Wed, 7 Sep 2022 17:39:45 +0200 Santiago Ruano 
=?iso-8859-1?Q?Rinc=F3n?=  wrote:

For the moment, I am waiting for (a final) upstream input about those
warning, in this bug:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604

But giving:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996
I doubt they are willing to reconsider deprecating egrep and fgrep.


But we should be considering our own users. I'd appreciate it if either 
Debian continues to ship egrep and fgrep. Or if you don't want to do 
that or if you don't want to decide on your own I'd appreciate it if we 
had a bit of discussion in a broader audience (I suggest 
debian-de...@l.do) to see what we as a project believe is the right 
course of action.


To be clear, I'm not saying we can't have this change at all, but I'm 
saying we can't have this change with at least some agreement that it's 
acceptable by the project. The block is to buy us time to reach that 
agreement.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019051: ffmpeg: Repackaging with pipewire: dpkg-shlibdeps: error: no dependency information found for libjack.so.0 used by libavdevice.so.59.7.100

[Sebastian Ramacher]

Control: tags -1 moreinfo
Control: severity -1 normal

On 2022-09-03 07:29:20 -0400, Braiam Peguero wrote:
> Package: ffmpeg
> Version: 7:5.1-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear Maintainer,
> 
> Repackaging FFMPEG on a Pipewire enabled host, while fulfilling
> all dependencies fails on the shlibdeps step with the following message:
> 
> set -e && for pkg in libavcodec-extra59 libavfilter-extra8 
> libavformat-extra59; do \
>   mainpkg=`echo $pkg | sed 's/-extra//'`; \
>   cp -f debian/$mainpkg.symbols debian/$pkg.symbols; \
>   dh_shlibdeps -p$pkg; \
>   rm -f debian/$pkg.symbols; \
> done
> dh_shlibdeps --remaining-packages
> dpkg-shlibdeps: error: no dependency information found for 
> /usr/lib/x86_64-linux-gnu/pipewire-0.3/jack/libjack.so.0 (used by 
> debian/libavdevice59/usr/lib/x86_64-linux-gnu/libavdevice.so.59.7.100)
> Hint: check if the library actually comes from a package.
> dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/libavdevice59.substvars 
> debian/libavdevice59/usr/lib/x86_64-linux-gnu/libavdevice.so.59.7.100 
> returned exit code 25
> dh_shlibdeps: error: Aborting due to earlier error

I cannot reproduce this issue when building ffmpeg in sbuild with
pipewire-jack installed. Are you sure that's the root cause of your
issue? Could you please provide a full log?

Cheers

> 
> I'm unsure if ffmpeg dependencies needs to be more tighter wtr jack
> or if a change should be done to pipewire so that it correctly
> declares the shared library.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
> 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=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages ffmpeg depends on:
> ii  libavcodec597:5.1-3
> ii  libavdevice59   7:5.1-3
> ii  libavfilter87:5.1-3
> ii  libavformat59   7:5.1-3
> ii  libavutil57 7:5.1-3
> ii  libc6   2.34-4
> ii  libpostproc56   7:5.1-3
> ii  libsdl2-2.0-0   2.24.0+dfsg-1
> ii  libswresample4  7:5.1-3
> ii  libswscale6 7:5.1-3
> 
> ffmpeg recommends no packages.
> 
> Versions of packages ffmpeg suggests:
> pn  ffmpeg-doc  
> 
> -- no debconf information
> 

-- 
Sebastian Ramacher

Bug#1019354: libc6-dev-riscv64-cross: static libc is unusable

[Rémi Denis-Courmont]

Package: libc6-dev-riscv64-cross
Version: 2.34-7cross2
Severity: important

Dear Maintainer,

Even the most trivial C program:
encounters a segmentation crash when linked statically:

# cat << EOF > hello.c
int main(void) { return 0; }
EOF
# riscv64-linux-gnu-gcc -O2 -static hello.c
# qemu-riscv64-static ./a.out

This can be verified both by running the resulting binary under
qemu-riscv64-static or on real RISC-V hardware running the Debian
RISC-V port.

On target hardware, I can get a stack trace in early libc code:

$ gdb ./a.out 
GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "riscv64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./a.out...
(gdb) run
Starting program: /home/remi/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x0002ce94 in __ctype_init ()
(gdb) bt
#0  0x0002ce94 in __ctype_init ()
#1  0x00023d92 in __libc_early_init ()
Backtrace stopped: frame did not save the PC


There are no such problems with dynamic linking (although in that case
qemu-riscv64-static will obviously refuse to work since it can only
deal with static binaries). There are also no such problems whilst
statically linking Debian libc6 natively on RISC-V: this seems to
affect *only* libc6-dev-riscv64-cross.

This was working fine a few months ago. Not sure when did it break.

Best regards,

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fi_FI.UTF-8), LANGUAGE=fr:en_GB:fi
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev-riscv64-cross depends on:
ii  libc6-riscv64-cross   2.34-7cross2
ii  linux-libc-dev-riscv64-cross  5.18.16-1cross2

libc6-dev-riscv64-cross recommends no packages.

libc6-dev-riscv64-cross suggests no packages.

-- no debconf information

Bug#1019353: transition: perl 5.36

[Niko Tyni]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Tags: moreinfo
X-Debbugs-Cc: p...@packages.debian.org
Control: block -1 with 1016761

We'd like to get Perl 5.36 in bookworm. Filing this to get it on the
radar properly, but I'd like to do a few more checks first. So tagging
'moreinfo' for now. I'll remove that when I'm done with the checks,
hopefully in a couple of weeks at the latest.

The package in experimental is in good shape.  We've been continuously
rebuilding perl reverse dependencies (currently 4507 packages) since
June or so on http://perl.debian.net/ , and tracking regressions at

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=perl-5.36-transition;users=debian-p...@lists.debian.org

The only remaining regression in testing that I'm aware of is #1016761
which should be easy to fix by dropping the problematic test case that
uses HTTP::Tiny internals in a not forward compatible way.

I ran autopkgtest checks of 3847 packages that have Testsuite-Triggers:
perl or Testsuite: autopkgtest-pkg-perl locally in July and did not find
any regressions from sid.  I intend to recheck this on ci.debian.net
soon now that we have support for external repositories there (thanks,
Paul et al.!) The recent egrep deprecation (#1019335) in sid may be a
blocker for this though.

I also intend to test rebuild the ~500 packages in sid that will need a
binNMU one more time to catch any non-perl-related new build failures.
I don't have a good way to spot non-amd64 architecture specific issues
or unrelated version skew between unstable and testing, so those can
still yield surprises for the transition.

title = "perl";
is_affected = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ 
"libperl5.34|perlapi-5.34";
is_good = .depends ~ "libperl5.36|perlapi-5.36" | .pre-depends ~ 
"libperl5.36|perlapi-5.36";
is_bad = .depends ~ "libperl5.34|perlapi-5.34" | .pre-depends ~ 
"libperl5.34|perlapi-5.34";

Thanks for your work on the release,
-- 
Niko Tyni   nt...@debiar.org

Bug#1017434: speedtest-cli: error message "Cannot retrieve speedtest configuration"

[Antoine Beaupré]

I just had this again:

anarcat@emma:linkchecker$ speedtest-cli
Retrieving speedtest.net configuration...
Cannot retrieve speedtest configuration
ERROR: HTTP Error 403: Forbidden
anarcat@emma:linkchecker[1]$

Pretty reliably.

a.
-- 
Striving for social justice is the most valuable thing to do in life
   - Albert Einstein

Bug#1018753: abiword: FTBFS on several platforms (test timeout)

[Sebastian Ramacher]

Control: severity -1 serious

On 2022-08-30 16:14:28 +0800, Eric Long wrote:
> Source: abiword
> Version: 3.0.5~dfsg-1
> Severity: serious
> Tags: ftbfs patch
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: i...@hack3r.moe
> 
> Dear maintainer,
> 
> abiword failed to build on armel, mipsel, hppa, ppc64, riscv64, sparc64 and 
> x32
> due to timeout of test located at `src/wp/test/unix`:
> 
> ```
> Making check in unix
> make[6]: Entering directory '/<>/src/wp/test/unix'
> make  AbiWord-test testwrap.sh-stamp testwrap.sh
> make[7]: Entering directory '/<>/src/wp/test/unix'
> g++ -std=c++11 -DHAVE_CONFIG_H -I. -I../../../..  -I/usr/include/libpng16 
> -pthread -I/usr/include/wv -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/enchant-2 -I/usr/include/libgsf-1 -I/usr/include/rasqal 
> -I/usr/include/raptor2 -I/usr/include/evolution-data-server 
> -I/usr/include/libsecret-1 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 
> -I/usr/include/cairo -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 
> -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
> -I/usr/include/dbus-1.0 -I/usr/lib/riscv64-linux-gnu/dbus-1.0/include 
> -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo 
> -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 
> -I/usr/include/fribidi -I/usr/include/harfbuzz -I/usr/include/atk-1.0 
> -I/usr/include/cairo -I/usr/include/librsvg-2.0 -I/usr/include/gdk-pixbuf-2.0 
> -I/usr/include/riscv64-linux-gnu -I/usr/include/libmount -I/usr/include/blkid 
> -I/usr/include/cairo -I/usr/include/glib-2.0 
> -I/usr/lib/riscv64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
> -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
> -I/usr/include/libgoffice-0.10 -DGDK_VERSION_MIN_REQUIRED=GDK_VERSION_3_0 
> -I/usr/include -I../../../..  -I../../../../src/af/ev/gtk 
> -I../../../../src/af/ev/xp -I../../../../src/af/gr/gtk 
> -I../../../../src/af/gr/xp -I../../../../src/af/util/unix 
> -I../../../../src/af/util/xp -I../../../../src/af/xap/gtk 
> -I../../../../src/af/xap/xp -I../../../../src/text/fmt/gtk 
> -I../../../../src/text/fmt/xp -I../../../../src/text/ptbl/xp 
> -I../../../../src/wp/impexp/gtk -I../../../../src/wp/impexp/xp 
> -I../../../../src/wp/ap/gtk -I../../../../src/wp/ap/xp 
> -I../../../../src/plugins -DABIWORD_DATADIR="\"/usr/share/abiword-3.0\"" 
> -I../../../../src/af/tf/xp/ -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
> -Wsign-compare -Wpointer-arith -Wchar-subscripts -Wwrite-strings 
> -Wmissing-noreturn -Wformat-overflow=2 -Wunused -Wpointer-arith -Wshadow  -g 
> -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wno-overloaded-virtual -MT AbiWord_test-test_main.o 
> -MD -MP -MF .deps/AbiWord_test-test_main.Tpo -c -o AbiWord_test-test_main.o 
> `test -f 'test_main.cpp' || echo './'`test_main.cpp
> chmod a+x testwrap.sh
> make[7]: 'testwrap.sh' is up to date.
> touch testwrap.sh-stamp
> In file included from test_main.cpp:21:
> ../xp/main.cpp:49:46: warning: macro "__TIME__" might prevent reproducible 
> builds [-Wdate-time]
>49 | const char* XAP_App::s_szBuild_CompileTime = __TIME__;
>   |  ^~~~
> ../xp/main.cpp:50:46: warning: macro "__DATE__" might prevent reproducible 
> builds [-Wdate-time]
>50 | const char* XAP_App::s_szBuild_CompileDate = __DATE__;
>   |  ^~~~
> In file included from ../xp/all_test.h:29,
>  from ../xp/main.cpp:24:
> ../../../../src/text/ptbl/xp/t/pp_PropertyMap.t.cpp: In function ‘void 
> _tftest_main_12()’:
> ../../../../src/text/ptbl/xp/t/pp_PropertyMap.t.cpp:34:24: warning: unused 
> variable ‘map’ [-Wunused-variable]
>34 | PP_PropertyMap map;
>   |^~~
> mv -f .deps/AbiWord_test-test_main.Tpo .deps/AbiWord_test-test_main.Po
> /bin/bash ../../../../libtool  --tag=CXX   --mode=link g++ -std=c++11  -g -O2 
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wno-overloaded-virtual -L../../../../src 
> -labiword-3.0 -L../../../../src/af/tf/xp -lxp -Wl,-z,relro -Wl,-z,now 
> -Wl,--as-needed -o AbiWord-test AbiWord_test-test_main.o -lpng16 -lz -ljpeg 
> -lfribidi -lgthread-2.0 -pthread -lwv -lz -lpng -lwmf -lwmflite -lfreetype 
> -lX11 -lexpat -ljpeg -lpng -lz -lm -lgsf-1 -lxslt -lenchant-2 -lgoffice-0.10 
> -lrdf -lrasqal -lraptor2 -lebook-1.2 -ledata-book-1.2 -lebackend-1.2 
> -lebook-contacts-1.2 -ledataserver-1.2 -lsecret-1 -lxml2 -lsoup-2.4 
> -Wl,--export-dynamic -lgmodule-2.0 -pthread -lical -licalss -licalvcal -lz 
> -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 
> -lcairo-gobject -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 
> -lglib-2.0 -lcairo -lfontconfig -lfreetype -lX11 -ljpeg 
> libtool: link: g++ -std=c++11 -g -O2 "-ffile-prefix-map=/<>=." 
> 

Bug#1015537: macaulay2: ftbfs with LTO (link time optimization) enabled

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/M2/issues/2604

On Tue, 19 Jul 2022 16:56:31 + Matthias Klose  wrote:

This package currently fails to build (at least on the amd64
architecture) with link time optimizations enabled.  For a background
for LTO please see

https://wiki.debian.org/ToolChain/LTO

The goal is to enable this optimization by default in an upcoming
Debian release in dpkg-buildflags for 64bit architectures.  The goal
is to get this package to build with link time optimizations, or to
explicitly disable link time optimizations for this package build.

To reproduce the build failure, enable the lto optimization in
testing/unstable by adding "optimize=+lto" to DEB_BUILD_MAINT_OPTIONS
in the debian/rules file, or if this macro is unset, just set it:

export DEB_BUILD_MAINT_OPTIONS = optimize=+lto

Please try to fix the build with lto enabled, fixing the packaging or
forwarding the issue upstream. If the issue cannot be fixed,
explicitly disallow building the package with lto by adding to your
rules file:

export DEB_BUILD_MAINT_OPTIONS = optimize=-lto

or adding that string to your existing setting of DEB_BUILD_MAINT_OPTIONS.

The full build log can be found at:
http://qa-logs.debian.net/2022/06/09/dpkglto/macaulay2_1.20+ds-4_unstable_dpkglto.log
The last lines of the build log are at the end of this report.

[...]
testing: schorder2.m2
testing: schreyer.m2
testing: schubert.m2
testing: schur.m2
testing: selectInSubring.m2
testing: singular.m2
testing: size.m2
testing: skew.m2
testing: skewmonideal.m2
testing: skewmult.m2
testing: smith.m2
testing: socket.m2
testing: sort.m2
testing: sortcol.m2
testing: sottile.m2
testing: strings.m2
testing: submatrix.m2
testing: subring.m2
testing: subsets.m2
testing: subst.m2
testing: subst2.m2
testing: subst3.m2
testing: subst4.m2
testing: subst5.m2
testing: subst6.m2
testing: subst7.m2
testing: substitute-1.2.m2
testing: sums.m2
testing: symbols.m2
testing: symmetricAlgebra.m2
testing: symmetricPowers.m2
testing: syz-schreyer-order.m2
testing: syz1.m2
testing: syz2.m2
testing: tensor.m2
testing: tensor_monoid.m2
testing: tensor_ring.m2
testing: terms.m2
testing: testdet.m2
testing: testgb.m2
testing: testing.m2
testing: testmat.m2
testing: testpromote.m2
testing: testskew.m2
testing: testsubring.m2
testing: threads.m2
testing: timing-quotient.m2
  -- occasionally caused build failures, see:
  -- https://github.com/Macaulay2/M2/issues/1804
  -- https://github.com/Macaulay2/M2/pull/1811
  -- https://github.com/Macaulay2/M2/pull/1957
  assert BinaryOperation {symbol <, tim#0, standardSecond}
timing-quotient.m2:224:1:(3):[5]: error: assertion failed:
.569765<.381781 is false


I was never able to reliably duplicate this particular error, and I think it's 
likely unrelated to LTO (see [1,2]).

However, PPA builds of Macaulay2 are now consistently failing in Ubuntu 22.10, 
which enables LTO and uses GCC 12 (the GCC version in the above log was 11), 
e.g., [3].  I've opening a corresponding issue upstream [4].

Doug

[1] https://github.com/Macaulay2/M2/issues/1804
[2] https://github.com/Macaulay2/M2/issues/2533
[3] 
https://launchpadlibrarian.net/622254125/buildlog_ubuntu-kinetic-amd64.macaulay2_1.20.0.1+git202209061708-0ppa202209021435~ubuntu22.10.1_BUILDING.txt.gz
[4] https://github.com/Macaulay2/M2/issues/2604


signature.asc
Description: PGP signature

Bug#1019325: logcheck: multiple calls to deprecated egrep generates lots of warnings

[debian]

The deprectation warnings are not the only problem, once grep -E is
used: "Regular expressions with stray backslashes now cause warnings"
(from the grep package's NEWS.Debian.gz). Such backslashes are found in
multiple config files, I saw them reported for

   * anon-proxy
   * dovecot
   * dhcp
   * cyrus
   * perdition
   * nagios
   * kernel
   * hylafax
   * innd

Regards,

Nicolas

Bug#1017772: OneTBB migration to testing stalled

[M. Zhou]

Control: reassign -1 src:binutils 2.38.90.20220713-2

I believe this issue is a binutils regression instead of GCC-12
regression. The default linker ends up with segmentation fault
on ppc64el. However, if I change the default linker from bfd to
gold, the issue is temporarily bypassed in onetbb 2021.5.0-14.

https://salsa.debian.org/science-team/tbb/-/commit/ad1fe7e7021a37b63f8c7a2b4dc0c766828e7758

I have uploaded -14 to experimental and it passed the NEW queue
lightning fast. I shall upload -15 to unstable as long as it
becomes green on all architectures.

On Sun, 2022-09-04 at 10:59 -0400, M. Zhou wrote:
> Control: affects -1 src:onetbb
> 
> It's due to a regression bug in GCC-12 that caused linker internal
> error on ppc64el:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017772
> Does not look like something I can look into.
> 
> If you need it soon in testing, please go ahead and downgrade
> compiler
> to gcc-11 for ppc64el only.
> 
> On Sun, 2022-09-04 at 10:50 +0530, Nilesh Patra wrote:
> > Hi Mo,
> > 
> > It seems that the migration of oneTBB to testing is stalled (since
> > 16
> > days) due
> > to FTBFS on ppc64el with some linker errors[1]
> > I am not sure what is up there, could you please take a look?
> > 
> > [1]:
> > https://buildd.debian.org/status/fetch.php?pkg=onetbb=ppc64el=2021.5.0-13=1662266636=0
> > 
> 
> 

Bug#1019352: python-pytest-flake8: FTBFS with flake8 5.0.4

[Emanuele Rocca]

Source: python-pytest-flake8
Version: 1.0.6-4
Severity: serious

The package fails to build with the flake8 version currently in sid,
namely 5.0.4-1. Multiple tests fail, partial output follows:

[...]

copying pytest_flake8.py -> 
/build/python-pytest-flake8-1.0.6/.pybuild/cpython3_3.10_python-pytest-flake8/build
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:240: cd 
/build/python-pytest-flake8-1.0.6/.pybuild/cpython3_3.10_python-pytest-flake8/build;
 pyt
hon3.10 -m pytest 
= test session starts ==
platform linux -- Python 3.10.6, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /build/python-pytest-flake8-1.0.6, configfile: tox.ini
plugins: flake8-1.0.6
collected 14 items

pytest_flake8.py F   [  7%]
test_flake8.py F...FF.xF [100%]
LURES ===
_ FLAKE8-check _
pytest_flake8.py:122: in runtest
found_errors = check_file(
pytest_flake8.py:201: in check_file
config_finder = config.ConfigFileFinder(
E   AttributeError: module 'flake8.options.config' has no attribute 
'ConfigFileFinder'
_ FLAKE8-check _
/usr/lib/python3/dist-packages/pluggy/_hooks.py:265: in __call__
return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
/usr/lib/python3/dist-packages/pluggy/_manager.py:80: in _hookexec

[...]

The autopkgtests also fail, see full output at:
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pytest-flake8/25797652/log.gz

Bug#1014162: lintian's run-time is too long on some packages

[Christoph Berg]

Re: To Debian Bug Tracking System
> Version: 2.115.2
> Severity: normal
> 
> Lintian now needs about 3 minutes to check the postgresql-15 source
> package alone.

Current timings:

$ time lintian postgresql-15_15~beta4-1.pgdg+1.dsc
2.115.2 2m29,255s
2.115.3 1m24,698s
2.115.4~git 1m23,866s

So it became a lot better, but I think 84s is still too slow for
checking a .dsc.

Christoph

Bug#1018991: STOP THOSE BUGS, PLEASE

[Rene Engelhard]

Hi,

STOP THIS F* MADNESS.


Debian is not LibreOffice upstream. Such bugs have to be fixed 
upstream, not in Debian.


Report them there.


- Neither do I as the sole maintainer of libreoffice (remember, free 
time and there's other stuff to do in life) have time to debug all 
this what belongs upstream,


- Nor to report all this upstream without any sensible information.

This then will result in either lingering around until infunity or 
requring me to play proxy (which I neither have time for)


Here in Debian this will just pile up without any action.

And also LibreOffice is not a PDF viewer or PDF editor. That PDF import 
"feature" was one of the worst features even implemented, and marketing 
and too big user expectations (as we see here) do the  rest.



Use PDF viewers to view PDFs. (You  compare already with evince, etc. 
Use them.)



Regards,


Rene

Bug#1019351: pulseaudio: Update pulseaudio to 16.1 in Debian unstable

[Amr Ibrahim]

Package: pulseaudio
Version: 15.0+dfsg1-4+b1
Severity: minor

Dear Maintainer,

Please update pulseaudio to 16.1 in Debian unstable.

Best,
Amr


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser 3.128
ii  init-system-helpers 1.64
ii  libasound2  1.2.7.2-1
ii  libasound2-plugins  1.2.7.1-1
ii  libc6   2.34-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-2
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.73.3-3
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.3-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-4
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   15.0+dfsg1-4+b1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.0.31-2
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.0-1
ii  libstdc++6  12.2.0-1
ii  libsystemd0 251.4-3
ii  libtdb1 1.4.6-3
ii  libudev1251.4-3
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libx11-62:1.8.1-2
ii  libx11-xcb1 2:1.8.1-2
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  lsb-base11.2
ii  pulseaudio-utils15.0+dfsg1-4+b1

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-2
ii  libpam-systemd [logind]  251.4-3
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
pn  pavucontrol  
pn  pavumeter
ii  udev 251.4-3

-- Configuration Files:
/etc/pulse/daemon.conf changed [not included]

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; 

Bug#1018991: STOP THOSE BUGS, PLEASE

[Rene Engelhard]

Hi,

Am 07.09.22 um 15:54 schrieb jindam, vani:

Package: libreoffice-writer
No. Also not on any of your other bugs. The PDF "import" thingy is in 
core, and in many cases PDFs will be opened in Draw anyway.

Version: 1:7.4.1~rc1-3
Severity: important
X-Debbugs-Cc: jindam.v...@disroot.org

Dear Maintainer,


Not so dear submitter,



* my os on android 9 (samsung galaxy j7 nxt
Version: J701F/DS (India)) device(z):
  ** install userland app, full upgrade
buster(default), dist upgrade to
bullseye, remove security from sources.list,
dist upgrade to unstable
  ** install nano & add disable recommended
packages
  ** installed: libreoffice-writer,
libreoffice-calc, mc, ghostscript,
qpdfview, evince, gnumeric, abiword,
gv, palemoon (.deb & its dependencies),
inkscape, openbox, default-jre


Aha.



  ** very important :: debugging is
not possible

Nonsense. There's arm devices out there.

* there are also several files with
same issue, if patch is created & applied
to bug
   ** expect me to test in next dot
release or version
   ** i will also test other files, if
they have issues, i will create new bug



STOP THIS F* MADNESS.


Debian is not LibreOffice upstream. Such bugs have to be fixed upstream, 
not in Debian.


Report them there.


- Neither do I as the sole maintainer of libreoffice (remember, free 
time and there's other stuff to do in life) have time to debug all this 
what belongs upstream,


- Nor to report all this upstream without any sensible information.

This then will result in either lingering around until infunity or 
requring me to play proxy (which I neither have time for)


Here in Debian this will just pile up without any action.


Regards,


Rene

Bug#1019350: gnome-terminal: "Select All" merely selects the visible part of terminal contents

[kalle]

Package: gnome-terminal
Version: 3.44.1-1
Severity: normal

Dear Maintainer,

when using the terminal to solve a problem or to perform some other rather
complex operation that cannot be described with a few sentences, I would like
to be able to save the complete terminal contents to a file for reference in
case I have to perform that same operation on a different machine.
"Copy as HTML" is especially nice because colors are preserved.

But sadly, "Select All" doesn't select the full contents of the scrollback
buffer as you would expect, but merely what is currently visible.

Well, you can select everything using the mouse, but this would be a pain for a
huge number of lines.


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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.0-2
ii  dbus-x11 [dbus-session-bus]   1.14.0-2
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-3
ii  gnome-terminal-data   3.44.1-1
ii  gsettings-desktop-schemas 43~alpha-1
ii  libatk1.0-0   2.38.0-1
ii  libc6 2.34-7
ii  libdconf1 0.40.0-3
ii  libgcc-s1 12.2.0-1
ii  libglib2.0-0  2.73.3-3
ii  libgtk-3-03.24.34-3
ii  libpango-1.0-01.50.9+ds-1
ii  libstdc++612.2.0-1
ii  libuuid1  2.38.1-1
ii  libvte-2.91-0 0.69.99-1
ii  libx11-6  2:1.8.1-2

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.2-2
ii  nautilus-extension-gnome-terminal  3.44.1-1
ii  yelp   42.1-2

gnome-terminal suggests no packages.

-- no debconf information

Bug#1019349: librust-cssparser-dev: impossible to install

[Jonas Smedegaard]

Package: librust-cssparser-dev
Version: 0.27.2-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is impossible to install: Depends on several missing packages. 

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMY1LoACgkQLHwxRsGg
ASHv8A//ToueLfvnKx7VrPDsyMlGMobcXLnoZUB0kejrUHlckxcFY+I/PHgtWsek
t+Q67fL/VJbq3VwYmRN5DLAZ5SiRnuS1wp8p620JrQoFJLs1AQGmF38yHMaskXPT
ezbwtDMckG3CBh8nHIV8XW/Kf3ApJZnwH1q0Hx6Jd1r92XdknkesNuktkxhj4R2w
ZY1RaJxefHWI3hunCxqB2KUwuPx+QjC5qZ8DMQtlehmJbNrrhtYio5srhAz4LE1Q
RDycZd1+NtoJAE1s9t7ITw5WBm8umvubjcxbY0PZT5cODvSSiamZvuuHCPCK2si/
khb8XXzHNgwm60wDsSHp2a6RuLj7XOPHIcMyr2la45mMqwVB7H7gYpqFagRo/9vF
03vusOkj41RGfn6aSUQVp6p5qN9rFJAJEo/YgEGU9+E6axb3iMl7zuyWqm4ZxJ+/
njX+GCg6lA1dnKTnDuOcN0yL9nUUQNSfZ80rSRCcumBNDzw8IGS9hr3MTnB5bBJL
nN/50LTt0bAq+YBd6tz8VLW9YIW61/Ept4Yfyi0TevFcSD4AvNjzxwImWhM0Yfkx
MOb7UQmyodaeR5BjrF4SCzBwVG8CHdKOOlYa/pU52GDGWXu30qtRT92y/dAm1otz
++mJJdKPUHfoaWM0nlPdiWQopisp16jFGZtJw22EI5Dt03ogpWI=
=QSRT
-END PGP SIGNATURE-

Bug#1019295: schroot: Displays a lot of "egrep: warning: egrep is obsolescent; using grep -E"

[Christoph Biedl]

Control: tags 1019295 pending

Sven-Haegar Koch wrote...

> Since update of grep to 3.8-1 using schroot outputs a lot of egrep
> warnings:
> 
> Examples:
> 
> E: 20copyfiles: egrep: warning: egrep is obsolescent; using grep -E

Oy, this is going to be a lot of fun:

https://codesearch.debian.net/search?q=egrep=1
https://bugs.debian.org/1019335

Reworking the shell scripts using the input of shellcheck and shfmt was
already on the agenda, so let's speed up things a bit. At least in that
regard.

Christoph



signature.asc
Description: PGP signature

Bug#1018224: src:exempi: fails to migrate to testing for too long: FTBFS on s390x

[Dipak Zope1]

Hi Paul,


Setting the environment variable ATOPACCT to empty value disables this issue.

Please use this workaround in the caller script of atop till we get a final fix.

 export ATOPACCT=""





The behaviour is described in the source as below:



/*

** when a particular environment variable is present, atop 
should

** use a specific accounting-file (as defined by the environment

** variable) or should use no process accounting at all (when

** contents of environment variable is empty)

*/



-Dipak

From: Dipak Zope1 
Date: Tuesday, 30 August 2022 at 3:28 PM
To: Paul Gevers , 1018...@bugs.debian.org 
<1018...@bugs.debian.org>, debian-s390 
Subject: [EXTERNAL] RE: src:exempi: fails to migrate to testing for too long: 
FTBFS on s390x
Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it further and 
will keep this thread updated. I am looking forward to have a fix for this for 
s390x. ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Apologies for late response. It looks like the issue is related to the 
synchronization between atop and atopacctd. I am looking into it further and 
will keep this thread updated.

I am looking forward to have a fix for this for s390x.

-Dipak


On 30/08/22, 12:44 AM, "Paul Gevers"  wrote:
Hi Michael

On 29-08-2022 14:23, Michael Biebl wrote:
> As you are probably aware, this issue is known and tracked in [1].

Which I added as a blocker and mentioned in my message, so yes.

> The
> package FTBFS after enabling the test suite. I raised this issue
> upstream but there is no real interest/motivation [2] on their part to
> address these (most likely endianess related) issues.
> So I informed the s390x porters as well but got not feedback so far.

Ack, I saw the latter part.

> To me it seems it's better to not continue ship a known broken package
> on s390x and think a partial architecture removal is probably the better
> alternative.

If you think the package indeed is severely broken, then removal sounds
best. If its broken in some less common use cases, it may be OK to leave
it for now (skipping those tests on 390x) and let the porters have a
look when they have time.

> Let me know what you think

It all depends on how broken it is. If you would consider the bugs found
by the tests RC, then removal is the better choice unless a porter steps
up to fix it. If the bugs would be important at most, than skipping
broken tests on s390x sounds like the better option. Removal bugs are
hard to time predict.

Paul

PS: I would not disable building on s390x if you have the test suite
finding out severe problems (as the d/control file doesn't have negated
architecture fields yet). Just getting the binary removed and FTBFS will
prevent the architecture from building again.

Bug#1019347: Backups end up mostly empty when location.patterns is used and /root/.borgmatic exists

[Sven Bartscher]

Package: borgmatic
Version: 1.5.12-2
Severity: grave
Tags: upstream fixed-upstream
Forwarded: 
https://projects.torsion.org/borgmatic-collective/borgmatic/issues/574
Control: found -1 1.6.3-1

Hi,

Recently I reported the bug mentioned above upstream, which causes
most data to be silently excluded from backups if /root/.borgmatic
exists. Since details of the bug are already available in the upstream
bug report, I will omit them here for brevity.

Since the issue has already been fixed upstream, this bug is only
meant to track the issue in Debian.

I've set the severity to grave, because the bug causes borgmatic to
produce effectively empty backups, while the user may believe to have
secure backups, which qualifies as data loss to me. Feel free to lower
the severity to normal if you disagree.

Regards
Sven

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 
'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages borgmatic depends on:
ii  borgbackup 1.2.1-2
ii  python33.10.6-1
ii  python3-colorama   0.4.5-2
ii  python3-jsonschema 4.6.0-3
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-requests   2.27.1+dfsg-1
ii  python3-ruamel.yaml0.17.16-1

borgmatic recommends no packages.

borgmatic suggests no packages.

-- no debconf information

Bug#1019345: flake8-class-newline: autopkgtest failure

[Emanuele Rocca]

Source: flake8-class-newline
Version: 1.6.0-2
Severity: serious

Hi,

the test fails with the latest flake8 version in sid (5.0.4-1).

The output of flake8 --version with -class-newline installed is now:

$ flake8 --version
5.0.4 (flake8-class-newline: 1.6.0, mccabe: 0.6.1, pycodestyle: 2.9.1,
pyflakes: 2.5.0) CPython 3.10.6 on Linux

While the autopkgtest expects it to include the string
"new_line_checker".

https://ci.debian.net/data/autopkgtest/testing/amd64/f/flake8-class-newline/25797651/log.gz

[...]
Processing triggers for libc-bin (2.34-7) ...
(Reading database ... 14305 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [20:13:42]: test install: [---
autopkgtest [20:13:43]: test install: ---]
autopkgtest [20:13:43]: test install:  - - - - - - - - - - results - - -
- - - - - - -
install  FAIL non-zero exit status 1
autopkgtest [20:13:43]:  summary
install  FAIL non-zero exit status 1

Bug#1019340: Segfaults on startup

[tony mancill]

On Wed, Sep 07, 2022 at 04:57:14PM +0200, Christoph Berg wrote:
> Package: tucnak
> Version: 4.36-1
> Severity: grave
> 
> tucnak doesn't start here:
> 
> $ LC_ALL=C tucnak

Hi Christoph,

Hmm... it starts and runs here, so I don't think it is broken for
everyone.  I uninstalled and reinstalled to be sure that I'm running the
binaries from the archive.  Perhaps related to differences in windowing
setups?  I'm running xwayland and Gnome.

Looking at your stack trace, my first guess is that this is an issue
introduced in libzia based on this bit.

> #11 0x7febdc0654f8 n/a (libSDL2-2.0.so.0 + 0x314f8)
> #12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438)
> #13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4)
> #14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0)
> #15 0x7febd5ead5ee n/a (crocus_dri.so + 0xad5ee)
> #16 0x7febd80836e6 glPrimitiveBoundingBox 
> (libGLX_mesa.so.0 + 0x4e6e6)
> #17 0x7febd8085d32 glPrimitiveBoundingBox 
> (libGLX_mesa.so.0 + 0x50d32)
> #18 0x7febd80860d3 glPrimitiveBoundingBox 
> (libGLX_mesa.so.0 + 0x510d3)
> #19 0x7febd5eaf0df n/a (crocus_dri.so + 0xaf0df)

I will poke through the libzia changes.

Thanks,
tony

Bug#1018296: ftpsync: rsync 3.2.5-1 breaks ftpsync

[Julien Cristau]

On Sun, Aug 28, 2022 at 17:05:10 +0100, Chris Boot wrote:

> Package: ftpsync
> Version: 20180513+nmu1
> Severity: important
> 
> Hi all,
> 
> I discussed this a few days ago in #debian-ftp; I think the bug is
> probably in rsync but ftpsync is how I ran across it.
> 
> My mirror syncs against free.hands.com / ftp.uk.debian.org. With rsync
> 3.2.5-1 my mirror fails to sync: stage1 executes fine but stage 2 fails
> with the following error from rsync:
> 
> ERROR: rejecting excluded file-list name: project
> rsync error: protocol incompatibility (code 2) at flist.c(994)
> [Receiver=3.2.5]
> rsync error: protocol incompatibility (code 2) at io.c(1644)
> [sender=3.2.3]
> (from rsync-ftpsync.error.0)
> 
On Fri, Sep  2, 2022 at 10:19:01 -0700, Lance Albertson wrote:

> I have reported a similar bug to RedHat:
> https://bugzilla.redhat.com/show_bug.cgi?id=2123815
> 
The RH bug points to https://github.com/WayneD/rsync/issues/356 which
seems to confirm this is an rsync bug/regression.  Hopefully it can be
fixed soon; I see Samuel is active in the upstream issue.

Cheers,
Julien

Bug#1019335: Reconsider the egrep and fgrep deprecation

[Santiago Ruano Rincón]

Hi Christoph,

El 07/09/22 a las 16:45, Christoph Berg escribió:
> POSIX has these notes:
> 
> RATIONALE
> 
> This grep has been enhanced in an upwards-compatible way to provide the 
> exact functionality of the historical egrep and fgrep commands as well. It 
> was the clear intention of the standard developers to consolidate the three 
> greps into a single command.
> 
> The old egrep and fgrep commands are likely to be supported for many 
> years to come as implementation extensions, allowing historical applications 
> to operate unmodified.
> 
> https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/
> 
> 
> I don't think there's anything to gain (besides saving 2 filesystem
> blocks) by removing egrep and fgrep.
> 
> Christoph
> 

Thanks for filing this bug report.

For the moment, I am waiting for (a final) upstream input about those
warning, in this bug:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57604

But giving:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49996
I doubt they are willing to reconsider deprecating egrep and fgrep.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1019333: cadabra2: FTBFS with pkgconf

[Andrej Shadura]

Hi,

On Wed, 7 Sep 2022, at 17:25, Gürkan Myczko wrote:
> Hi Andrej
> 
> The trick is to not use any pkg*config and the missing header problem you 
> encounter is the older version of pcre (3 < 2): 
> https://salsa.debian.org/tar/cadabra2/-/blob/master/debian/control
> 
> please refer to the closed bugs in actual d/changelog?
> 
> what did i miss? (i havent tried to build it now)

Well, something definitely does pull pkg-config during a regular build.
As you can see from the log, libpcre2 is the latest one:

Get:226 http://deb.debian.org/debian unstable/main amd64 libpcre2-16-0 amd64 
10.40-1 [243 kB]
Get:227 http://deb.debian.org/debian unstable/main amd64 libpcre2-32-0 amd64 
10.40-1 [232 kB]
Get:228 http://deb.debian.org/debian unstable/main amd64 libpcre2-posix3 amd64 
10.40-1 [53.8 kB]
Get:229 http://deb.debian.org/debian unstable/main amd64 libpcre2-dev amd64 
10.40-1 [746 kB]

However, pcrecpp.h is apparently in libpcre3-dev:

libpcre3-dev: /usr/include/pcrecpp.h
libpcre3-dev: /usr/include/pcrecpparg.h
libpcre3-dev: /usr/lib/x86_64-linux-gnu/libpcrecpp.a
libpcre3-dev: /usr/lib/x86_64-linux-gnu/libpcrecpp.so
libpcre3-dev: /usr/lib/x86_64-linux-gnu/pkgconfig/libpcrecpp.pc

-- 
Cheers,
  Andrej

Bug#1019333: cadabra2: FTBFS with pkgconf

[Gürkan Myczko]

Hi Andrej

The trick is to not use any pkg*config and the missing header problem you 
encounter is the older version of pcre (3 < 2): 
https://salsa.debian.org/tar/cadabra2/-/blob/master/debian/control

please refer to the closed bugs in actual d/changelog?

what did i miss? (i havent tried to build it now)

Best,
Gürkan



> On 7 Sep 2022, at 16:18, Andrej Shadura  wrote:
> 
> Control: retitle -1 cadabra2: FTBFS due to a missing header
> 
>> On Wed, 7 Sep 2022, at 16:13, Andrej Shadura wrote:
>> While rebuilding your package, it failed to build from the source
>> due to the following error:
> 
> While this package *also* failed to build with pkgconf, I must note that this 
> was a mistake in the Subject field — it fails to build with pkg-config as 
> well.
> 
> -- 
> Cheers,
>  Andrej

Bug#1019342: gnome-remote-desktop: Update to 43

[Jeremy Bicha]

Source: gnome-remote-desktop
Severity: wishlist
Version: 42.4-1
Control: block -1 by 1016491

The update to gnome-remote-desktop 43 is blocked because freerdp2
2.8.0 isn't in Debian yet.

Thank you,
Jeremy Bicha

Bug#1016766: gnome-initial-setup: Please upgrade to 43

[Jeremy Bicha]

Control: severity -1 important
Control: retitle -1 gnome-initial-setup: Privacy page needs webkitgtk 5.0

To keep gnome-initial-setup installable with the evolution-data-server
3.45 transition, I've uploaded gnome-initial-setup 43 to Debian
Unstable but I had to disable the privacy page because it uses
webkitgtk 5.0.

Thank you,
Jeremy Bicha

Bug#1019341: pulseaudio: Start of daemon fails

[Axel Dürrbaum]

Package: pulseaudio
Version: 16.1+dfsg1-1
Severity: important

Dear Maintainer,

after the update today the pulseaudio daemon does not start anymore:

pulseaudio: symbol lookup error: /usr/lib/x86_64-linux-gnu/libsndfile.so.1:
undefined symbol: lame_encode_buffer_interleaved_int

That conserns the stable and the experimental version of pulseaudio.

Sincerely yours
Axel Dürrbaum


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser 3.129
ii  init-system-helpers 1.64
ii  libasound2  1.2.7.2-1
ii  libasound2-plugins  1.2.7.1-1
ii  libc6   2.34-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-2
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12.2.0-1
ii  libglib2.0-02.73.3-3
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.3-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-4
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   16.1+dfsg1-1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.1.0-1
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.0-1
ii  libstdc++6  12.2.0-1
ii  libsystemd0 251.4-3
ii  libtdb1 1.4.6-3
ii  libudev1251.4-3
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libwrap07.6.q-31
ii  libx11-62:1.8.1-2
ii  libx11-xcb1 2:1.8.1-2
ii  libxcb1 1.15-1
ii  libxtst62:1.2.3-1.1
ii  lsb-base11.2
ii  pulseaudio-utils16.1+dfsg1-1

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-2
ii  libpam-systemd [logind]  251.4-3
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
ii  paprefs  1.2-1
ii  pavucontrol  5.0-2
ii  pavumeter0.9.3-4+b4
ii  udev 251.4-3

-- Configuration Files:
/etc/pulse/daemon.conf changed:
; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no
high-priority = yes
rlimit-nice = 31 
nice-level = -11
; realtime-scheduling = yes
; realtime-priority = 5
; exit-idle-time = 20
; scache-idle-time = 20
; dl-search-path = (depends on architecture)
; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa
; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0
; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; remixing-produce-lfe = no
; remixing-consume-lfe = no
; lfe-crossover-freq = 0
; flat-volumes = no
; rescue-streams = yes
; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20
; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right
default-fragments = 3
default-fragment-size-msec = 5
; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0

/etc/pulse/default.pa changed:
.fail
load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore
load-module module-augment-properties
load-module module-switch-on-port-available
.ifexists module-udev-detect.so
load-module module-udev-detect tsched=0 tsched_buffer_size=0
.else
load-module module-detect
.endif
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif
.ifexists 

Bug#1019340: Segfaults on startup

[Christoph Berg]

Package: tucnak
Version: 4.36-1
Severity: grave

tucnak doesn't start here:

$ LC_ALL=C tucnak
tucnak: ../src/GLX/libglx.c:966: CommonMakeCurrent: Assertion `oldCtxInfo != 
NULL' failed.
Abgebrochen (Speicherabzug geschrieben)

The stack traces look mostly like garbage:

Stack trace of thread 1472741:
#0  0x7febdaa8983c __pthread_kill_implementation (libc.so.6 
+ 0x8983c)
#1  0x7febdaa3da52 __GI_raise (libc.so.6 + 0x3da52)
#2  0x7febdaa28469 __GI_abort (libc.so.6 + 0x28469)
#3  0x7febdaa28395 __assert_fail_base (libc.so.6 + 0x28395)
#4  0x7febdaa36b02 __GI___assert_fail (libc.so.6 + 0x36b02)
#5  0x7febd80aa3bf n/a (libGLX.so.0 + 0x53bf)
#6  0x7febdc1418a3 n/a (libSDL2-2.0.so.0 + 0x10d8a3)
#7  0x7febdc114aba n/a (libSDL2-2.0.so.0 + 0xe0aba)
#8  0x7febdc115de6 n/a (libSDL2-2.0.so.0 + 0xe1de6)
#9  0x7febdc115ee1 n/a (libSDL2-2.0.so.0 + 0xe1ee1)
#10 0x7febdc0650b2 n/a (libSDL2-2.0.so.0 + 0x310b2)
#11 0x7febdc0654f8 n/a (libSDL2-2.0.so.0 + 0x314f8)
#12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438)
#13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4)
#14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0)
#15 0x7febd5ead5ee n/a (crocus_dri.so + 0xad5ee)
#16 0x7febd80836e6 glPrimitiveBoundingBox (libGLX_mesa.so.0 
+ 0x4e6e6)
#17 0x7febd8085d32 glPrimitiveBoundingBox (libGLX_mesa.so.0 
+ 0x50d32)
#18 0x7febd80860d3 glPrimitiveBoundingBox (libGLX_mesa.so.0 
+ 0x510d3)
#19 0x7febd5eaf0df n/a (crocus_dri.so + 0xaf0df)
#20 0x7febd5eaf21f n/a (crocus_dri.so + 0xaf21f)
#21 0x7febd5eb2205 n/a (crocus_dri.so + 0xb2205)
#22 0x7febd5f85c92 n/a (crocus_dri.so + 0x185c92)
#23 0x7febd5f85f9a n/a (crocus_dri.so + 0x185f9a)
#24 0x7febd5eb1de4 n/a (crocus_dri.so + 0xb1de4)
#25 0x7febd5eb4d51 n/a (crocus_dri.so + 0xb4d51)
#26 0x7febd8077efc n/a (libGLX_mesa.so.0 + 0x42efc)
#27 0x7febd80687f2 n/a (libGLX_mesa.so.0 + 0x337f2)
#28 0x7febd80a87e3 n/a (libGLX.so.0 + 0x37e3)
#29 0x7febd80a9116 n/a (libGLX.so.0 + 0x4116)
#30 0x7febd80aa378 n/a (libGLX.so.0 + 0x5378)
#31 0x7febdc1418a3 n/a (libSDL2-2.0.so.0 + 0x10d8a3)
#32 0x7febdc114aba n/a (libSDL2-2.0.so.0 + 0xe0aba)
#33 0x7febdc0a7daa n/a (libSDL2-2.0.so.0 + 0x73daa)
#34 0x7febdc0a9e0a n/a (libSDL2-2.0.so.0 + 0x75e0a)
#35 0x7febdc09d981 n/a (libSDL2-2.0.so.0 + 0x69981)
#36 0x7febdc09fda9 n/a (libSDL2-2.0.so.0 + 0x6bda9)
#37 0x7febdc087d3a n/a (libSDL2-2.0.so.0 + 0x53d3a)
#38 0x7febdc08e11d n/a (libSDL2-2.0.so.0 + 0x5a11d)
#39 0x7febdc08deb6 n/a (libSDL2-2.0.so.0 + 0x59eb6)
#40 0x7febdc13a02c n/a (libSDL2-2.0.so.0 + 0x10602c)
#41 0x7febdc13b6db n/a (libSDL2-2.0.so.0 + 0x1076db)
#42 0x7febdc087e33 n/a (libSDL2-2.0.so.0 + 0x53e33)
#43 0x5586f2631edb sdl_event_thread (tucnak + 0x121edb)
#44 0x7febdc279c0d n/a (libglib-2.0.so.0 + 0x7ec0d)
#45 0x7febdaa87b27 start_thread (libc.so.6 + 0x87b27)
#46 0x7febdab0a78c __clone3 (libc.so.6 + 0x10a78c)

Stack trace of thread 1472737:
#0  0x7febdaaa13db __memmove_sse2_unaligned_erms (libc.so.6 
+ 0xa13db)
#1  0x7febd5f72904 n/a (crocus_dri.so + 0x172904)
#2  0x7febd5f34f9d n/a (crocus_dri.so + 0x134f9d)
#3  0x7febd5f3831d n/a (crocus_dri.so + 0x13831d)
#4  0x7febd5f3e928 n/a (crocus_dri.so + 0x13e928)
#5  0x7febdc0a8949 n/a (libSDL2-2.0.so.0 + 0x74949)
#6  0x7febdc0a0fc9 n/a (libSDL2-2.0.so.0 + 0x6cfc9)
#7  0x7febdc1110f9 n/a (libSDL2-2.0.so.0 + 0xdd0f9)
#8  0x7febdc11222c n/a (libSDL2-2.0.so.0 + 0xde22c)
#9  0x5586f26337da progress (tucnak + 0x1237da)
#10 0x5586f258bb05 main (tucnak + 0x7bb05)
#11 0x7febdaa2920a __libc_start_call_main (libc.so.6 + 
0x2920a)
#12 0x7febdaa292bc __libc_start_main_impl (libc.so.6 + 
0x292bc)
#13 0x5586f258c0d1 _start (tucnak + 0x7c0d1)

Stack trace of thread 1472740:
#0  0x7febdaa847ea __futex_abstimed_wait_common64 
(libc.so.6 + 0x847ea)

Bug#1019335: Reconsider the egrep and fgrep deprecation

[Christoph Berg]

POSIX has these notes:

RATIONALE

This grep has been enhanced in an upwards-compatible way to provide the 
exact functionality of the historical egrep and fgrep commands as well. It was 
the clear intention of the standard developers to consolidate the three greps 
into a single command.

The old egrep and fgrep commands are likely to be supported for many years 
to come as implementation extensions, allowing historical applications to 
operate unmodified.

https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/


I don't think there's anything to gain (besides saving 2 filesystem
blocks) by removing egrep and fgrep.

Christoph

Bug#1018961: pypandoc tests fail with 2.17.1.1

[Gianfranco Costamagna]

control: forwarded -1 
https://githublab.com/repository/issues/NicklasTegner/pypandoc/278

Hello, this might actually be a pandoc conf issue.

G.

On Fri, 2 Sep 2022 10:17:11 -0700 Steve Langasek  
wrote:

Source: pypandoc
Version: 1.7.4+ds0-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Elena,

The pypandoc autopkgtests are failing against pandoc 2.17.1.1 in unstable:

[...]
==
ERROR: test_conversion_from_non_plain_text_file (tests.TestPypandoc)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.jwltu_fs/downtmp/build.Zuz/src/tests.py", line 
407, in test_conversion_from_non_plain_text_file
received = pypandoc.convert_text('# some title\n', to='docx', format='md', 
outputfile=file_name)
  File 
"/tmp/autopkgtest-lxc.jwltu_fs/downtmp/build.Zuz/src/pypandoc/__init__.py", 
line 113, in convert_text
return _convert_input(source, format, 'string', to, extra_args=extra_args,
  File 
"/tmp/autopkgtest-lxc.jwltu_fs/downtmp/build.Zuz/src/pypandoc/__init__.py", 
line 372, in _convert_input
raise RuntimeError(
RuntimeError: Pandoc died with exitcode "97" during conversion: Could not find 
data file data/data/docx/[Content_Types].xml
[...]

  (https://ci.debian.net/packages/p/pypandoc/testing/amd64/)

I don't know if this is just a bug in the pypandoc tests or if it represents
a regression in pypandoc's usability with the new pandoc, or a regression in
pandoc itself.  There is a /usr/share/pandoc/data/docx/[Content_Types].xml
in pandoc-data, perhaps this is a path issue?

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

Bug#1019338: tre: no Homepage field

[Jakub Wilk]

Source: tre
Version: 0.8.0-6
Severity: wishlist

Please add

  Homepage: https://laurikari.net/tre/

to debian/control.

--
Jakub Wilk

Bug#1019337: /usr/share/units/currency.units is a broken symlink

[Jakub Wilk]

Package: units
Version: 2.22-1
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

$ file /usr/share/units/currency.units
/usr/share/units/currency.units: broken symbolic link to 
/build/units-OeD46Z/units-2.22/debian/units/var/lib/units/currency.units


-- System Information:
Architecture: i386

Versions of packages units depends on:
ii  libc6 2.34-7
ii  libreadline8  8.2~rc2-2

Versions of packages units recommends:
ii  python3   3.10.6-1
ii  python3-requests  2.27.1+dfsg-1

--
Jakub Wilk

Bug#1019336: cargo: Cargo wrapper script adds additional '--target' command line parameter

[Claudius Heine]

Package: cargo
Version: 0.57.0-7+b1
Severity: normal

Dear Maintainer,

Short description:

This bug mostly boils down to a incompatibility of the cargo wrapper script and
external build tools, that call the wrapper script. Which causes `cargo` to be
called with two identical `--target` command line parameters, one from the
external build tool, and one from the wrapper script. This causes the build to
fail with:

error: specifying multiple `--target` flags requires `-Zmultitarget`

Long description:

Some software project that have Rust code embedded into them use third-party
build tools, like for instance with Python `setuptools-rust`. Those ordinarily
just call `cargo` with some command line parameters to build the Rust code.

The `/usr/share/cargo/bin/cargo` script is a wrapper script, that simplifies
packaging of Rust software for Debian and takes care about creating and using
local Rust software registries. So that all Rust dependencies come from Debian
packages instead directly from crates.io. The wrapper scripts configures the
build environment and then calls `cargo` with some additional command line
parameters to build the Rust code.

Combining those two software pieces would mean that `setuptools-rust` calls the
wrapper script instead of cargo directly. Because `setuptools-rust` is part of a
bigger build process that processes other code, like in this case Python code,
in addition to just the Rust part.

Because the cargo wrapper script adds the `--target $DEB_HOST_RUST_TYPE` to its
call to `cargo`, `cargo` generates the binaries to different paths and
`setuptools-rust` will no longer find them.

If `setuptools-rust` is configured with the same rust target, so that in
searches for the right path for those binaries, it adds a `--target` parameter
as well. In that case the wrapper script is called with a `--target` parameter,
which it just hands of to cargo, but it also adds its own `--target`
parameter. Now cargo is called with two `--target` parameters, and it complains
about those with the error:

error: specifying multiple `--target` flags requires `-Zmultitarget`

Expected outcome:

The cargo wrapper script should be as transparent as possible, there are a
couple of options to resolve this:

 - If the cargo wrapper script is called without `--target` parameters, the
   path where the binaries are generated to, should be the same as if `cargo` is
   called without `--target` parameter.
   I think this would be a proper solution, however it would break backwards
   compatibility
 - If the cargo wrapper script is called with a `--target` parameter, it should
   check whether the target is the same, an discard one, or complain if they are
   different.
   This would require that build tools like `setuptools-rust` need to support
   defining rust targets on there own, and know where to look for the binaries
   if both cases, but the fix would be backwards compatible, because it only
   fixes the issue if the wrapper script is called with a `--target` parameter,
   which currently just fails.

regards,
Claudius

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cargo depends on:
ii  binutils   2.38.90.20220713-2
ii  clang  1:14.0-55.1
ii  clang-13 [c-compiler]  1:13.0.1-7
ii  clang-14 [c-compiler]  1:14.0.6-2
ii  gcc [c-compiler]   4:12.1.0-3
ii  gcc-10 [c-compiler]10.4.0-4
ii  gcc-11 [c-compiler]11.3.0-5
ii  gcc-12 [c-compiler]12.2.0-1
ii  gcc-9 [c-compiler] 9.5.0-2
ii  libc6  2.34-7
ii  libcurl3-gnutls7.84.0-2
ii  libgcc-s1  12.2.0-1
ii  libgit2-1.31.3.0+dfsg.1-3
ii  libssh2-1  1.10.0-3+b1
ii  libssl33.0.5-2
ii  rustc  1.59.0+dfsg1-2
ii  zlib1g 1:1.2.11.dfsg-4.1

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  
ii  python33.10.6-1

-- no debconf information

Bug#1019335: Reconsider the egrep and fgrep deprecation

[Christoph Berg]

Package: grep
Version: 3.8-1
Severity: normal

Hi,

I see egrep and fgrep have started throwing deprecation warnings:

$ egrep
egrep: warning: egrep is obsolescent; using grep -E

I understand that they have been dubbed deprecated for quite a while:
(manpage of an older grep version)

   In  addition,  the  variant  programs egrep, fgrep and rgrep are
   the same as grep -E, grep -F, and grep -r, respectively.  These
   variants are deprecated, but are provided for backward
   compatibility.

This deprecation will need a LOT of effort to weed out in probably
1000s of packages, while in practise we'll likely never be able to
really remove them from the package since users will expect egrep and
fgrep to be present on any normal unix system, both for interactive
use and to be able to execute 3rd party sh scripts.

I suggest removing the deprecation notices, and keep egrep and fgrep
around indefinitely.

(On a side node, the deprecation notice quoted above also mentions
"rgrep", which is no longer mentioned in the manpage, but it's still
there in the package, not throwing a deprecation warning.)

Christoph

Bug#1019334: Webkit2gtk - Bug Report

[Henning Sprang]

Package: webkit2gtk

Version: 2.36.7-1~deb11u1

Hello,

Since I have made the upgrade as described in details below in the apt
history, invlolving multiple binary üackages from the here mentioned source
üackage, I have massive problems with Webbrowsers constantly crashing as
soon as I do anything serious on webpages with JavaSCript in them. It's
basically impossible to continuously work with such browser based
applications for 15min in a row.

I first thought it could be a gnome-shell issue because I have also log
output about problems with gnome-shell when the error happens, but the
occurrence of the problem appears since the update described below, and
there is no update of gnome shell to be seen in recent apt history.

This is happening in a virtualbox vm, I already took care to update all
libraries on the host and reinstall the most current and matching guest
additions package in the Debian guest  VM.


I can reproduce the problem by:

* starting a Browser (same effect no matter if it's firefox-esr, chromium
or chrome, others not yet tested)

* start using a JavaSCript-heavy web application, like Mattermost, Jira,
Confluence

* after some actions - things that you "normally" do in these apps like
looking at documentation pages, reading chat messages, looking at or
editing bug tickets, I experience either gnome-shell unwillingly restart,
and the browser crashing and showing it's crash reporting window


Sorry if this bug report does not adhere to all rules that it should - I
had trouble to find out what I really need to put into from the debian docs
and wiki pages that try to explain it, and wasn't able to understand
reportbug's usage properly. But I want to get this information to you so it
might help improving Debian.

Please ask me if there is any missing information I should add to make this
report really helpful.


The apt history log:


Start-Date: 2022-09-02  17:12:38
Commandline: packagekit role='update-packages'
Install: libxnvctrl0:amd64 (470.103.01-1~deb11u1)
Upgrade: chromium-sandbox:amd64 (104.0.5112.101-1~deb11u1,
105.0.5195.52-1~deb11u1), google-chrome-stable:amd64 (104.0.5112.101-1,
105.0.5195.52-1), gir1.2-javascriptcoregtk-4.0:amd64 (2.36.6-1~deb11u1,
2.36.7-1~deb11u1), gir1.2-webkit2-4.0:amd64 (2.36.6-1~deb11u1,
2.36.7-1~deb11u1), chromium:amd64 (104.0.5112.101-1~deb11u1,
105.0.5195.52-1~deb11u1), libjavascriptcoregtk-4.0-18:amd64
(2.36.6-1~deb11u1, 2.36.7-1~deb11u1), chromium-common:amd64
(104.0.5112.101-1~deb11u1, 105.0.5195.52-1~deb11u1),
libwebkit2gtk-4.0-37:amd64 (2.36.6-1~deb11u1, 2.36.7-1~deb11u1),
zlib1g:amd64 (1:1.2.11.dfsg-2+deb11u1, 1:1.2.11.dfsg-2+deb11u2)
End-Date: 2022-09-02  17:13:09



The journactl ouput that appears to happen at the same time when the
problems occur:


Sep 07 15:29:15 mycomputer ibus-daemon[2709]: GChildWatchSource: Exit
status of a child process was requested but ECHILD was received by
waitpid(). See the documentation of g_child_watch_source_new() for possible
causes.
Sep 07 15:29:15 mycomputer systemd[1074]: org.gnome.Shell@x11.service: Main
process exited, code=killed, status=11/SEGV
Sep 07 15:29:15 mycomputer systemd[1074]: org.gnome.Shell@x11.service:
Failed with result 'signal'.
Sep 07 15:29:15 mycomputer systemd[1074]: org.gnome.Shell@x11.service:
Consumed 33.557s CPU time.
Sep 07 15:29:15 mycomputer systemd[1074]: org.gnome.Shell@x11.service:
Scheduled restart job, restart counter is at 4.
Sep 07 15:29:15 mycomputer systemd[1074]: Stopped GNOME Shell on X11.
Sep 07 15:29:15 mycomputer systemd[1074]: org.gnome.Shell@x11.service:
Consumed 33.557s CPU time.
Sep 07 15:29:15 mycomputer systemd[1074]: Starting GNOME Shell on X11...
Sep 07 15:29:15 mycomputer gnome-shell[3059]: Failed to use stored monitor
configuration: Invalid mode 3840x1820 (59.96) for monitor 'unknown
unknown'
Sep 07 15:29:15 mycomputer gsd-media-keys[1483]: Failed to grab
accelerators: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such
interface “org.gnome.Shell” on object at path /org/gnome/Shell
Sep 07 15:29:16 mycomputer gnome-shell[3059]: Getting parental controls for
user 1001
Sep 07 15:29:16 mycomputer gsd-media-keys[1483]: Failed to grab
accelerators: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such
interface “org.gnome.Shell” on object at path /org/gnome/Shell
Sep 07 15:29:16 mycomputer gnome-shell[3059]: Called
enable_unredirect_for_display while unredirection is enabled.
Sep 07 15:29:16 mycomputer dbus-daemon[1094]: [session uid=1001 pid=1094]
Activating service name='org.freedesktop.portal.IBus' requested by ':1.116'
(uid=1001 pid=3136 comm="ibus-daemon --panel disable --xim ")
Sep 07 15:29:16 mycomputer dbus-daemon[1094]: [session uid=1001 pid=1094]
Successfully activated service 'org.freedesktop.portal.IBus'
Sep 07 15:29:17 mycomputer gnome-shell[3059]: Telepathy is not available,
chat integration will be disabled.
Sep 07 15:29:17 mycomputer gnome-shell[3059]: Warning: Hiding app because
parental controls not yet initialised: 

Bug#1019333: cadabra2: FTBFS with pkgconf

[Andrej Shadura]

Control: retitle -1 cadabra2: FTBFS due to a missing header

On Wed, 7 Sep 2022, at 16:13, Andrej Shadura wrote:
> While rebuilding your package, it failed to build from the source
> due to the following error:

While this package *also* failed to build with pkgconf, I must note that this 
was a mistake in the Subject field — it fails to build with pkg-config as well.

-- 
Cheers,
  Andrej

Bug#1003397:

[Daichi Fukui]

Hello Iwamatsu-san,

I have drafted a source package for debugbreak.
Kindly find the URL below for the latest source package (Upload #3).
https://mentors.debian.net/package/debugbreak/

I would appreciate it if you review the source package.

Best,
Fukui

On Mon, 5 Sep 2022 09:17:48 +0900 Nobuhiro Iwamatsu 
wrote:
> Hi Daichi,
>
> 2022年9月3日(土) 15:22 Daichi Fukui :
> >
> > Hello Iwamatsu-san,
> >
> > I have drafted a source package of debugbreak.
> > I'm doing this because c4core, which you mentioned before, depends on
this software.
> > Kindly find URLs for the ITP below.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017846
> > https://mentors.debian.net/package/debugbreak/
> >
> > I would appreciate it if you review the source package.
>
> This contains a Python script.
>   /usr/share/debugbreak/gdb/debugbreak-gdb.py
>
> I recommend that you specify gdb for Sugguest.
>
> Best regards,
>   Nobuhiro
>
>
> >
> > Best,
> > Fukui
> >
> > On Sat, 13 Aug 2022 22:12:35 +0900
*－－－*
福意 大智

Daichi Fukui

a.dog.will.talk [at] akane.waseda.jp
*－－－*
 wrote:
> > > Hi Iwamatsu-san,
> > >
> > > > First, This is emedded with C4CORE.
> > > > Do you have any plans to package this?
> > > >   https://github.com/biojppm/c4core
> > >
> > > I filed an ITP for c4core. For details, take a look at the following.
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017088
> > >
> > > Let's continue discussion about packaging c4core there.
> > >
> > > Best,
> > > Fukui
> > >
> > > On Mon, 25 Jul 2022 06:58:22 +0900 Nobuhiro Iwamatsu <
iwama...@nigauri.org>
> > > wrote:
> > > > Hi Daichi,
> > > >
> > > > I reviewed your package.
> > > >
> > > > First, This is emedded with C4CORE.
> > > > Do you have any plans to package this?
> > > >   https://github.com/biojppm/c4core
> > > >
> > > > debain/control:
> > > >   development package is required., because this is a library.
> > > >
> > > > debian/patches:
> > > >   Currently, this package does not have any patches. so this can
delete.
> > > >
> > > > Best regards,
> > > >   Nobuhiro

Bug#1019320: openvpn: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Hi!

On Wed, 2022-09-07 at 12:25:02 +0200, Guillem Jover wrote:
> Source: openvpn
> Source-Version: 2.6.0~git20220818-1
> Severity: normal

> With the recent grep 2.8 release, egrep usage, which has been slated
> for removal for a long time, now generates warnings, such as:
> 
>   egrep: warning: egrep is obsolescent; using grep -E
> 
> When checking the /etc on my systems, I noticed openvpn uses egrep
> at least on its init script (checking the source it also does on its
> test suite).

If reporting upstream or fixing locally, please also notice the fgrep
usage in the test suite.

Thanks,
Guillem

Bug#1019153: php-horde-turba: fatal error: $name must be a string

[s...@uni-paderborn.de (Cyrus)]

Apparently in
/usr/share/horde/turba/lib/Driver/Share.php:47
the change from create to createFromConfig is missing.

If changed manually it seems to work like intended

Regards,
Sebastian

Bug#1019330: dkms: please replace obsolescent egrep by grep -E

[Vincent Lefevre]

Package: dkms
Version: 3.0.3-4
Severity: normal

In the grep 3.8 NEWS file:

  The egrep and fgrep commands, which have been deprecated since
  release 2.5.3 (2007), now warn that they are obsolescent and should
  be replaced by grep -E and grep -F.

The /usr/sbin/dkms script contains

if ! find $dkms_tree/$module/$module_version/* -maxdepth 0 -type d 
2>/dev/null | egrep -qv "(build|tarball|driver_disk|rpm|deb|source)$"; then

which triggers the warning

egrep: warning: egrep is obsolescent; using grep -E

when removing a kernel.

-- 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')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-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

Versions of packages dkms depends on:
ii  build-essential 12.9
ii  clang-10 [c-compiler]   1:10.0.1-8+b1
ii  clang-11 [c-compiler]   1:11.1.0-6+b2
ii  clang-12 [c-compiler]   1:12.0.1-21
ii  clang-13 [c-compiler]   1:13.0.1-7
ii  clang-14 [c-compiler]   1:14.0.6-2
ii  clang-3.6 [c-compiler]  1:3.6.2-3
ii  clang-3.7 [c-compiler]  1:3.7.1-3+b2
ii  clang-6.0 [c-compiler]  1:6.0.1-14.1
ii  clang-7 [c-compiler]1:7.0.1-12
ii  clang-8 [c-compiler]1:8.0.1-10+b1
ii  clang-9 [c-compiler]1:9.0.1-20+b1
ii  dctrl-tools 2.24-3+b1
ii  dh-dkms 3.0.3-4
ii  dpkg-dev1.21.9
ii  gcc [c-compiler]4:12.2.0-1
ii  gcc-10 [c-compiler] 10.4.0-5
ii  gcc-11 [c-compiler] 11.3.0-6
ii  gcc-12 [c-compiler] 12.2.0-1
ii  gcc-4.8 [c-compiler]4.8.5-4
ii  gcc-4.9 [c-compiler]4.9.4-2
ii  gcc-5 [c-compiler]  5.5.0-12
ii  gcc-6 [c-compiler]  6.5.0-2
ii  gcc-8 [c-compiler]  8.4.0-7
ii  gcc-9 [c-compiler]  9.5.0-2
ii  kmod30+20220630-3
ii  lsb-release 11.2
ii  make4.3-4.1
ii  patch   2.7.6-7
ii  tcc [c-compiler]0.9.27+git20200814.62c30a4a-1

Versions of packages dkms recommends:
ii  fakeroot 1.29-1
ii  linux-headers-amd64 [linux-headers-generic]  5.19.6-1
ii  sudo 1.9.11p3-1

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.5-2
ii  menu   2.1.49

-- Configuration Files:
/etc/dkms/framework.conf changed:
verbose="1"
autoinstall_all_kernels="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#1019328: debian-goodies: please replace obsolescent egrep / fgrep by grep -E / grep -F

[Axel Beckert]

Control: tag -1 + confirmed

Hi Vincent,

Vincent Lefevre wrote:
> In the grep 3.8 NEWS file:
> 
>   The egrep and fgrep commands, which have been deprecated since
>   release 2.5.3 (2007), now warn that they are obsolescent and should
>   be replaced by grep -E and grep -F.

Yeah, unfortunately. IMHO a very bad decision. This will cause as much
havoc as the removal/deprecation of which brought. Luckily that one
has been force-reverted by the TC.

> They occur in checkrestart.8 (man page), dglob, dgrep and dgrep.pod,
> dman and which-pkg-broke-build.

Thanks for the analysis.

Oh, and JFTR: degrep, dfgrep, dzegrep and dzfgrep will not be
deprecated and continue to work.

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

Bug#1019259: devscripts: The command uscan with the option 'dehs' doesn't always generate valid XML ouput

[Yadd]

On 07/09/2022 11:44, Raphael Hertzog wrote:

Control: tags -1 - moreinfo

Hello Yadd,

Please keep the bug submitter on copy, otherwise you can't expect to get
replies.

Le mardi 06 septembre 2022, Yadd a écrit :

uscan generates a valid XML on STDOUT and displays messages on STDERR. Use
`uscan --dehs 2>/dev/null`


That was my expectation also but I double checked and it doesn't display
messages on STDERR:

┏t14-buxy:~/deb/pkg/zim (master)
┗(freexian,534)$ uscan --dehs --upstream-version 0.74 >/dev/null
┏t14-buxy:~/deb/pkg/zim (master)
┗(freexian,535)$ uscan --dehs --upstream-version 0.74 2>/dev/null

uscan: Newest version of zim on remote site is 0.74.3, local version is 0.74
uscan:  => Newer package available from:
 => https://zim-wiki.org/downloads/zim-0.74.3.tar.gz
Leaving ../zim_0.74.3.orig.tar.gz where it is.
zim
0.74
0.74
0.74.3
https://zim-wiki.org/downloads/zim-0.74.3.tar.gz
newer package available
zim_0.74.3.orig.tar.gz
../zim_0.74.3.orig.tar.gz
Not downloading, using existing file: zim-0.74.3.tar.gz




Cheers,


Found, thanks!

https://salsa.debian.org/debian/devscripts/-/merge_requests/279

Bug#1019329: apt-file: please replace obsolescent fgrep by grep -F

[Vincent Lefevre]

Package: apt-file
Version: 3.2.2
Severity: normal

In the grep 3.8 NEWS file:

  The egrep and fgrep commands, which have been deprecated since
  release 2.5.3 (2007), now warn that they are obsolescent and should
  be replaced by grep -E and grep -F.

I currently get:

cventin:~> apt-file search some-file
Searching through filenames ...fgrep: warning: fgrep is obsolescent; using grep 
-F

-- 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')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-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

Versions of packages apt-file depends on:
ii  apt  2.5.2
ii  libapt-pkg-perl  0.1.40+b1
ii  liblist-moreutils-perl   0.430-2
ii  libregexp-assemble-perl  0.38-1
ii  perl 5.34.0-5

apt-file recommends no packages.

apt-file suggests no packages.

-- no debconf information

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

Bug#1019328: debian-goodies: please replace obsolescent egrep / fgrep by grep -E / grep -F

[Vincent Lefevre]

Package: debian-goodies
Version: 0.88
Severity: normal

In the grep 3.8 NEWS file:

  The egrep and fgrep commands, which have been deprecated since
  release 2.5.3 (2007), now warn that they are obsolescent and should
  be replaced by grep -E and grep -F.

They occur in checkrestart.8 (man page), dglob, dgrep and dgrep.pod,
dman and which-pkg-broke-build.

-- 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')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-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

debian-goodies depends on no packages.

Versions of packages debian-goodies recommends:
ii  apt2.5.2
ii  curl   7.85.0-1
ii  dctrl-tools2.24-3+b1
ii  dialog 1.3-20211214-1
ii  elfutils   0.187-2
ii  equivs 2.3.1
ii  libfile-slurper-perl   0.013-1
ii  libfile-which-perl 1.27-1
ii  libipc-system-simple-perl  1.30-1
ii  man-db 2.10.2-3
ii  perl   5.34.0-5
ii  popularity-contest 1.74
ii  procps 2:3.3.17-7+b1
ii  python33.10.6-1
ii  sensible-utils 0.0.17
ii  whiptail   0.52.21-5+b2
ii  zenity 3.43.0-1

Versions of packages debian-goodies suggests:
ii  apt-file   3.2.2
pn  ccze   
pn  debsums
ii  elinks [www-browser]   0.13.2-1+b3
ii  firefox [www-browser]  104.0-1
hi  firefox-esr [www-browser]  52.9.0esr-1~deb9u1
pn  konqueror  
ii  links [www-browser]2.27-1+b1
ii  links2 [www-browser]   2.27-1+b1
ii  lsb-release11.2
ii  lsof   4.95.0-1
ii  lynx [www-browser] 2.9.0dev.10-1
ii  openssh-client 1:9.0p1-1+b1
ii  sudo   1.9.11p3-1
ii  w3m [www-browser]  0.5.3+git20220429-1+b1
ii  xdg-utils  1.1.3-4.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#1019322: pcscd: Prints warnings due to obsolescent egrep usage

[Ludovic Rousseau]

Le 07/09/2022 à 12:34, Guillem Jover a écrit :

Package: pcscd
Version: 1.9.8-1
Severity: normal

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

   egrep: warning: egrep is obsolescent; using grep -E

When checking the /etc on my systems, I noticed pcscd uses egrep
at least on its init script (checking the source seems that's the only
relevant instance).


Fixed in 
https://salsa.debian.org/debian/pcsc-lite/-/commit/9759a1c84b5639e3a15bc972f19e79e1b773abf1

I will try to release and push a new upstream release soon.

Thanks

--
Dr. Ludovic Rousseau

Bug#1019300: mp3guessenc: autopkgtests failure with grep 3.8: fgrep is deprecated

[Peter B]

On 07/09/2022 07:22, Pino Toscano wrote:

Source: mp3guessenc
Version: 0.27.5+dfsg.1-1
Severity: serious
Tags: patch
Justification: breaks autopkgtests

Hi,

GNU grep 3.8 officially deprecates egrep and fgrep, and those two
commands now issue a deprecation message on stderr [1].

The autopkgtests of mp3guessenc use fgrep, and while they still work
fine, the extra messages on stderr are considered by default a failure,
and thus the tests are marked as such. While autopkgtest has a
"allow-stderr" restriction to not consider stderr output as failure in
case it is expected, I think the better solution here is simply to
switch away from fgrep to grep -F. This works fine with grep 3.8 and
any older version.

Patch attached for this.

[1] https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html

Thanks,


Thanks for the patch.

I've uploaded a fixed version to Mentors.
https://mentors.debian.net/package/mp3guessenc/



Cheers,
Peter

Bug#1019326: ucf: grep warning "stray \ before /" due to incorrect use of perl's \Q...\E

[Vincent Lefevre]

Package: ucf
Version: 3.0043
Severity: important

While setting up mercurial (postinst script), I got severals of
the following warning:

grep: warning: stray \ before /

They come from

  safe_dest_file=$(echo "$dest_file" | perl -nle 'print "\Q$_\E\n"')

For instance,

  echo ab/cd | perl -nle 'print "\Q$_\E\n"'

outputs "ab\/cd". \Q...\E is designed for reuse by Perl, not for grep.

In the NEWS file for grep 3.8:

  Regular expressions with stray backslashes now cause warnings, as
  their unspecified behavior can lead to unexpected results.

-- 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')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-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

Versions of packages ucf depends on:
ii  coreutils   8.32-4.1
ii  debconf 1.5.79
ii  sensible-utils  0.0.17

ucf recommends no packages.

ucf suggests no packages.

-- debconf information:
  ucf/conflicts_found:
  ucf/changeprompt: keep_current
* ucf/show_diff:
* ucf/changeprompt_threeway: merge_threeway
  ucf/title:

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

Bug#1019324: ucf: please replace obsolescent egrep by grep -E

[Vincent Lefevre]

Package: ucf
Version: 3.0043
Severity: important

While setting up mercurial (postinst script), I got severals of
the following warning:

egrep: warning: egrep is obsolescent; using grep -E

Indeed, egrep has been deprecated since 2007, and, as of grep 3.8,
it is obsolescent. It may be removed in the future (which would
break the scripts) and should be replaced by "grep -E".

-- 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')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-4-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

Versions of packages ucf depends on:
ii  coreutils   8.32-4.1
ii  debconf 1.5.79
ii  sensible-utils  0.0.17

ucf recommends no packages.

ucf suggests no packages.

-- debconf information:
* ucf/changeprompt_threeway: merge_threeway
  ucf/conflicts_found:
  ucf/changeprompt: keep_current
  ucf/title:
* ucf/show_diff:

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

Bug#1006674: Heap out-of-bounds write vulnerability in Agentxtrap

[Craig Small]

Hi,
  Im not seeing this issue at all in 5.9.3

cat crash-79988d8886068ffd86a3f3efc90d420f5284c45f | xargs agentxtrap
1: Bad value notation (bs)
$ agentxtrap -V
NET-SNMP version: 5.9.3


>

Bug#766595: gnome-shell memory leak

[Christophe TROESTLER]

I run gnome-shell 42.4-1+b1 (Wayland, only extensions are Caffeine, topIcons 
Plus and Window List) and it seems to still have a memory leak.  It started at 
about 150MB and is now at more than 400MB and counting.

Bug#1018880: dbus-user-session: GNOME applications such as evince and nautilus start with a 25-second delay via ssh

[Simon McVittie]

Control: retitle -1 under ssh X11 forwarding, apps like nautilus that use 
xdg-desktop-portal start with 25s delay
Control: affects -1 + nautilus evince xdg-desktop-portal xdg-desktop-portal-gtk

On Wed, 07 Sep 2022 at 11:35:52 +0200, Vincent Lefevre wrote:
> On 2022-09-07 09:19:26 +0100, Simon McVittie wrote:
> > If you're expecting graphical applications to work "when I connect by
> > ssh", then presumably you're doing *something* that you're not saying
> 
> X11 forwarding.

Thank you, that is the crucial piece of missing context that I needed.

> > In a Debian X11 environment, /etc/X11/Xsession.d/20dbus_xdg-runtime is
> > meant to do something similar for you, so if you are in an X11 environment
> > where that's not working, either something has gone wrong somewhere or
> > your X11 environment is not participating in Debian's system-integration
> > mechanisms.
> 
> But /etc/X11/Xsession.d/20dbus_xdg-runtime isn't run via ssh, AFAIK.

Yes, X11 forwarding is an example of an X11 environment that doesn't
participate in Debian's X11 integration. There has never been a particularly
coherent design for how X11 forwarding should fit into the D-Bus session
bus, or into systemd user sessions.

> > It might help to try to reproduce a minimal version of the same problem
> > in a virtual machine, perhaps starting from one of the Debian Live images.

A minimal reproducer seems to be:

- boot a text-mode session (I used debian-live-11.4.0-amd64-standard.iso)
- sudo apt update
- sudo apt install openssh-server
- sudo systemctl enable --now ssh
- enable a ssh login (ssh-import-id is a useful way to do this quickly)
- sudo apt install nautilus
- (xdg-desktop-portal-gtk is pulled in as a dependency, this is significant)

and from another machine, in a ssh -X session:

- echo $DISPLAY
- nautilus

Expected result: nautilus starts quickly.

Actual result: it takes a while.

Looking at the systemd journal, I think the problem here is the interaction
between xdg-desktop-portal, its desktop-specific implementation (in this
case xdg-desktop-portal-gtk), and X11 forwarding:

> Sep 07 10:19:22 debian dbus-daemon[5956]: [session uid=1000 pid=5956] 
> Activating via systemd: service name='org.freedesktop.portal.Desktop' 
> unit='xdg-desktop-portal.service' requested by ':1.1' (uid=1000 pid=5954 
> comm="nautilus ")
> Sep 07 10:19:22 debian systemd[1201]: Starting Portal service...
...
> Sep 07 10:19:22 debian dbus-daemon[5956]: [session uid=1000 pid=5956] 
> Activating via systemd: service 
> name='org.freedesktop.impl.portal.desktop.gtk' 
> unit='xdg-desktop-portal-gtk.service' requested by ':1.8' (uid=1000 pid=6015 
> comm="/usr/libexec/xdg-desktop-portal ")
> Sep 07 10:19:22 debian systemd[1201]: Starting Portal service (GTK+/GNOME 
> implementation)...
> Sep 07 10:19:22 debian xdg-desktop-portal-gtk[6031]: Unable to init server: 
> Could not connect: Connection refused
> Sep 07 10:19:22 debian xdg-desktop-por[6031]: cannot open display:
> Sep 07 10:19:22 debian systemd[1201]: xdg-desktop-portal-gtk.service: Main 
> process exited, code=exited, status=1/FAILURE
> Sep 07 10:19:22 debian systemd[1201]: xdg-desktop-portal-gtk.service: Failed 
> with result 'exit-code'.
> Sep 07 10:19:22 debian systemd[1201]: Failed to start Portal service 
> (GTK+/GNOME implementation).

Immediately after that failure, there is a 25 second gap in the message
timestamps, and then nautilus starts doing other setup:

> Sep 07 10:19:47 debian dbus-daemon[5956]: [session uid=1000 pid=5956] 
> Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' 
> unit='gvfs-udisks2-volume-monitor.service' requested by ':1.1' (uid=1000 
> pid=5954 comm="nautilus ")

Part of the root cause here is that xdg-desktop-portal-gtk is a systemd
user-service that cannot work without either an X11 or Wayland display
(its purpose is to show prompts when a sandboxed application wants to
do something that needs your permission); but during X11 forwarding,
no component is responsible for telling systemd --user where user-services
can find your X11 display, so xdg-desktop-portal-gtk fails to start.

Because X11 forwarding isn't part of the integrated system involving
x11-common, there's no good component to be responsible for that.
A ssh login session probably should *not* be doing this automatically,
because in your specific case (X11 forwarding with no local GUI),
it would be beneficial to tell systemd --user about your DISPLAY, but
in a more typical desktop use-case (local Wayland or X11), it would
be harmful to do that (because it would make parts of the overall GUI
unexpectedly pop up on the forwarded X11 display instead of locally,
until the forwarded display disconnects, at which point those parts of
the GUI would just not work at all).

Another problem here is that when xdg-desktop-portal-gtk fails and exits
unsuccessfully, that information is getting lost somewhere in the chain
of communication between nautilus, xdg-desktop-portal, dbus-daemon and
systemd 

Bug#1019323: ros-rosdep: FTBFS E275 missing whitespace after keyword

[Emanuele Rocca]

Source: ros-rosdep
Version: 0.22.1-1
Severity: serious
Justification: FTBFS
Tags: sid ftbfs

Hi,

ros-rosdep fails to build with the flake8 version currently in sid.

The relevant part of a failed build follows:

1 E275 missing whitespace after keyword
- Captured stderr call -
/build/ros-rosdep-0.22.1/.pybuild/cpython3_3.10/build/test/test_rosdep_source.py:191:15:
 E275 missing whitespace
 after keyword
assert not(commands)
  ^
flake8 reported 1 errors

Bug#1019196: pd-flext-dev: externals crash on armhf

[Debian/GNU]

Package: pd-flext-dev
Version: 0.6.2-1
Followup-For: Bug #1019196

This is an upstream bug: https://github.com/g/flext/issues/50


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

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

Versions of packages pd-flext-dev depends on:
ii  libflext-pd0  0.6.2-1
ii  puredata-dev  0.52.2+ds0-1

Versions of packages pd-flext-dev recommends:
ii  pd-flext-doc0.6.2-1
ii  pd-lib-builder  0.6.0-2
ii  pkg-config  0.29.2-1

pd-flext-dev suggests no packages.

-- no debconf information

Bug#1019322: pcscd: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Package: pcscd
Version: 1.9.8-1
Severity: normal

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

  egrep: warning: egrep is obsolescent; using grep -E

When checking the /etc on my systems, I noticed pcscd uses egrep
at least on its init script (checking the source seems that's the only
relevant instance).

Thanks,
Guillem

Bug#1018011: reportbug-gtk: please add a close button

[IOhannes m zmoelnig]

y
On Wed, 24 Aug 2022 09:07:53 +0200 Nicolas Patrois 
 wrote:


When I just want to see if a bug has already been reported, I can’t close the
GTK window with a close button (call it escape, abort…), in the top bar or
elsewhere.


speaking of "Escape": hitting the Esc key pops up a dialog that asks
whether I really want to quit Reportbug.
At least for me (using xfce4 as the DE)

that's probably what you want :-)

alternatively, i can use the ordinary "Close Window" shortcut (Alt+F4),
which doesn't ask any questions.


there are two caveats to this though:
- the 'Esc' key doesn't seem to work on the greeting window
- it's non-obvious (unlike a [x] button in the window-decoration) to new 
users.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1019321: budgie-extras: FTBFS: E275 missing whitespace after keyword

[Emanuele Rocca]

Source: budgie-extras
Version: 1.4.90-2
Severity: serious
Justification: FTBFS
Tags: sid ftbfs patch

Hi,

budgie-extras fails to build due to a pep8 error with pycodestyle
2.9.1-1 (currently in sid). The attached patch fixes the issue.

See the relevant part of the build logs:

./tools/run-pep8
= pycodestyle = 

checking ./budgie-dropby/copy_flash 

checking ./budgie-dropby/checkonwin 

checking ./budgie-dropby/dropby_tools.py
./budgie-dropby/dropby_tools.py:133:11: E275 missing whitespace after keyword
make[1]: *** [debian/rules:13: override_dh_auto_test] Error 1
make[1]: Leaving directory '/tmp/autopkgtest.MWCN9F/build.gEw/real-tree'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Fix pep8 error: E275 missing whitespace after keyword
Index: budgie-extras-1.4.90/budgie-dropby/dropby_tools.py
===
--- budgie-extras-1.4.90.orig/budgie-dropby/dropby_tools.py
+++ budgie-extras-1.4.90/budgie-dropby/dropby_tools.py
@@ -130,4 +130,4 @@ def get_volumes(allvols):
 devdata["free"] = free
 devdata["volume_path"] = fpath
 relevant.append(devdata)
-return(relevant)
+return (relevant)

Bug#1019320: openvpn: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Source: openvpn
Source-Version: 2.6.0~git20220818-1
Severity: normal

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

  egrep: warning: egrep is obsolescent; using grep -E

When checking the /etc on my systems, I noticed openvpn uses egrep
at least on its init script (checking the source it also does on its
test suite).

Thanks,
Guillem

Bug#1019319: etckeeper: Prints warnings due to obsolescent egrep usage

[Guillem Jover]

Source: etckeeper
Source-Version: 1.18.17-1
Severity: normal
Tags: upstream patch

Hi!

With the recent grep 2.8 release, egrep usage, which has been slated
for removal for a long time, now generates warnings, such as:

  egrep: warning: egrep is obsolescent; using grep -E

This causes unintended output on etckeeper usage. I'm attaching a
patch that should fix those. I've not touched the doc/todo/ items.

Thanks,
Guillem
From b5ba219b124d415af78cb4bb3d17ca2ec199e03c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 7 Sep 2022 12:08:00 +0200
Subject: [PATCH] =?UTF-8?q?Use=20=C2=ABgrep=20-E=C2=BB=20instead=20of=20ob?=
 =?UTF-8?q?solescent=20=C2=ABegrep=C2=BB?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The grep 2.8 release generates warnings when invoking egrep, such as:

  egrep: warning: egrep is obsolescent; using grep -E

as it is slated for removal in a later release.
---
 etckeeper | 4 ++--
 list-installed.d/50list-installed | 2 +-
 post-install.d/50vcs-commit   | 4 ++--
 pre-commit.d/20warn-problem-files | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/etckeeper b/etckeeper
index 0085eee..6de4754 100755
--- a/etckeeper
+++ b/etckeeper
@@ -84,7 +84,7 @@ elif [ "$command" = "pre-apt" ]; then
 	command=pre-install
 fi
 
-if echo "$command" | LANG=C egrep -q '[^-a-z_]'; then
+if echo "$command" | LANG=C grep -E -q '[^-a-z_]'; then
 	echo "etckeeper: invalid command $command" >&2
 	exit 1
 fi
@@ -142,7 +142,7 @@ else
 	# fallback if perl isn't present
 	for script in $ETCKEEPER_CONF_DIR/$command.d/*; do
 		if [ ! -d "$script" -a -x "$script" ]; then
-			echo "$script" | egrep -q "/[-a-zA-Z0-9]+$"
+			echo "$script" | grep -E -q "/[-a-zA-Z0-9]+$"
 			[ $? -eq 0 ] && "$script" "$@"
 		fi
 	done
diff --git a/list-installed.d/50list-installed b/list-installed.d/50list-installed
index 3b2ff6f..0551af4 100755
--- a/list-installed.d/50list-installed
+++ b/list-installed.d/50list-installed
@@ -17,7 +17,7 @@ else
 	# format "package version\n" (or something similar).
 	if [ "$LOWLEVEL_PACKAGE_MANAGER" = dpkg ]; then
 		dpkg-query -W -f '${Status}\t${Package} ${Version} ${Architecture}\n' | \
-			egrep '(ok installed|ok config-files)' | cut -f2,3
+			grep -E '(ok installed|ok config-files)' | cut -f2,3
 	elif [ "$LOWLEVEL_PACKAGE_MANAGER" = rpm ]; then
 		rpm -qa --qf "%|epoch?{%{epoch}}:{0}|:%{name}-%{version}-%{release}.%{arch}\n" | sort
 	elif [ "$LOWLEVEL_PACKAGE_MANAGER" = pacman ]; then
diff --git a/post-install.d/50vcs-commit b/post-install.d/50vcs-commit
index e8fa4fc..11657af 100755
--- a/post-install.d/50vcs-commit
+++ b/post-install.d/50vcs-commit
@@ -66,7 +66,7 @@ if etckeeper unclean; then
 			get_changed_packages | sort | uniq > $pl.found-pkgs
 			if [ -s $pl.found-pkgs ]; then
 sed -i 's/^/^[-+]/;s/$/ /' $pl.found-pkgs
-etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | egrep '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages
+etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' | grep -f $pl.found-pkgs > $pl.found-packages
 if [ -s $pl.found-packages ]; then
 	echo "Packages with configuration changes:"
 	cat $pl.found-packages || true
@@ -74,7 +74,7 @@ if etckeeper unclean; then
 fi
 			fi
 			echo "Package changes:"
-			etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | egrep '^[-+]' || true
+			etckeeper list-installed | diff -U0 $pl.pre-install - | tail -n+4 | grep -E '^[-+]' || true
 		) | etckeeper commit --stdin
 	else
 		etckeeper commit "$(printf "$message")"
diff --git a/pre-commit.d/20warn-problem-files b/pre-commit.d/20warn-problem-files
index 6bd5c2b..43320e4 100755
--- a/pre-commit.d/20warn-problem-files
+++ b/pre-commit.d/20warn-problem-files
@@ -2,7 +2,7 @@
 set -e
 
 exclude_internal () {
-	egrep -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
+	grep -E -v '(^|/)(\.git|\.hg|\.bzr|_darcs)/'
 }
 
 if [ "$VCS" = bzr ] || [ "$VCS" = darcs ]; then
-- 
2.37.2