Bug#1012218: firefox: Firefox 111 was available on Debian riscv64

[Jessica Clarke]

On 21 Mar 2023, at 04:49, Bo YU  wrote:
> 
> Source: firefox
> Followup-For: Bug #1012218
> 
> Hi,
> 
> Now the firefox 111 can be built with patch attached on qemu
> But unfortunately, it is still not able to build real riscv64
> hardware(Unmatched board) due to running out of resources at
> ld pharse.

Is it doing LTO or something? 16 GiB is a lot of memory for the linker
to exhaust, especially for a non-debug build, even accounting for GNU
ld’s inefficiency compared with other linkers. Though presumably it
should build just fine if you add a swap partition, or reduce
parallelism if the problem is linking multiple large binaries at the
same time?

Jess

> The binary package was available on google drive:
> https://drive.google.com/drive/folders/1QR0rbP66Qf0bdukCtmXM98IreoEzRENt
> 
> I hopefully the package can be built on riscv64 hardware as early as
> possible so that the patch can be merged. Sure, I will update it here
> once done.
> 
> I get inspired here Arch linux[0] again, thanks.
> 
> [0]: https://github.com/felixonmars/archriscv-packages/pull/139
> -- 
> Regards,
> --
>  Bo YU
> 
> <0001-support-riscv64.patch>

Bug#1012218: firefox: Firefox 111 was available on Debian riscv64

[Bo YU]

Source: firefox
Followup-For: Bug #1012218

Hi,

Now the firefox 111 can be built with patch attached on qemu
But unfortunately, it is still not able to build real riscv64
hardware(Unmatched board) due to running out of resources at
ld pharse.

The binary package was available on google drive:
https://drive.google.com/drive/folders/1QR0rbP66Qf0bdukCtmXM98IreoEzRENt

I hopefully the package can be built on riscv64 hardware as early as
possible so that the patch can be merged. Sure, I will update it here
once done.

I get inspired here Arch linux[0] again, thanks.

[0]: https://github.com/felixonmars/archriscv-packages/pull/139
-- 
Regards,
--
  Bo YU

From 3311c09e007337343984dd7e24e7ef280de041ff Mon Sep 17 00:00:00 2001
From: Bo YU 
Date: Mon, 20 Mar 2023 21:07:55 +0800
Subject: [PATCH] support riscv64

Signed-off-by: Bo YU 
---
 debian/browser.mozconfig.in | 6 +-
 debian/rules| 4 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/debian/browser.mozconfig.in b/debian/browser.mozconfig.in
index 1836cdbde19..5f7f2b68881 100644
--- a/debian/browser.mozconfig.in
+++ b/debian/browser.mozconfig.in
@@ -30,6 +30,10 @@ ac_add_options --disable-updater
 ac_add_options --with-unsigned-addon-scopes=app,system
 ac_add_options --allow-addon-sideload
 ac_add_options --enable-alsa
-%if DIST == bullseye || DIST == buster || DIST == stretch || DEB_HOST_ARCH == s390x
+%if DIST == bullseye || DIST == buster || DIST == stretch || DEB_HOST_ARCH == s390x || DEB_HOST_ARCH == riscv64
 ac_add_options --without-wasm-sandboxed-libraries
 %endif
+%if DEB_HOST_ARCH == riscv64
+ac_add_options --disable-debug
+ac_add_options --disable-debug-symbols
+%endif
diff --git a/debian/rules b/debian/rules
index d35ca9256af..20ac1f85999 100755
--- a/debian/rules
+++ b/debian/rules
@@ -35,7 +35,9 @@ endef
 $(foreach lib,$(sort $(call uc,$(SYSTEM_LIBS))),$(eval $(call system_lib,$(lib
 
 OFFICIAL_BRANDING := browser/branding/official
-MOZILLA_OFFICIAL := 1
+ifneq (riscv64,$(DEB_HOST_ARCH))
+	MOZILLA_OFFICIAL := 1
+endif
 # ESR, Beta and Releases use the official branding
 ifneq (,$(filter release beta esr%,$(SHORT_SOURCE_CHANNEL)))
 BRANDING ?= $(OFFICIAL_BRANDING)
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1000293: Problems starting jackd: Method RequestRelease is not implemented on interface org.freedesktop.ReserveDevice1

[Robin Gareus]

Hello fellow Debian users,

I wish I had better news for you but at this point in time PipeWire is 
not a replacement for JACK when it comes to pro-audio. Neither in terms 
of reliability, performance or features. It is certainly not something 
to use in a studio with paying customers, or live on stage.


There are still regular issues [1] coming up, configuration is still not 
easily accessible [2], freewheeling does not always work, and 
performance when using many clients is not yet equal to how JACK handles 
context-switches.


JACK is mature and reliable, musicians can trust it live on stage, 
pipewire is still under heavy development and sadly not yet ready for 
prime-time.


On the upside JACK and pipewire can co-exist. When jackd requests a 
device via d-bus, pipewire does (or should) release it.


At this point it is even unclear if JACK will be ever be discontinued. A 
recent discussion at [3] investigates the possibility to run pipewire on 
top of JACK, but that is a different story.


--
robin

PS. I have been involved with development of both JACK, design of 
PipeWire and am developing pro-audio software such as Ardour (I am also 
a Debian user since Potato).


[1] https://discourse.ardour.org/t/ardour-inputs-with-pipewire/108489
[2] 
https://discourse.ardour.org/t/how-does-pipewire-perform-with-ardour/107381/12
[3] 
https://lists.linuxaudio.org/hyperkitty/list/linux-audio-...@lists.linuxaudio.org/thread/I3BSVFO6DU7S2L7ATA7WOSDS7BTS4BPH/



On Sat, 15 Jan 2022 17:14:16 + =?utf-8?Q?Cr=C3=A1udio?= 
 wrote:

Hi Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attention!Hi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments... Thank you for your attention!Hi 
Chris, do you think Pipewire is stable enough for professional audio 
production? I've seen some reports that it fails at important moments... Thank 
you for your attentioHi Chris, do you think Pipewire is stable enough for 
professional audio production? I've seen some reports that it fails at 
important moments... Thank you for your attention!Hi Chris, do you think 
Pipewire is stable enough for professional audio production? I've seen some 
reports that it fails at important moments...

Thank you for your attention!

Cláudio.

‐‐‐ Original Message ‐‐‐
Em quinta-feira, 30 de dezembro de 2021 às 14:03, chris 
 escreveu:

> `pipewire` is providing its own replacement for `jack`, so if you are using 
`pipewire` maybe you should not have `jackd2` installed at all.
>
> I think I've done exactly the following:
>
> ```
>
> aptitude --schedule-only install libspa-0.2-jack qsynth rosegarden; aptitude 
--schedule-only full-upgrade; aptitude install
>
> aptitude purge pulseaudio pulseaudio-module-bluetooth 
pulseaudio-module-gsettings
>
> aptitude purge qjackctl jackd jackd2
> ```
>
> Then, to start an app needing `jack`, I did:
>
> `pw-jack qsynth` (don't forget to add a soundfont in `settups/soudfounts`)
>
> then:
>
> `rosegarden 28316.mid` (you must go in `studio/manage midi devices` and 
select a mdi output)
>
> And it worked.
>
> I'm using unstable.
>
> Right after switching to pipewire, I did:
>
> ```
>
> aptitude install libspa-0.2-bluetooth pipewire-audio-client-libraries
> aptitude purge pipewire-media-session
> aptitude reinstall wireplumber
> ```
>
> Maybe as a user you should do:
>
> ```
>
> systemctl --user --now disable pulseaudio.service pulseaudio.socket
>
> systemctl --user mask pulseaudio
>
> systemctl --user restart pipewire
> ```
>
> Maybe there should be a dependency conflict between `pipewire `and `jackd`?
>
> Also, concerning
>
> https://wiki.debian.org/PipeWire#For_JACK;>
>


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033278: wine: Battle.Net: The application failed to start because no Qt platform plugin could be initialized

[Joseph Nahmias]

Package: wine
Version: 8.0~repack-4
Severity: normal
X-Debbugs-Cc: j...@nahmias.net

Hello,

I just upgraded from bullseye to bookworm and now Battle.Net / Hearthstone
refuses to start. Instead it shows this error message:

The application failed to start because no Qt
platform plugin could be initialized. Reinstalling
the application may fix this problem.

Was there some change in the wine packaging that would cause this error?
Would additional logs/debug info be useful to troubleshoot?

Thanks,
--Joe

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-stable.

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/8 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 wine depends on:
ii  wine32  8.0~repack-4
ii  wine64  8.0~repack-4

wine recommends no packages.

Versions of packages wine suggests:
pn  dosbox
ii  icoextract-thumbnailer [exe-thumbnailer]  0.1.4-1
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
pn  winetricks

Versions of packages libwine depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-8
ii  libcapi20-3  1:3.27-3+b1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libglib2.0-0 2.74.6-1
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgstreamer-plugins-base1.0-0   1.22.0-3
ii  libgstreamer1.0-01.22.0-2
ii  libpcap0.8   1.10.3-1
ii  libpulse016.1+dfsg1-2+b1
ii  libudev1 252.6-1
ii  libunwind8   1.6.2-3
ii  libusb-1.0-0 2:1.0.26-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libz-mingw-w64   1.2.13+dfsg-1
ii  ocl-icd-libopencl1 [libopencl1]  2.3.1-1

Versions of packages libwine recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 8.0~repack-4
ii  gstreamer1.0-plugins-good  1.22.0-5
ii  libasound2-plugins 1.2.7.1-1
ii  libcups2   2.4.2-2
ii  libdbus-1-31.14.6-1
ii  libgl1 1.6.0-1
ii  libgl1-mesa-dri22.3.3-1
ii  libgnutls303.7.9-1
ii  libgssapi-krb5-2   1.20.1-1
ii  libkrb5-3  1.20.1-1
ii  libodbc2   2.3.11-2
ii  libosmesa6 22.3.3-1
ii  libsdl2-2.0-0  2.26.4+dfsg-1
ii  libv4l-0   1.22.1-5+b1
ii  libvulkan1 1.3.239.0-1
ii  libxcomposite1 1:0.4.5-1
ii  libxcursor11:1.2.1-1
ii  libxfixes3 1:6.0.0-2
ii  libxi6 2:1.8-1+b1
ii  libxinerama1   2:1.1.4-3
ii  libxrandr2 2:1.5.2-2+b1
ii  libxrender11:0.9.10-1.1
ii  libxxf86vm11:1.1.4-1+b2

Versions of packages libwine suggests:
ii  cups-bsd   2.4.2-2
ii  gstreamer1.0-libav 1.22.0-2
ii  gstreamer1.0-plugins-bad   1.22.0-4
ii  gstreamer1.0-plugins-ugly  1.22.0-2
pn  ttf-mscorefonts-installer  

Versions of packages wine32 depends on:
ii  libc62.36-8
ii  libwine  8.0~repack-4

wine32 recommends no packages.

Versions of packages wine32 suggests:
pn  wine32-preloader  

Versions of packages wine64 depends on:
ii  libc62.36-8
ii  libwine  8.0~repack-4

Versions of packages wine64 recommends:
ii  wine32  8.0~repack-4

Versions of packages wine64 suggests:
pn  wine64-preloader  

Versions of packages wine is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   8.0~repack-4

-- no debconf information

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Paul Wise]

On Mon, 2023-03-20 at 12:05 +, James Addison wrote:

> That's not a bad idea.  Are there any reasons that that might _not_ be a good
> idea before filing a wishlist bug?  (performance, implications of scanning
> binary packages, ...)

binutils isn't security supported, so using objdump in lintian probably
isn't a good idea, especially since it is run on ftp-master.debian.org.

In addition disassembling binaries is going to have an impact on the
performance of lintian, especially for larger packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1033277: coreutils: new upstream version

[Christoph Anton Mitterer]

Package: coreutils
Version: 9.1-1
Severity: wishlist

Hey.

9.2 is out :-)

Cheers,
Chris.

Bug#1033276: unattended-upgrades: does not create directory for Dir::Cache::archives/partial when it does not exist

[Jay]

Package: unattended-upgrades
Version: 2.9.1+nmu3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

apt.conf contains:

Dir::Cache::archives "/tmp";

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

ineffective:

unattended-upgrades

effective:

mkdir /tmp/partial; unattended-upgrades

   * What was the outcome of this action?

unattended-upgrades give a "No such file or directory" when trying to download 
packages if /tmp/partial does not exist

   * What outcome did you expect instead?

expected unattended-upgrades to create the directory, as `apt upgrade` does


-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'stable'), (875, 'oldstable'), 
(800, 'testing-security'), (800, 'oldoldstable'), (800, 'testing'), (700, 
'oldoldstable'), (700, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-dbus   1.2.16-5
ii  python3-distro-info1.0
ii  ucf3.0043
ii  xz-utils   5.2.5-2.1~deb11u1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-30
ii  cron [cron-daemon]  3.0pl1-137
ii  systemd-sysv247.3-7+deb11u1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-2
pn  needrestart
ii  nullmailer [mail-transport-agent]  1:2.2-3
ii  powermgmt-base 1.36
ii  python3-gi 3.38.0-2

-- Configuration Files:
/etc/logrotate.d/unattended-upgrades changed:
/var/log/unattended-upgrades/unattended-upgrades.log 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
/var/log/unattended-upgrades/unattended-upgrades-shutdown.log
{
  rotate 996
  monthly
  compress
  missingok
  notifempty
}


-- debconf information:
* unattended-upgrades/enable_auto_updates: true

Bug#1033275: RFS: zstd-jni-java/1.5.4-2+ds-1 [Team] -- JNI bindings for Zstd (Architecture-specific files)

[sun min]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "zstd-jni-java":

* Package name : zstd-jni-java
   Version  : 1.5.4-2+ds-1
   Upstream contact : [fill in name and email of upstream]
* URL  : https://github.com/luben/zstd-jni
* License  : BSD-2-clause, BSD-3-clause
* Vcs  : https://salsa.debian.org/java-team/zstd-jni-java
   Section  : java

The source builds the following binary packages:

  libzstd-jni-java - JNI bindings for Zstd (Java files)
  libzstd-jni1 - JNI bindings for Zstd (Architecture-specific files)

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

  https://mentors.debian.net/package/zstd-jni-java/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/z/zstd-jni-java/zstd-jni-java_1.5.4-2+ds-1.dsc

Changes since the last upload:

zstd-jni-java (1.5.4-2+ds-1) unstable; urgency=medium
.
   * Team upload.
   * New upstream release.
   * Update debian/libzstd-jni1.symbols.

Regards,
--
  sun min

Bug#1032706: [pkg-lxc-devel] Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend

[Pierre-Elliott Bécue]

severity 1032706 important
thanks

Hi,

"Sperl, Mario"  wrote on 11/03/2023 at 09:30:06+0100:

> Package: lxc
> Version: 1:5.0.2-1
> Severity: grave
> Justification: causes data loss
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation? I tried to generate a snapshot with 
> lxc-snapshot for a test container that is more than 1G of size. Snapshot 
> generation does not show any problems but the restore does only restore 1G so 
> the container is not able to start after restore.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? One can create a new loop file with correct size and copy 
> the snapshot contents in here but this renders this command absolute useless 
> when using loop backend
>* What was the outcome of this action? Container cannot start 
>* What outcome did you expect instead? A container that does start 
> normally after restoring.

Lowering the severity for multiple reasons:

 1. The data is not lost, only the changes after the latest snapshot
are, as the snapshots are not deleted by a call to restore. The
snapshot is actually a full-fledged lxc directory under snaps, that
you can reuse almost directly. I admit not losing the changes after
the latest snapshot would be better, but I feel that this sole point
is not enough to keep the bug as 'grave';
 2. A snapshot should not be restored inplace, as suggested by the
command's manpage. The -N option is only useful for restoration and
allows one to create a new container based on the snapshot. It's
actually this feature that doesn't work when the rootfs is on a loop
device ;
 3. This bug is tied specifically to a backend little to no user use,
other filesystems seem to produce the proper result. If it comes to
that, I'd rather remove the loop feature than having LXC out of
bookworm.

I'll still try to have a proper upstream solution offer before the release.

-- 
PEB


signature.asc
Description: PGP signature

Bug#1033274: gnome-session: recommends xdg-desktop-portal-gnome and not depends

[Pablo Mazzini]

Package: gnome-session
Severity: normal

gnome-session can work properly without xdg-desktop-portal-gnome.

As per the policy:
Depends: This declares an absolute dependency.
Recommends: This declares a strong, but not absolute, dependency.

Please recommend xdg-desktop-portal-gnome.

The gnome-core meta package already provides this dependency and it may
be appropriate there.

Bug#988597: trash-cli version too old

[Ganton]

Dear Sirs, this issue has been mentioned on 
https://bugs.launchpad.net/ubuntu/+source/trash-cli/+bug/2011289 . Is 
there any news about solving the present problem?

Bug#1033273: unblock: curl/7.88.1-6

[Samuel Henrique]

Package: release.debian.org
Control: affects -1 + src:curl
X-Debbugs-Cc: c...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org
Severity: normal

Please unblock package curl

We have two changes on unstable:
1) Curl's test suite now skips flaky tests and it's critical to the
result of the build:
This means we get a FTBFS if tests fails, considering curl has a very
extensive test-suite (around 1600 tests) and that this will increase
the reliability of our backporting of patches throughout stable,
oldstable and oldoldstable (hello lts/elts), this is very important.

2) Add support to PEM certificates for libcurl3-nss:
When working on having the improved test coverage, we noticed the
possibility to fix this long-standing bug. Users of libcurl3-nss are
now able to load PEM certificates (like from ca-certificates), which
makes it easier to run a safer libcurl with nss.

[ Reason ]
Major improvements to tests and fix of a long-standing bug related to
usage of NSS and PEM certificates.

[ Impact ]
Maintenance of curl will be much more reliable from now on as we have
better test coverage with results which can't be ignored.

[ Tests ]
I've run at least 8 builds of the curl package in our buildd
infrastructure and didn't spot any flaky tests left.
Regarding the NSS + PEM change, curl's extensive unit tests passed.

[ Risks ]
More work and less reliability maintaining curl on trixie (for
backporting patches, for example).

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
I would like 7.88.1-6 to migrate as soon as possible (it has been more
than 10 days already) because I want to push 6 CVE fixes after this
upload. I will also request for the CVE fixes to be unblocked but I
would like this version to migrate first so it happens sooner (trying
to avoid baking this for an extra 20 days).

unblock curl/7.88.1-6

Thank you,

--
Samuel Henrique 


curl_7.88.1-6.debdiff
Description: Binary data

Bug#1033272: ITP: libre-graph-api-cpp-qt-client -- C++/Qt Libre Graph API client

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: Pierre-Elliott Bécue 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libre-graph-api-cpp-qt-client
  Version : 1.0.1
  Upstream Author : Michael Barz 
* URL : https://github.com/owncloud/libre-graph-api-cpp-qt-client
* License : Apache-2.0
  Programming Lang: C++
  Description : C++/Qt client implementation of Libre Graph API

The Libre Graph API is an API for open Cloud Collaboration. It provides
an open source standard for open Cloud Collaboration. See the Libre
Graph Home for more details.

This package is a new dependency on owncloud-client, and will be
maintained in the Next-Owncloud Team.

Bug#1031587: [request-tracker-maintainers] Bug#1031587: Handling of the request-tracker4 -> request-tracker5 transition in bookworm

[Sebastian Ramacher]

Hi Dominic

On 2023-02-27 15:50:05 +, Dominic Hargreaves wrote:
> On Thu, Feb 23, 2023 at 04:54:33PM +0100, Paul Gevers wrote:
> > Control: tags -1 moreinfo
> > 
> > Hi,
> > 
> > On 20-02-2023 13:09, Dominic Hargreaves wrote:
> > > If the release team would be willing to grant an exception to the policy
> > > to get this done, we can get this wrapped up inside a week I expect.
> > 
> > Can you please confirm that everything is ready to do this? I.e. there is no
> > "this should work but we haven't tested it" cases. If yes, then please
> > upload the packages that involve new binaries to experimental and when those
> > are passed NEW, ping this bug. If no surprises pop up, we'll grant an
> > exception, but we want everything fully ready before doing so.
> 
> Thanks, yep. We had planned out this transition and I feel confident
> the rest of it will work out (worst case we need to drop a barely
> used extension package somewhere).
> 
> Andrew and I are working on this at the moment and will ping this bug
> when it's fully staged.

What's the status of this transition?

Cheers
-- 
Sebastian Ramacher

Bug#1033270: RM: sqlite -- RoQA; Obsolete

[Moritz Muehlenhoff]

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

Please remove sqlite. It's an older copy of src:sqlite3
and EOL for a long time (#607969)

Cheers,
Moritz

Bug#1033269: RM: kannel-sqlbox -- RoQA; Unmaintained, RC-buggy, blocks removal of src:sqlite

[Moritz Muehlenhoff]

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

Please remove kannel-sqlbox. The last maintainer upload was in 2018, it's 
removed
from testing since 2020 and it's blocking the removal of src:sqlite (#972128).

Cheers,
Moritz

Bug#1032787: vfu: cat not open file with special characters in it's name

[Vladi Belperchinov-Shabanski]

hi!

fixed in vslib for "|". 
still not sure if there is ever need for "%" but added for now:
(btw, what shell do you use?)

vslib
commit ecdba011eef270083320fadd5e1a0407294fb3b2 (HEAD -> master)
Date:   Mon Mar 20 23:35:15 2023 +0200

thanks!

P! Vladi.

-- 
Vladi Belperchinov-Shabanski  
   
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu


pgpZnXmMk9Vfs.pgp
Description: PGP signature

Bug#1033268: unblock: emacs/1:28.2+1-13

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: em...@packages.debian.org, Sean Whitton 
, j...@debian.org, car...@debian.org
Control: affects -1 + src:emacs

Hi release team members,

Please unblock package emacs

Sean might give some additional input if you need some additional
information. Between 1:28.2+1-10 and 1:28.2+1-13 of emacs, there were
security fixes for CVE-2022-48337, CVE-2022-48338, CVE-2022-48339,
CVE-2023-27985 and CVE-2023-27986.

CVE-2022-48337, CVE-2022-48338 and CVE-2022-48339 were covered as well
in DSA-5360-1 for bullseye.

Can you please unblock emacs/1:28.2+1-13 so we do not have regression
for those fixes from bullseye to bookworm?

(note the -13 entry has a off-by-one typo in one CVE identifier)

Regards,
Salvatore
diff -Nru emacs-28.2+1/debian/.git-dpm emacs-28.2+1/debian/.git-dpm
--- emacs-28.2+1/debian/.git-dpm2023-01-18 01:32:40.0 +0100
+++ emacs-28.2+1/debian/.git-dpm2023-03-14 21:30:28.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-595617abab6964ac0c6e617bae3d82692bf298b9
-595617abab6964ac0c6e617bae3d82692bf298b9
+4e6971c25c27c9a3f34cc69b51db894105362d08
+4e6971c25c27c9a3f34cc69b51db894105362d08
 279b82e64e15b5e2df3cb522636c6db85a8ee659
 279b82e64e15b5e2df3cb522636c6db85a8ee659
 emacs_28.2+1.orig.tar.xz
diff -Nru emacs-28.2+1/debian/changelog emacs-28.2+1/debian/changelog
--- emacs-28.2+1/debian/changelog   2023-01-18 01:32:40.0 +0100
+++ emacs-28.2+1/debian/changelog   2023-03-14 21:30:28.0 +0100
@@ -1,3 +1,24 @@
+emacs (1:28.2+1-13) unstable; urgency=high
+
+  * Cherry-pick upstream fixes for command injection vulnerabilities
+(CVE-2023-27984, CVE-2023-27986) (Closes: #1032538).
+
+ -- Sean Whitton   Tue, 14 Mar 2023 13:30:28 -0700
+
+emacs (1:28.2+1-12) unstable; urgency=medium
+
+  * Fix memory leak in etags.c introduced by recent security fix.
+Thanks to Adrian Bunk for identifying the issue.
+
+ -- Sean Whitton   Thu, 02 Mar 2023 12:21:19 -0700
+
+emacs (1:28.2+1-11) unstable; urgency=high
+
+  * Cherry-pick upstream fixes for command injection vulnerabilities
+(CVE-2022-48337, CVE-2022-48338, CVE-2022-48339) (Closes: #1031730).
+
+ -- Sean Whitton   Wed, 22 Feb 2023 11:01:50 -0700
+
 emacs (1:28.2+1-10) unstable; urgency=medium
 
   * Fix copyright tests for 2023 onwards.  Thanks to Mattias Engdegård for
diff -Nru 
emacs-28.2+1/debian/patches/0020-Fix-htmlfontify.el-command-injection-vulnerability-C.patch
 
emacs-28.2+1/debian/patches/0020-Fix-htmlfontify.el-command-injection-vulnerability-C.patch
--- 
emacs-28.2+1/debian/patches/0020-Fix-htmlfontify.el-command-injection-vulnerability-C.patch
 1970-01-01 01:00:00.0 +0100
+++ 
emacs-28.2+1/debian/patches/0020-Fix-htmlfontify.el-command-injection-vulnerability-C.patch
 2023-03-14 21:30:28.0 +0100
@@ -0,0 +1,33 @@
+From 665489d7de786a61fa0c0883b9dffbc76487e37e Mon Sep 17 00:00:00 2001
+From: Xi Lu 
+Date: Sat, 24 Dec 2022 16:28:54 +0800
+Subject: Fix htmlfontify.el command injection vulnerability (CVE-2022-48339)
+
+This upstream patch has been incorporated to fix the problem:
+
+  Fix htmlfontify.el command injection vulnerability.
+
+  * lisp/htmlfontify.el (hfy-text-p): Fix command injection
+  vulnerability.  (Bug#60295)
+
+Origin: upstream, commit 807d2d5b3a7cd1d0e3f7dd24de22770f54f5ae16
+Bug: https://debbugs.gnu.org/60295
+Bug-Debian: https://bugs.debian.org/1031730
+Forwarded: not-needed
+---
+ lisp/htmlfontify.el | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lisp/htmlfontify.el b/lisp/htmlfontify.el
+index 115f67c9560..f8d1e205369 100644
+--- a/lisp/htmlfontify.el
 b/lisp/htmlfontify.el
+@@ -1882,7 +1882,7 @@ hfy-make-directory
+ 
+ (defun hfy-text-p (srcdir file)
+   "Is SRCDIR/FILE text?  Use `hfy-istext-command' to determine this."
+-  (let* ((cmd (format hfy-istext-command (expand-file-name file srcdir)))
++  (let* ((cmd (format hfy-istext-command (shell-quote-argument 
(expand-file-name file srcdir
+  (rsp (shell-command-to-stringcmd)))
+ (string-match "text" rsp)))
+ 
diff -Nru 
emacs-28.2+1/debian/patches/0021-Fix-ruby-mode.el-command-injection-vulnerability-CVE.patch
 
emacs-28.2+1/debian/patches/0021-Fix-ruby-mode.el-command-injection-vulnerability-CVE.patch
--- 
emacs-28.2+1/debian/patches/0021-Fix-ruby-mode.el-command-injection-vulnerability-CVE.patch
 1970-01-01 01:00:00.0 +0100
+++ 
emacs-28.2+1/debian/patches/0021-Fix-ruby-mode.el-command-injection-vulnerability-CVE.patch
 2023-03-14 21:30:28.0 +0100
@@ -0,0 +1,33 @@
+From 52fb40cf6a3c50c996cff79b0d4f81fc39c7badf Mon Sep 17 00:00:00 2001
+From: Xi Lu 
+Date: Fri, 23 Dec 2022 12:52:48 +0800
+Subject: Fix ruby-mode.el command injection vulnerability (CVE-2022-48338)
+
+This upstream patch has been incorporated to fix the problem:
+
+  Fix ruby-mode.el local command injection vulnerability (bug#60268)
+
+  * 

Bug#1032338: vfu: can not enter directories which names start from empty space

[Vladi Belperchinov-Shabanski]

hi!

fixed:

commit ea096de0dda3910f6d0a3e99f0fde8b5635aa1b8
Date:   Mon Mar 6 09:59:39 2023 +0200


thanks!

P! Vladi.

-- 
Vladi Belperchinov-Shabanski  
   
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu


pgp1ZYUdxS0I6.pgp
Description: PGP signature

Bug#1033198: vfu crashes on new directory creation

[Vladi Belperchinov-Shabanski]

hi!

fixed, with also few other related problems:

commit 900a0100b94ee8b38fab958cbe41b7612e04515b (HEAD -> master)
Date:   Mon Mar 20 23:16:30 2023 +0200

thanks!

P! Vladi.

-- 
Vladi Belperchinov-Shabanski  
   
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu


pgpvFbpsiRcNM.pgp
Description: PGP signature

Bug#1033267: Upload ccache bookworm fix via testing-proposed-updates?

[Joel Rosdahl]

Package: release.debian.org
Severity: normal

[ Short version ]
I prematurely uploaded ccache/4.8-1 to unstable to fix bug #1033191. I would
like to get a more targeted fix into testing instead of that one. Would it be
appropriate to use testing-proposed-updates for this, as suggested on the freeze
policy page?

[ Long version ]
Ccache versions 4.7–4.7.4 by default enable a feature called the inode cache
which shares information between processes via a memory mapped file,
synchronized by pthread mutexes. Yesterday, a user reported that he is seeing
ccache processes hanging on futex calls (related to the inode cache feature) on
GitLab runners with Debian bookworm as well as other distributions using ccache
4.7.4. The inode cache synchronization mechanism was rewritten in ccache 4.8 to
use spin locks, thus taking pthread mutexes out of the equation, so after
reviewing the freeze policy page briefly I uploaded ccache/4.8-1 to improve the
situation since ccache is a non-key package with good autopkgtests.

Except I was wrong: ccache is apparently considered a key package, which I did
not know. Also, in retrospect, I was too stressed and should definitely have
made a more targeted fix.

The user then submitted Debian bug #1033191 with severity serious. I agree that
it would be unfortunate to ship ccache 4.7.4 in bookworm. Unless fixed, builds
using ccache 4.7.4 (maybe in specific container environments such as GitLab
runners with buggy kernels, maybe in other scenarios) risk getting stuck.

For reference, I'm attaching the targeted fix I would like to make.

-- Joel
diff -Nru ccache-4.7.4/LICENSE.adoc ccache-4.7.5/LICENSE.adoc
--- ccache-4.7.4/LICENSE.adoc	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/LICENSE.adoc	2023-03-20 20:47:12.0 +0100
@@ -35,7 +35,7 @@
 
 
 Copyright (C) 2002-2007 Andrew Tridgell
-Copyright (C) 2009-2022 Joel Rosdahl and other contributors
+Copyright (C) 2009-2023 Joel Rosdahl and other contributors
 
 
 
diff -Nru ccache-4.7.4/cmake/CcacheVersion.cmake ccache-4.7.5/cmake/CcacheVersion.cmake
--- ccache-4.7.4/cmake/CcacheVersion.cmake	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/cmake/CcacheVersion.cmake	2023-03-20 20:47:12.0 +0100
@@ -22,7 +22,7 @@
 # CCACHE_VERSION_ORIGIN is set to "archive" in scenario 1 and "git" in scenario
 # 3.
 
-set(version_info "1527040bc2a278b9d3d51badb732ecf5841d8bb5 HEAD, tag: v4.7.4, origin/master, origin/HEAD, master")
+set(version_info "9b1033f3ae534e5aad02c10f663b589b8f28c026 HEAD, tag: v4.7.5, origin/HEAD, origin/4.7-maint, 4.7-maint")
 set(CCACHE_VERSION "unknown")
 
 if(version_info MATCHES "^([0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f])[0-9a-f]* (.*)")
diff -Nru ccache-4.7.4/debian/changelog ccache-4.7.5/debian/changelog
--- ccache-4.7.4/debian/changelog	2022-11-21 20:40:46.0 +0100
+++ ccache-4.7.5/debian/changelog	2023-03-20 21:59:44.0 +0100
@@ -1,3 +1,10 @@
+ccache (4.7.5-1) unstable; urgency=medium
+
+  * New upstream release 4.7.5, whose only change compared with 4.7.4 is
+to disable the inode cache by default (closes: #1033191)
+
+ -- Joel Rosdahl   Mon, 20 Mar 2023 21:59:44 +0100
+
 ccache (4.7.4-1) unstable; urgency=medium
 
   * New upstream release 4.7.4
diff -Nru ccache-4.7.4/doc/MANUAL.adoc ccache-4.7.5/doc/MANUAL.adoc
--- ccache-4.7.4/doc/MANUAL.adoc	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/doc/MANUAL.adoc	2023-03-20 20:47:12.0 +0100
@@ -756,7 +756,7 @@
 
 If true, ccache will cache source file hashes based on device, inode and
 timestamps. This reduces the time spent on hashing include files since the
-result can be resused between compilations. The default is true. The feature
+result can be resused between compilations. The default is false. The feature
 requires <> to be located on a local
 filesystem of a supported type.
 +
diff -Nru ccache-4.7.4/doc/NEWS.adoc ccache-4.7.5/doc/NEWS.adoc
--- ccache-4.7.4/doc/NEWS.adoc	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/doc/NEWS.adoc	2023-03-20 20:47:12.0 +0100
@@ -1,5 +1,16 @@
 = Ccache news
 
+== Ccache 4.7.5
+
+Release date: 2023-03-20
+
+=== Bug fixes
+
+- Disabled the inode cache by default again since there have reports of ccache
+  processes hanging on futex calls related to the inode cache. +
+  [small]#_[contributed by Joel Rosdahl]_#
+
+
 == Ccache 4.7.4
 
 Release date: 2022-11-21
diff -Nru ccache-4.7.4/src/Config.hpp ccache-4.7.5/src/Config.hpp
--- ccache-4.7.4/src/Config.hpp	2022-11-21 19:53:32.0 +0100
+++ ccache-4.7.5/src/Config.hpp	2023-03-20 20:47:12.0 +0100
@@ -1,4 +1,4 @@
-// Copyright (C) 2019-2022 Joel Rosdahl and other contributors
+// Copyright (C) 2019-2023 Joel Rosdahl and other contributors
 //
 // See doc/AUTHORS.adoc for a complete list of contributors.
 //
@@ -181,7 +181,7 @@
   bool m_hash_dir = true;
   std::string m_ignore_headers_in_manifest;
   std::string m_ignore_options;
-  bool m_inode_cache = true;
+  

Bug#1033266: ITP: gnss-share: Share Location Data from GNSS Module

[Chris Talbot]

Package: wnpp
Severity: wishlist
Owner: Chris Talbot 

* Package name: gnss-share
  Version : 6.0
  Upstream Author : postmarketOS
* URL : https://gitlab.com/postmarketOS/gnss-share
* License : GPL 3.0+
  Programming Lang: Go
  Description : Share Location Data from GNSS Module

gnss-share is an app that facilitates sharing GNSS location data with
multiple clients, while providing a way to perform device-specific
setup beforehand. For some devices, it can also manage loading and
storing A-GPS data.

This app is particularly useful to provide location data to geoclue-2.0

This package will be maintained by the Mobian team.


-- 
Respectfully,
Chris Talbot

Bug#1033265: netplan.io: autopkgtest tmpfails in unstable with systemd from experimental

[Paul Gevers]

Source: netplan.io
Version: 0.106-1
Severity: important
X-Debbugs-CC: syst...@packages.debian.org

Dear maintainers,

Since the upload of systemd 253~rc2-1 to experimental the autopkgtest 
tmpfails in unstable if tested with systemd from experimental. Your test 
asks for a reboot, which times out. As tmpfails are immediately retried 
by the Debian migration software, this is causing quite some load. Can 
you please investigate?


Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/n/netplan.io/32304482/log.gz

autopkgtest [19:18:33]: test autostart: [---
+ dpkg-vendor --is Debian
+ rm -f /etc/network/interfaces
+ systemctl unmask systemd-networkd.service
+ systemctl unmask systemd-networkd.socket
+ systemctl unmask systemd-networkd-wait-online.service
+ systemctl enable systemd-networkd.service
Created symlink 
/etc/systemd/system/dbus-org.freedesktop.network1.service → 
/lib/systemd/system/systemd-networkd.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/systemd-networkd.service → 
/lib/systemd/system/systemd-networkd.service.
Created symlink 
/etc/systemd/system/sockets.target.wants/systemd-networkd.socket → 
/lib/systemd/system/systemd-networkd.socket.
Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-network-generator.service 
→ /lib/systemd/system/systemd-network-generator.service.
Created symlink 
/etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service 
→ /lib/systemd/system/systemd-networkd-wait-online.service.

+ systemctl start systemd-networkd.service
+ systemctl unmask systemd-resolved.service
+ systemctl enable systemd-resolved.service
+ systemctl start systemd-resolved.service
+ mount -o remount,rw /sys
+ systemctl unmask systemd-udevd.service
Removed "/etc/systemd/system/systemd-udevd.service".
+ systemctl start systemd-udevd.service
INFO: Doing initial check that there is no existing netplan config.
● systemd-networkd.service - Network Configuration
 Loaded: loaded (/lib/systemd/system/systemd-networkd.service; 
enabled; preset: enabled)

 Active: active (running) since Mon 2023-03-20 19:18:33 UTC; 419ms ago
TriggeredBy: ● systemd-networkd.socket
   Docs: man:systemd-networkd.service(8)
   Main PID: 1274 (systemd-network)
 Status: "Processing requests..."
  Tasks: 1 (limit: 308759)
 Memory: 1.3M
CPU: 33ms
 CGroup: /system.slice/systemd-networkd.service
 └─1274 /lib/systemd/systemd-networkd

Mar 20 19:18:33 ci-079-80a5bc06 systemd[1]: Starting 
systemd-networkd.service - Network Configuration...

Mar 20 19:18:33 ci-079-80a5bc06 systemd-networkd[1274]: lo: Link UP
Mar 20 19:18:33 ci-079-80a5bc06 systemd-networkd[1274]: lo: Gained carrier
Mar 20 19:18:33 ci-079-80a5bc06 systemd-networkd[1274]: eth0: Link UP
Mar 20 19:18:33 ci-079-80a5bc06 systemd-networkd[1274]: eth0: Gained carrier
Mar 20 19:18:33 ci-079-80a5bc06 systemd-networkd[1274]: eth0: Gained IPv6LL
Mar 20 19:18:33 ci-079-80a5bc06 systemd-networkd[1274]: Enumeration 
completed
Mar 20 19:18:33 ci-079-80a5bc06 systemd[1]: Started 
systemd-networkd.service - Network Configuration.

INFO: systemd-networkd is fine, rebooting...
Killed
autopkgtest [19:18:34]: test process requested reboot with marker noconfig
+ dpkg-vendor --is Debian
+ rm -f /etc/network/interfaces
+ systemctl unmask systemd-networkd.service
+ systemctl unmask systemd-networkd.socket
+ systemctl unmask systemd-networkd-wait-online.service
+ systemctl enable systemd-networkd.service
+ systemctl start systemd-networkd.service
+ systemctl unmask systemd-resolved.service
+ systemctl enable systemd-resolved.service
+ systemctl start systemd-resolved.service
+ mount -o remount,rw /sys
+ systemctl unmask systemd-udevd.service
+ systemctl start systemd-udevd.service
INFO: Verifying that the test bridge is not up and writing config.
INFO: Configuration written, rebooting...
Killed
autopkgtest [19:18:43]: test process requested reboot with marker config
Unexpected error:
Traceback (most recent call last):
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 829, in mainloop
command()
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 758, in command
r = f(c, ce)
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 453, in cmd_reboot
caller.hook_wait_reboot(**wait_reboot_args)
  File "/usr/bin/autopkgtest-virt-lxc", line 311, in hook_wait_reboot
wait_booted(lxc_container_name)
  File "/usr/bin/autopkgtest-virt-lxc", line 117, in wait_booted
VirtSubproc.wait_booted(sudoify(['lxc-attach', '--name', lxc_name, 
'--']),
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 247, in 
wait_booted

check_exec(
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 192, in check_exec
(status, out, err) = execute_timeout(None, timeout, real_argv,
  File "/usr/share/autopkgtest/lib/VirtSubproc.py", line 154, in 
execute_timeout

(out, err) = sp.communicate(instr)
  File "/usr/lib/python3.9/subprocess.py", 

Bug#950174: 950174 resolved!

[G.M.]

HI
after much research and knowing that the problem does not arise on new
installations,
I searched for all the old configuration files
In the X11 folder /etc/X11/Xsession.d/ there were files from 2010 and
trying to associate each file with the package they were installed from..
 I found the file
/etc/X11/Xsession.d/20desktop-profiles_activateDesktopProfiles
belonging to the package
desktop-profiles

I fixed it by deleting the outdated package desktop-profiles and finally it
works without errors and without slowdowns!
I hope it's useful for those who have old debian installations ;-) and who
wisely keep upgrading

bye bye Gianluca

Bug#1033264: ruby-rack: CVE-2023-27539

[Salvatore Bonaccorso]

Source: ruby-rack
Version: 2.2.4-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-rack.

CVE-2023-27539[0]:
| Possible Denial of Service Vulnerability in Rack’s header parsing

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-27539
https://www.cve.org/CVERecord?id=CVE-2023-27539
[1] 
https://discuss.rubyonrails.org/t/cve-2023-27539-possible-denial-of-service-vulnerability-in-racks-header-parsing/82466
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033263: rails: CVE-2023-23913

[Salvatore Bonaccorso]

Source: rails
Version: 2:6.1.7+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rails.

CVE-2023-23913[0]:
| DOM Based Cross-site Scripting in rails-ujs for contenteditable HTML
| Elements

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-23913
https://www.cve.org/CVERecord?id=CVE-2023-23913
[1] 
https://discuss.rubyonrails.org/t/cve-2023-23913-dom-based-cross-site-scripting-in-rails-ujs-for-contenteditable-html-elements/82468

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033261: strawberry: Tag editing can corrupt media files

[Peter B]

Package: strawberry
Version: 1.0.14-1
Severity: important
Tags: upstream
X-Debbugs-Cc: pe...@pblackman.plus.com

A bug affecting the tag editor can cause possible corruption of media files.
Versions affected are all versions from 0.9.1 to the current latest 1.0.15.

The issue occurs whenever you edit and save both the tags and the album cover
with the embedded cover option in one operation. The embedded cover option is
off by default, and it only occurs if you also edit any tags in the same save
operation.
It is also possible that the issue only affects certain audio formats on
specific file-systems.

As a precaution, suggest to not use the tag editor at all until a new release
[16] is available.


https://github.com/strawberrymusicplayer/strawberry/issues/1158

Bug#1033262: rails: CVE-2023-28120

[Salvatore Bonaccorso]

Source: rails
Version: 2:6.1.7+dfsg-3
Severity: important
X-Debbugs-Cc: car...@debian.org

Hi,

The following vulnerability was published for rails.

CVE-2023-28120[0]:
| Possible XSS Security Vulnerability in SafeBuffer#bytesplice

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28120
https://www.cve.org/CVERecord?id=CVE-2023-28120
[1] 
https://discuss.rubyonrails.org/t/cve-2023-28120-possible-xss-security-vulnerability-in-safebuffer-bytesplice/82469

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033260: libpython3.11-minimal: should Break: python3-pysimplesoap (<< 1.16.2-5)

[Lionel Elie Mamane]

Package: libpython3.11-minimal
Version: 3.11.2-4
Severity: normal
Control: affects -1 python3-pysimplesoap

python3.11 breaks python3-pysimplesoap (versions prior to 1.16.2-5)
but doesn't declare so.

Trying to use python3-pysimplesoap with python3.11 gives error:

  File "/usr/lib/python3/dist-packages/pysimplesoap/__init__.py", line 16, in 

from . import client, server, simplexml, transport
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 33, in 

from .transport import get_http_wrapper, set_http_wrapper, get_Http
  File "/usr/lib/python3/dist-packages/pysimplesoap/transport.py", line 109, in 

if 'timeout' in inspect.getargspec(httplib2.Http.__init__)[0]:
^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 
'getargs'?


pysimplesoap version 1.16.2-5 has the fix for that

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (400, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libpython3.11-minimal depends on:
ii  libc62.36-8
ii  libssl3  3.0.8-1

Versions of packages libpython3.11-minimal recommends:
ii  libpython3.11-stdlib  3.11.2-4

libpython3.11-minimal suggests no packages.

-- no debconf information

Bug#1033259: lists.debian.org: vgui-discuss archive is heavily spam-infested

[Lionel Elie Mamane]

Package: lists.debian.org
Severity: normal

I've patiently clicked on a few years worth of archives "report as
spam" message per message, but I've run out of steam after doing
December 2005 and have stopped going into older messages.

I've found *one* non-spam message since December 2005, that is
https://lists.debian.org/vgui-discuss/2006/01/msg00019.html

Bug#920139:

[pipe...@yahoo.it]

HI i had a similar problem with my install done many years ago;
I fixed it by deleting the outdated package
desktop-profiles

I hope it can help you
Greetings Gianluca

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Bill Allombert]

On Mon, Mar 20, 2023 at 12:05:24PM +, James Addison wrote:
> On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote:
> > Perhaps lintian could add classification tags for the relevant CPU
> > instructions and then the i386 port could have extra autopkgtest nodes
> > that only process the packages detected by lintian.
> 
> That's not a bad idea.  Are there any reasons that that might _not_ be a good
> idea before filing a wishlist bug?  (performance, implications of scanning
> binary packages, ...)

This seems logistically problematic.
Is lintian actually ran on i386 binaries anymore ?
lintian.debian.org only lists reports for amd64 packages.

I am not sure it is worth the trouble, frankly. I do not see what this would
bring us.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1032986: unblock fdroidserver/2.2.1-1

[Paul Gevers]

Hi,

On 20-03-2023 17:16, Hans-Christoph Steiner wrote:
I haven't really ever been able to troubleshoot it.  I don't have access 
to a s390x box.  And:


  ~ $ ssh zelenka.debian.org
ssh: connect to host zelenka.debian.org port 22: Connection timed out
  ~ $

That's the only porterbox I could find.


It works for me (now). Can you try again?

Also, you don't strictly need to troubleshoot it. Obviously it depends 
on how sure you are it's in your dependency, but you said it quite 
convinced.


Normally we expect a debdiff attached to an unblock. This is mostly to 
trigger the submitter to look at it and make sure that all changes are 
explained. Can you please elaborate on the changes in ./debian/?

  ^

The debdiff is large because we were working upstream on 2.2.x as the 
release that is tied to Debian/bookworm (attached).


Sure, I already used some tooling on our side to inspect it. It would 
help if you took a look and see if you spot things worth mentioning 
(e.g. some patches being dropped, I don't want to assume things). To 
reduce the diff you could ignore the tests and translations.


And that was 
uploaded before the freeze with passing autopkgtest, besides this s390x 
issue.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033245: php-common: phpquery doesn't retrieve fpm version installed

[Azerttyu]

Hello

My purpose is to retrieve all php fpm installed. With phpquery, I 
presume coud be provided by phpquery -s fpm -V


I could get this information with find -L /etc/php -mindepth 2 -maxdepth 
2 -name fpm -printf "%h\n"

Other options could be : dpkg --get-selections |grep "fpm\s*install"

We can have phpXX cli but not fpm part installed.

I hope have beee more explicit on my purpose.

Thanks

Le 20/03/2023 à 18:14, Ondřej Surý a écrit :

Hi,

your bug report is quite hard to parse, but I am 99% sure that this:


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

I've executed "phpquery -s fpm -V"

is not the full picture. So, could you transparently describe what you did to 
your system that led to this situation?

I’m 100% sure that it doesn’t start reporting 8.2 out of the blue.

Ondrej
--
Ondřej Surý  (He/Him)


On 20. 3. 2023, at 17:39, Azerttyu  wrote:

Package: php-common
Version: 2:93+0~20221211.45+debian11~1.gbpdb4dcc
Severity: normal

Dear Maintainer,

   * What led up to the situation?

phpquery doesn't return fpm version installed. In my usecase php 8.2 is not
installed with fpm behavior.

Error looks come fromhttps://salsa.debian.org/php-team/php-
defaults/-/blob/main/php-helper#L203 where fpm directory restriction is not
took in consideration.

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

I've executed "phpquery -s fpm -V"

   * What was the outcome of this action?

8.2
8.1
8.0
7.4
7.3
7.2
7.1
7.0
5.6

   * What outcome did you expect instead?

8.1
8.0
7.4
7.3
7.2
7.1
7.0
5.6


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


-- System Information:

Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name

[Karl O. Pinc]

On Mon, 20 Mar 2023 12:16:58 -0600
Sam Hartman  wrote: 

> pam_sssd always adds randomness to the cache name.
> So, this is not an issue with krb5; pam_sssd is explicitly setting
> KRB5CCNAME environment variable.

As an FYI, I don't see any of the above documented (Ubuntu 22.04.2 LTS)
in pam_sss(8) or pam_sss_gss(8).  (I can't find a man page for
pam_sssd.)  Further, the krb5_ccname_template section of sssd-krb5(5)
indicates that the default is the kerberos DEFCCNAME, as it refers
to krb5.conf(5), the libdefaults section.

So that makes it all a bit confusing.  But I'm going to focus on 
my problems getting cifs.upcall working, getting it the "right"
ccname, and leave these documentation issues for others.
(I mean, I can _make_ cifs.upcall work, but getting there
was painful.  It should work better out of the box.)

Anyway, again, thanks all for the help.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1033258: upx-ucl: CVE-2023-23456

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for upx-ucl.

CVE-2023-23456[0]:
| A heap-based buffer overflow issue was discovered in UPX in
| PackTmt::pack() in p_tmt.cpp file. The flow allows an attacker to
| cause a denial of service (abort) via a crafted file.

https://github.com/upx/upx/commit/510505a85cbe45e51fbd470f1aa8b02157c429d4
https://github.com/upx/upx/issues/632

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-23456
https://www.cve.org/CVERecord?id=CVE-2023-23456

Please adjust the affected versions in the BTS as needed.

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[James Addison]

Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: elb...@debian.org
Control: severity -1 serious

Increasing this bug's severity to a release-critical, based on mailing list
discussion[1].

Paul: bug #1005863 has most of the relevant context for Debian, although I'd
recommend the following wiki page as a more concise, purpose-written summary:

  https://www.jookia.org/wiki/Nopl

[1] - https://lists.debian.org/debian-doc/2023/03/msg00012.html

Bug#1033257: libde265: CVE-2023-27102 CVE-2023-27103

[Moritz Mühlenhoff]

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

Hi,

The following vulnerabilities were published for libde265.

CVE-2023-27102[0]:
| Libde265 v1.0.11 was discovered to contain a segmentation violation
| via the function decoder_context::process_slice_segment_header at
| decctx.cc.

https://github.com/strukturag/libde265/issues/393
https://github.com/strukturag/libde265/commit/0b1752abff97cb542941d317a0d18aa50cb199b1

CVE-2023-27103[1]:
| Libde265 v1.0.11 was discovered to contain a heap buffer overflow via
| the function derive_collocated_motion_vectors at motion.cc.

https://github.com/strukturag/libde265/issues/394
https://github.com/strukturag/libde265/commit/d6bf73e765b7a23627bfd7a8645c143fd9097995

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-27102
https://www.cve.org/CVERecord?id=CVE-2023-27102
[1] https://security-tracker.debian.org/tracker/CVE-2023-27103
https://www.cve.org/CVERecord?id=CVE-2023-27103

Please adjust the affected versions in the BTS as needed.

Bug#1033256: bullseye: bump python3-django-mailman3 version?

[Luis Gerhorst]

Package: python3-django-mailman3
Version: 1.3.5-2

Would it be possible to bump bullseye's python3-django-mailman3 [1] from 
1.3.5 to something >= 1.3.6?


We (running Debian 11) are affected by upstream issue [2] which has been 
fixed in 1.3.6. I noticed that 1.3.7 was already part of testing in 2021.


Apologies if this is the wrong place to submit this issue.

Best regards,
Luis

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=python3-django-mailman3;dist=stable

[2] https://gitlab.com/mailman/hyperkitty/-/issues/471


OpenPGP_0x135327F1058CA0EA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033255: aflplusplus: CVE-2023-26266

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for aflplusplus.

CVE-2023-26266[0]:
| In AFL++ 4.05c, the CmpLog component uses the current working
| directory to resolve and execute unprefixed fuzzing targets, allowing
| code execution.

https://github.com/AFLplusplus/AFLplusplus/pull/1643
https://github.com/AFLplusplus/AFLplusplus/commit/f2be73186e2e16c3992f92b65ae9ba598d6fff2f
https://github.com/AFLplusplus/AFLplusplus/commit/673a0a3866783bf28e31d14fbd7a9009c7816ec3


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-26266
https://www.cve.org/CVERecord?id=CVE-2023-26266

Please adjust the affected versions in the BTS as needed.

Bug#1018718: apache2-doc: despite having been disabled, apache2-doc.conf gets rather silently re-enabled automatically

[Thorsten Glaser]

Package: apache2-doc
Version: 2.4.56-1~deb11u1
Followup-For: Bug #1018718
X-Debbugs-Cc: t...@mirbsd.de
Control: severity -1 serious

Justification: Policy §10.7.3

This package overwrites local changes on upgrade,
which is a release-critical bug as it’s a Policy
violation.




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

Kernel: Linux 5.10.0-21-amd64 (SMP w/1 CPU thread)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

apache2-doc depends on no packages.

Versions of packages apache2-doc recommends:
ii  apache2  2.4.56-1~deb11u1

apache2-doc suggests no packages.

-- no debconf information

Bug#1033254: imagemagick: CVE-2023-1289

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for imagemagick.

CVE-2023-1289[0]:
https://github.com/ImageMagick/ImageMagick/security/advisories/GHSA-j96m-mjp6-99xr
https://github.com/ImageMagick/ImageMagick/commit/c5b23cbf2119540725e6dc81f4deb25798ead6a4

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1289
https://www.cve.org/CVERecord?id=CVE-2023-1289

Please adjust the affected versions in the BTS as needed.

Bug#1033252: maradns: CVE-2022-30256

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for maradns.

CVE-2022-30256[0]:
| An issue was discovered in MaraDNS Deadwood through 3.5.0021 that
| allows variant V1 of unintended domain name resolution. A revoked
| domain name can still be resolvable for a long time, including expired
| domains and taken-down malicious domains. The effects of an exploit
| would be widespread and highly impactful, because the exploitation
| conforms to de facto DNS specifications and operational practices, and
| overcomes current mitigation patches for "Ghost" domain names.

https://maradns.samiam.org/security.html#CVE-2022-30256

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-30256
https://www.cve.org/CVERecord?id=CVE-2022-30256

Please adjust the affected versions in the BTS as needed.

Bug#1033253: undertow: CVE-2023-1108

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for undertow.

CVE-2023-1108[0]:
https://issues.redhat.com/browse/UNDERTOW-2239


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1108
https://www.cve.org/CVERecord?id=CVE-2023-1108

Please adjust the affected versions in the BTS as needed.

Bug#1033251: wordpress: CVE-2022-3590

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for wordpress.

CVE-2022-3590[0]:
| WordPress is affected by an unauthenticated blind SSRF in the pingback
| feature. Because of a TOCTOU race condition between the validation
| checks and the HTTP request, attackers can reach internal hosts that
| are explicitly forbidden.

Only reference here is
https://www.sonarsource.com/blog/wordpress-core-unauthenticated-blind-ssrf/

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-3590
https://www.cve.org/CVERecord?id=CVE-2022-3590

Please adjust the affected versions in the BTS as needed.

Bug#1033239: libsoup-3.0-0: Crash when adding a new calendar in gnome-calendars

[Alberto Garcia]

Control: tags -1 patch

I confirm that this patch fixes the problem.

Berto
diff -Nru gnome-calendar-43.1/debian/changelog gnome-calendar-43.1/debian/changelog
--- gnome-calendar-43.1/debian/changelog	2022-10-18 16:09:27.0 +0200
+++ gnome-calendar-43.1/debian/changelog	2023-03-20 18:25:22.0 +0100
@@ -1,3 +1,10 @@
+gnome-calendar (43.1-2) unstable; urgency=high
+
+  * debian/patches/validate-uri.patch:
+- Fix crash when adding an url manually (Closes: #1033239)
+
+ -- Alberto Garcia   Mon, 20 Mar 2023 18:25:22 +0100
+
 gnome-calendar (43.1-1) unstable; urgency=high
 
   * New upstream release (LP: #1993308)
diff -Nru gnome-calendar-43.1/debian/patches/series gnome-calendar-43.1/debian/patches/series
--- gnome-calendar-43.1/debian/patches/series	2022-10-18 16:09:27.0 +0200
+++ gnome-calendar-43.1/debian/patches/series	2023-03-20 18:16:08.0 +0100
@@ -0,0 +1 @@
+validate-uri.patch
diff -Nru gnome-calendar-43.1/debian/patches/validate-uri.patch gnome-calendar-43.1/debian/patches/validate-uri.patch
--- gnome-calendar-43.1/debian/patches/validate-uri.patch	1970-01-01 01:00:00.0 +0100
+++ gnome-calendar-43.1/debian/patches/validate-uri.patch	2023-03-20 18:25:22.0 +0100
@@ -0,0 +1,121 @@
+From: Georges Basile Stavracas Neto 
+Subject: Test URI before discovery
+Bug: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/794
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033239
+Origin: https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/0322bcf54cf1fc37ff74b87fd36e282dc1cf7863
+Index: gnome-calendar-43.1/src/utils/gcal-source-discoverer.c
+===
+--- gnome-calendar-43.1.orig/src/utils/gcal-source-discoverer.c
 gnome-calendar-43.1/src/utils/gcal-source-discoverer.c
+@@ -183,6 +183,26 @@ is_authentication_error (gint code)
+   return FALSE;
+ }
+ 
++static GUri *
++create_and_validate_uri (const gchar  *uri,
++ GError  **error)
++{
++  g_autoptr (GUri) guri = NULL;
++
++  guri = g_uri_parse (uri, SOUP_HTTP_URI_FLAGS | G_URI_FLAGS_PARSE_RELAXED, error);
++
++  if (!guri)
++GCAL_RETURN (NULL);
++
++  if (!g_uri_get_host (guri) || g_uri_get_host (guri)[0] == '\0')
++{
++  g_set_error (error, G_URI_ERROR, G_URI_ERROR_FAILED, "Invalid URI");
++  return NULL;
++}
++
++  return g_steal_pointer ();
++}
++
+ 
+ /*
+  * Callbacks
+@@ -221,7 +241,7 @@ discover_file_in_thread (DiscovererData
+ 
+   GCAL_ENTRY;
+ 
+-  guri = g_uri_parse (data->uri, SOUP_HTTP_URI_FLAGS | G_URI_FLAGS_PARSE_RELAXED, NULL);
++  guri = create_and_validate_uri (data->uri, error);
+ 
+   if (!guri)
+ GCAL_RETURN (NULL);
+@@ -277,6 +297,7 @@ discover_webdav_in_thread (DiscovererDat
+   g_autoptr (ESource) source = NULL;
+   g_autoptr (GError) local_error = NULL;
+   g_autofree gchar *certificate_pem = NULL;
++  g_autoptr (GUri) guri = NULL;
+   GTlsCertificateFlags flags;
+   GSList *discovered_sources = NULL;
+   GSList *user_addresses = NULL;
+@@ -284,6 +305,11 @@ discover_webdav_in_thread (DiscovererDat
+ 
+   GCAL_ENTRY;
+ 
++  guri = create_and_validate_uri (data->uri, error);
++
++  if (!guri)
++GCAL_RETURN (NULL);
++
+   credentials = e_named_parameters_new ();
+   e_named_parameters_set (credentials, E_SOURCE_CREDENTIAL_USERNAME, data->username);
+   e_named_parameters_set (credentials, E_SOURCE_CREDENTIAL_PASSWORD, data->password);
+Index: gnome-calendar-43.1/tests/test-discoverer.c
+===
+--- gnome-calendar-43.1.orig/tests/test-discoverer.c
 gnome-calendar-43.1/tests/test-discoverer.c
+@@ -82,6 +82,43 @@ discoverer_file (void)
+ 
+ /*/
+ 
++static void
++discoverer_invalid_https_only_cb (GObject  *source_object,
++  GAsyncResult *result,
++  gpointer  user_data)
++{
++  g_autoptr (GPtrArray) sources = NULL;
++  g_autoptr (GError) error = NULL;
++  GMainLoop *mainloop = user_data;
++
++  sources = gcal_discover_sources_from_uri_finish (result, );
++  g_assert_error (error, G_URI_ERROR, G_URI_ERROR_FAILED);
++  g_assert_null (sources);
++
++  g_main_loop_quit (mainloop);
++}
++
++static void
++discoverer_invalid_https_only (void)
++{
++  g_autoptr (GMainLoop) mainloop = NULL;
++
++  g_test_bug ("794");
++
++  mainloop = g_main_loop_new (NULL, FALSE);
++
++  gcal_discover_sources_from_uri ("https://;,
++  NULL,
++  NULL,
++  NULL,
++  discoverer_invalid_https_only_cb,
++  mainloop);
++
++  g_main_loop_run (mainloop);
++}
++
++/*/
++
+ 

Bug#1033250: node-request: CVE-2023-28155

[Moritz Mühlenhoff]

Source: node-request
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for node-request.

CVE-2023-28155[0]:
| ** UNSUPPORTED WHEN ASSIGNED ** The Request package through 2.88.1 for
| Node.js allows a bypass of SSRF mitigations via an attacker-controller
| server that does a cross-protocol redirect (HTTP to HTTPS, or HTTPS to
| HTTP). NOTE: This vulnerability only affects products that are no
| longer supported by the maintainer.

https://github.com/request/request/issues/3442 was reported, but seems
the module is EOLed, so maybe we should be looking into retiring it
for trixie?

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28155
https://www.cve.org/CVERecord?id=CVE-2023-28155

Please adjust the affected versions in the BTS as needed.

Bug#1033164: closed by Sam Hartman (Re: Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name)

[Karl O. Pinc]

> From: Sam Hartman 
> To: "Karl O. Pinc" , 1033164-d...@bugs.debian.org, Andreas 
>  Hasenack 
> Cc: Benjamin Kaduk , 1033...@bugs.debian.org
> Subject: Re: Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably,  
> not the actual credential cache name
> Date: Mon, 20 Mar 2023 12:16:58 -0600
> 
> > "Karl" == Karl O Pinc  writes:  
> 
> Karl> On Mon, 20 Mar 2023 09:27:39 -0300
> Karl> Andreas Hasenack  wrote:  
> 
> >> The extra randomness suffix happens when you login via
> >> ssh/gssapi.  
> 
> Karl> That is exactly how I'm logging in, authenticating credentials
> Karl> with MS Active Directory, with configuration set in
> Karl> /etc/sssd/sssd.conf and /etc/krb5.conf -- after joining with
> Karl> the "realm" command.  
> 
> pam_sssd always adds randomness to the cache name.
> So, this is not an issue with krb5; pam_sssd is explicitly setting
> KRB5CCNAME environment variable.

Thanks for the help with this.  Much appreciated.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name

[Sam Hartman]

> "Karl" == Karl O Pinc  writes:

Karl> On Mon, 20 Mar 2023 09:27:39 -0300
Karl> Andreas Hasenack  wrote:

>> The extra randomness suffix happens when you login via
>> ssh/gssapi.

Karl> That is exactly how I'm logging in, authenticating credentials
Karl> with MS Active Directory, with configuration set in
Karl> /etc/sssd/sssd.conf and /etc/krb5.conf -- after joining with
Karl> the "realm" command.

pam_sssd always adds randomness to the cache name.
So, this is not an issue with krb5; pam_sssd is explicitly setting
KRB5CCNAME environment variable.

Bug#1033212: plasma-mobile fails to start on PP after kwin's commit eef9bd5c with "libkwinglutils: Shaders are not supported"

[Marco Mattiolo]

Version: 4:5.27.2-1
Severity: grave
Tags: patch,upstream,fixed-upstream

Bug#1033249: unblock: gnome-initial-setup/43.2-6

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: gnome-initial-se...@packages.debian.org
Control: affects -1 + src:gnome-initial-setup
Control: block -1 by 1029206

Please unblock package gnome-initial-setup. Note that this unblock
request is entangled with #1029206: in their current state, either they
will both migrate, or neither will.

[ Reason ]
* Fix the Privacy Policy link when asking whether to enable Mozilla
  Location Services (#1033228)
* Compatibility with a longer-term-supported WebKitGTK (see #1029206)

[ Impact ]
A minor code change in 43.2-5 is a blocker for #1029206.

Additionally, if not unblocked, the "privacy policy" hyperlink in
the Privacy tab will not do anything when gnome-initial-setup is run
automatically on a system that has no user accounts yet. This doesn't
normally happen on Debian systems, because d-i creates a user account,
but it can happen if d-i was not used or if the d-i-created user account
was deleted. (#1033228)

The "privacy policy" link not working seems like something that would
make us look bad.

[ Tests ]
Tested manually with the steps in #1033228. Briefly: deleted the user
account created by d-i, then rebooted and went through initial setup as
if for the first time, then re-ran initial setup as the logged-in user
to simulate what would normally happen after a d-i installation.

The upstream change for #1033228 includes a corresponding change for a
UI toggle for whether to enable automatic crash reporting (Fedora's abrt).
In practice this widget is not visible in Debian, because we don't have
abrt, so that part is untested - but it's very similar to the UI toggle
for location services.

[ Risks ]
The upstream changes to fix #1033228 are mostly declarative and I would
say they are low risk.

The upstream changes to fix FTBFS with the new WebKitGTK from #1029206 are
very simple.

If #1029206 can't happen for some reason, then this version will be unable
to migrate. A contingency plan is to revert the build-dependency change.
The patch applied for #1029206 is unnecessary but harmless if we revert to
the old WebKitGTK.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock gnome-initial-setup/43.2-6
diffstat for gnome-initial-setup-43.2 gnome-initial-setup-43.2

 debian/changelog |   28 ++
 debian/control   |2 
 debian/control.in|2 
 debian/patches/Update-for-removal-of-WebKitGTK-sandbox-API.patch |   26 ++
 debian/patches/privacy-Move-subtitles-to-separate-labels.patch   |  121 ++
 debian/patches/series|2 
 gnome-initial-setup/gis-driver.c |2 
 gnome-initial-setup/pages/privacy/gis-privacy-page.c |6 
 gnome-initial-setup/pages/privacy/gis-privacy-page.ui|   31 ++
 9 files changed, 214 insertions(+), 6 deletions(-)

diff -Nru gnome-initial-setup-43.2/debian/changelog gnome-initial-setup-43.2/debian/changelog
--- gnome-initial-setup-43.2/debian/changelog	2023-03-06 23:46:19.0 +
+++ gnome-initial-setup-43.2/debian/changelog	2023-03-20 15:27:27.0 +
@@ -1,3 +1,31 @@
+gnome-initial-setup (43.2-6) unstable; urgency=medium
+
+  * Team upload
+  * d/p/privacy-Move-subtitles-to-separate-labels.patch:
+Fix Mozilla Location Services privacy policy link in kiosk mode.
+The privacy policy links on the Privacy page are meant to be overridden
+to open in an embedded (WebKitGTK-based) web browser widget instead of
+an external web browser, but a regression in the port to GTK 4 between
+GNOME 42 and 43 caused this behaviour to break.
+In existing-user mode (run on the first GNOME login for a new user
+account), the link would previously have opened in the default web
+browser (normally Firefox), which is harmless but was not the
+intended UX.
+In new-user mode (when no user accounts exist), Initial Setup runs in a
+captive "kiosk mode" to create the first user account. In this mode, the
+link would previously not do anything. A mitigation is that this failure
+mode is rarely seen in Debian, because the installer normally creates a
+user account. (Closes: #1033228)
+
+ -- Simon McVittie   Mon, 20 Mar 2023 15:27:27 +
+
+gnome-initial-setup (43.2-5) unstable; urgency=medium
+
+  * Build against webkitgtk 6.0 instead of 5.0
+  * Cherry-pick a build fix for latest webkitgtk
+
+ -- Jeremy Bicha   Wed, 15 Mar 2023 20:18:52 -0400
+
 gnome-initial-setup (43.2-4) unstable; urgency=medium
 
   * Team upload
diff -Nru gnome-initial-setup-43.2/debian/control gnome-initial-setup-43.2/debian/control
--- gnome-initial-setup-43.2/debian/control	2023-03-06 

Bug#1033248: ITP: python-onetimepad -- python library for the onetimepad algorithm

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Python Team 
, matthias.geiger1...@tutanota.de

* Package name: python-ontimepad
  Version : 1.4
  Upstream Contact: Jai Luthra  
* URL : https://github.com/jailuthra/onetimepad
* License : MIT
  Programming Lang: Python
  Description : python library for the onetimepad algorithm

I intend to package this python library; it's a dependency for banking 
(#1013317). 
The packaging is done; I intend to push it to salsa soon. I'd need a sponsor 
for the initial upload.

Thanks,

Matthias Geiger (werdahias) 


signature.asc
Description: application/pgp-keys

Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name

[Karl O. Pinc]

On Mon, 20 Mar 2023 09:27:39 -0300
Andreas Hasenack  wrote:

> The extra randomness suffix happens when you login via ssh/gssapi.

That is exactly how I'm logging in, authenticating credentials with 
MS Active Directory, with configuration set in /etc/sssd/sssd.conf
and /etc/krb5.conf -- after joining with the "realm" command.

Winbind is not involved. And /etc/samba/smb.conf is involved only in
so far as setting "server role = member server" and
"kerberos method = secrets and keytab" (and realm and workgroup).
But smb.conf is involved only in so far as it is needed to mount
shares with a type of smb3 and sec=krb5.
Without making any changes to smb.conf I can login and
see the a credential cache file in /tmp/ with the extra randomness
suffix.  So the addition of the suffix does not seem to involve
smb.conf.

To be honest, I'm unclear on the involvement of gssapi.  There's
nothing in /etc/pam.d/ which invokes pam_sss_gss.so, and there's nothing
explicit in /etc/sssd/sssd.conf mentioning gss.  And sssd.conf(5)
seems to indicate that gssapi is not used unless explicitly configured.
So, without really knowing what gssapi does, I dont' see it being
called.  Yet I believe I've
seen log entries, or something, at some point while I was doing lots
of poking with a stick, that mentioned gssapi.  I suppose I could be
wrong.  Yup, here's a sample (there are other log entries from auditd):

sssd[15755]: tkey query failed: GSSAPI error: Major = Unspecified GSS failure.  
Minor code may provide more information, Minor = Server not found in Kerberos 
database.

There are also various messages involving adcli, and some from
ldap_child.

Thanks for the help.


> 
> On Sun, Mar 19, 2023 at 9:09 PM Benjamin Kaduk  wrote:
> >
> > Hmm, on my local machines (one running Debian, one running Ubuntu)
> > I appear to be seeing the expected default /tmp/krb5cc_%{uid}
> > behavior. I couldn't quite follow how your credentials were
> > obtained; were they perhaps obtained as part of the login process?
> > The PAM configuration might well be relevant in that case.
> >
> > -Ben
> >  
> 


Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1033238: Addition

[Jannick Loch]

I totally forgot that this kind of package has to be approved by the 
ftp-master team. The bus is closed


-done

Bug#995822: fbset: modeline2fb: fbset is (1), not (8)

[Jakub Wilk]

There's another fbset(8) reference in the fb.modes man page:

$ man fb.modes | grep -Ewo 'fbset[()0-9]+'
fbset(8)

--
Jakub Wilk

Bug#1033245: php-common: phpquery doesn't retrieve fpm version installed

[Ondřej Surý]

Hi,

your bug report is quite hard to parse, but I am 99% sure that this:

>   * What exactly did you do (or not do) that was effective (or ineffective)?
> 
> I've executed "phpquery -s fpm -V"

is not the full picture. So, could you transparently describe what you did to 
your system that led to this situation?

I’m 100% sure that it doesn’t start reporting 8.2 out of the blue.

Ondrej 
--
Ondřej Surý  (He/Him)

> On 20. 3. 2023, at 17:39, Azerttyu  wrote:
> 
> Package: php-common
> Version: 2:93+0~20221211.45+debian11~1.gbpdb4dcc
> Severity: normal
> 
> Dear Maintainer,
> 
>   * What led up to the situation?
> 
> phpquery doesn't return fpm version installed. In my usecase php 8.2 is not
> installed with fpm behavior.
> 
> Error looks come from https://salsa.debian.org/php-team/php-
> defaults/-/blob/main/php-helper#L203 where fpm directory restriction is not
> took in consideration.
> 
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
> 
> I've executed "phpquery -s fpm -V"
> 
>   * What was the outcome of this action?
> 
> 8.2
> 8.1
> 8.0
> 7.4
> 7.3
> 7.2
> 7.1
> 7.0
> 5.6
> 
>   * What outcome did you expect instead?
> 
> 8.1
> 8.0
> 7.4
> 7.3
> 7.2
> 7.1
> 7.0
> 5.6
> 
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> 

Bug#1033239: libsoup-3.0-0: Crash when adding a new calendar in gnome-calendars

[Alberto Garcia]

reassign 1033239 gnome-calendar 43.1-1
tags 1033239 fixed-upstream
retitle 1033239 Crashes when typing an https url manually
thanks

On Mon, Mar 20, 2023 at 03:45:00PM +, Alberto Garcia wrote:

> I'm not sure if this is a problem in libsoup or in gnome-calendar,

It was in gnome-calendar after all:

   https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/794

   
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/0322bcf54cf1fc37ff74b87fd36e282dc1cf7863

Berto

Bug#1033247: libmail-java: change homepage to https://jakartaee.github.io/mail-api/

[Patrice Duroux]

Package: libmail-java
Version: 1.6.5-1
Severity: wishlist

Dear Maintainer,

Currently the homepage found in the d/control file is:
http://javamail.java.net
which is the (old) Oracle Java one.
But the d/watch file is looking for the upstream source at:
https://github.com/eclipse-ee4j/mail

So I suggest to change the homepage for the Jakarta EE one:
https://jakartaee.github.io/mail-api/

Regards,
Patrice

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

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

Versions of packages libmail-java depends on:
ii  libactivation-java  1.2.0-2

libmail-java recommends no packages.

Versions of packages libmail-java suggests:
pn  libmail-java-doc  

-- no debconf information

Bug#1032986: unblock fdroidserver/2.2.1-1

[Jochen Sprickerhof]

* Hans-Christoph Steiner  [2023-03-20 17:16]:
I haven't really ever been able to troubleshoot it.  I don't have 
access to a s390x box.  And:


~ $ ssh zelenka.debian.org
ssh: connect to host zelenka.debian.org port 22: Connection timed out
~ $


We resolved this with:

https://lists.debian.org/debian-devel-announce/2018/11/msg3.html

(i.e. ssh jumphost)

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1033246: watchdog: The periodic fork test mentioned in the man page is not performed

[Peter Rosin]

Package: watchdog
Version: 5.15-2
Severity: normal
Tags: upstream

Dear Maintainer,

After crashing the kernel with "echo c > /proc/sysrq-trigger" the
watchdoggery sometimes failes to trigger a reboot. It's as if the
watchdog daemon continues to successfully perform its checks and
thus continues to service the hardware watchdog even if the
kernel has paniced.

The watchdog configuration is trivial:

watchdog-device = /dev/watchdog
interval = 10
realtime = yes
priority = 1
pidfile = /run/foo.pid
pidfile = /run/bar.pid

When reading the manual I noticed this passage:

"watchdog will try periodically to fork itself to
see whether the process table is full."

Since I was a bit sceptic that a paniced kernel could
successfully fork, I wondered a bit about what "periodically"
meant. So I went digging to see exactly how often that fork
test is performed and how long a should expect to wait for it,
but it appears it is no longer done at all.

To verify, I added an empty script that simply returns 0 to
/etc/watchdog.d and after that, the watchdog kicks in as expected.
That's arguably heavier than a fork-exit-test, but still an
indication.

I then went digging in the git history to check if it might be
intentional, but it appears not. The way I read it, the check
went missing along with 12-year-old commit
0fc6d009c78f ("This patch allows zero or more scripts/programs...")
which was new for version 5.10.

Notice how the "if (tbinary == NULL)" test is moved to before the
fork() call in the check_bin() function in that patch. But maybe
I misread something?

Anyway, please repair the broken fork test (or adjust the manual
to the new reality.)

Cheers,
Peter



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldstable-updates'), (500, 'testing'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages watchdog depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.56+nmu1
ii  libc6  2.28-10
ii  lsb-base   10.2019051400
ii  udev   232-25+deb9u11

watchdog recommends no packages.

watchdog suggests no packages.

-- debconf information excluded

Bug#1032965: Upstream 1.2.2 with Prelim Packaging

[Barak A. Pearlmutter]

I've done a bit of testing, and my prelim 1.2.2 packaging seems to
work fine. Also a tiny bit more yak shaving.

I have not tried to get the unit testing stuff working with the
debian/tests automated test suite business. But if that were done,
this version might be able to get past the freeze. (Also a good idea
for its own sake, of course.) There's a lot of test stuff, and it's
set up with Docker and tox. Just "cd testing && ./run_tests" downloads
all sorts of python stuff and runs it without Docker just fine (see
below), but ways to directly invoke just the tests are documented in
README-TESTING.md. Bottom line, I don't see any particular difficulty
in getting it to work in an autopkgtest / DEP-8 setup. "./setup.py
test" from the main directory might even be enough, once all the right
dependencies are marshalled in debian/tests/control.

Cheers,

--Barak.

testing/functional/test_restart.py ..

 [ 81%]
testing/functional/test_selection.py
...
  [ 98%]
testing/functional/test_verify.py 

 [100%]

==
warnings summary
==
.tox/py311/lib/python3.11/site-packages/future/standard_library/__init__.py:65
  
/home/barak/src/git/duplicity/.tox/py311/lib/python3.11/site-packages/future/standard_library/__init__.py:65:
DeprecationWarning: the imp module is deprecated in favour of
importlib and slated for removal in Python 3.12; see the module's
documentation for alternative uses
import imp

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 generated xml file:
/home/barak/src/git/duplicity/report.xml

== 467 passed, 10
skipped, 1 warning in 1044.34s (0:17:24)
===
__
summary 
___
  code: commands succeeded
ERROR:  py27: InterpreterNotFound: python2.7
ERROR:  py35: InterpreterNotFound: python3.5
ERROR:  py36: InterpreterNotFound: python3.6
ERROR:  py37: InterpreterNotFound: python3.7
ERROR:  py38: InterpreterNotFound: python3.8
ERROR:  py39: InterpreterNotFound: python3.9
ERROR:  py310: InterpreterNotFound: python3.10
  py311: commands succeeded

Bug#1029342: jexec: can't locate java: No such file or directory

[Patrice Duroux]

Hi,

First note that:

$ jexec
can't locate java: No such file or directory
$ ls -l /etc/alternatives/jexec
lrwxrwxrwx 1 root root 44 28 déc.  19:45 /etc/alternatives/jexec ->
/usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
$ /usr/lib/jvm/java-17-openjdk-amd64/lib/jexec
Error: -jar requires jar file specification
Syntaxe : java [options]  [args...]
   (pour exécuter une classe)
   ou  java [options] -jar  [args...]
   (pour exécuter un fichier JAR)
   ou  java [options] -m [/] [args...]
   java [options] --module [/] [args...]
   (pour exécuter la classe principale dans un module)
[...]
(sorry for the french output)

Second here is a diff output:

$ diff -C 4 openjdk-11-jexec.c openjdk-17-jexec.c
*** openjdk-11-jexec.c2023-03-20 17:31:50.797625352 +0100
--- openjdk-17-jexec.c2023-03-20 17:32:32.765543947 +0100
***
*** 167,178 
  }

  /* Get the path to the java binary, which is in a known position relative
   * to our current position, which is in argv[0]. */
! if (getJavaPath(JDK_BASE_DIR "/lib/jexec", java, RELATIVE_DEPTH) != 0) {
  errorExit(errno, MISSING_JAVA_MSG);
  }
- argi++;
  alen = (argc + 2) * (sizeof (const char *));
  if (alen <= 0 || alen > INT_MAX / sizeof(char *)) {
  errorExit(errno, BAD_ARG_MSG);
  }
--- 167,177 
  }

  /* Get the path to the java binary, which is in a known position relative
   * to our current position, which is in argv[0]. */
! if (getJavaPath(argv[argi++], java, RELATIVE_DEPTH) != 0) {
  errorExit(errno, MISSING_JAVA_MSG);
  }
  alen = (argc + 2) * (sizeof (const char *));
  if (alen <= 0 || alen > INT_MAX / sizeof(char *)) {
  errorExit(errno, BAD_ARG_MSG);
  }



The two source files have been retrieved using Debian Code Search.

Regards,
Patrice

Bug#1033245: php-common: phpquery doesn't retrieve fpm version installed

[Azerttyu]

Package: php-common
Version: 2:93+0~20221211.45+debian11~1.gbpdb4dcc
Severity: normal

Dear Maintainer,

   * What led up to the situation?

phpquery doesn't return fpm version installed. In my usecase php 8.2 is not
installed with fpm behavior.

Error looks come from https://salsa.debian.org/php-team/php-
defaults/-/blob/main/php-helper#L203 where fpm directory restriction is not
took in consideration.

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

I've executed "phpquery -s fpm -V"

   * What was the outcome of this action?

8.2
8.1
8.0
7.4
7.3
7.2
7.1
7.0
5.6

   * What outcome did you expect instead?

8.1
8.0
7.4
7.3
7.2
7.1
7.0
5.6


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


-- System Information:

Bug#1032428: firefox: Menu handling with the mouse is broken

[Vincent Lefevre]

Control: retitle -1 firefox: Menu handling with the mouse is broken with some 
window managers
Control: found -1 111.0-1

This is reproducible with fvwm (2.x), fvwm3 and twm.

And as said at https://bugzilla.mozilla.org/show_bug.cgi?id=1820542#c22
setting widget.gtk.grab-pointer to 0 avoids this brokenness, but yields
another one: the menus close as soon as the mouse pointer leaves them,
which is rather annoying too (though less confusing).

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

Bug#1033244: unblock: armci-mpi/0.3.1~beta-7

[Drew Parsons]

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

Please unblock package armci-mpi

[ Reason ]

armci-mpi 0.3.1~beta-7 makes some small changes to test management
that will be bookworm management more reliable. Source was
occasionally and randomly failing, evidently when only 1 cpu was
available (armci-mpi usually uses 2 processes for testing).  s390x
fails debci tests with mpich.

armci-mpi/0.3.1~beta-7 restricts build-time testing to 1 process if
only 1 cpu is available.  It switches off mpich tests on s390x in
debian/tests.  

So tests should pass more reliably and s390x won't show a "false"
failure (the failure is real but is known. No point making bookworm
continue to fail on s390x. Better to let it just monitor openmpi
operations).


[ Impact ]

If not accepted, s390x will show debci failure, when in fact openmpi
tests should be passing (an openmpi failure should not be treated as
"not a regression").

Also binNMUs may occasionally fail (if only 1 cpu is provided for the
build)

[ Tests ]

debci tests are passing as normal
s390x now reports as passing (with openmpi, skipping mpich)

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

[ Checklist ]
  [x ] all changes are documented in the d/changelog
  [x ] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in testing

[ Other info ]

Our default MPI is openmpi.  The mpich build is provided to enable an
mpich build of nwchem that supports multinode execution (with the env
variable documented in nwchem/7.0.2-4).

armci-mpi might now migrate after 20 day testing.  I've filed this
unblock request to complement the unblock request for nwchem/7.0.2-4,
since nwchem/7.0.2-4 was built against armci-mpi/0.3.1~beta-7
(it uses static libraries, no problem in practice but better for
bookworm to have the matching package versions)

unblock armci-mpi/0.3.1~beta-7
diff -Nru armci-mpi-0.3.1~beta/debian/changelog 
armci-mpi-0.3.1~beta/debian/changelog
--- armci-mpi-0.3.1~beta/debian/changelog   2022-03-07 13:07:13.0 
+0100
+++ armci-mpi-0.3.1~beta/debian/changelog   2023-03-19 14:08:54.0 
+0100
@@ -1,3 +1,12 @@
+armci-mpi (0.3.1~beta-7) unstable; urgency=medium
+
+  * Team upload.
+  * run build-time tests on only 1 process if only 1 CPU is available.
+Closes: #1031064.
+  * debian/tests: don't run mpich tests on s390x. Closes: #1009772.
+
+ -- Drew Parsons   Sun, 19 Mar 2023 14:08:54 +0100
+
 armci-mpi (0.3.1~beta-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru armci-mpi-0.3.1~beta/debian/rules armci-mpi-0.3.1~beta/debian/rules
--- armci-mpi-0.3.1~beta/debian/rules   2022-03-07 13:07:13.0 +0100
+++ armci-mpi-0.3.1~beta/debian/rules   2023-03-19 14:08:54.0 +0100
@@ -49,8 +49,9 @@
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test:
set -e; \
+   ncpu=`nproc`; if [ $${ncpu} -gt 1 ]; then ncpu=2; fi;\
for mpi_flavor in $(TEST_MPI_FLAVORS); do \
- $(MAKE) -C $(CURDIR)/build-$${mpi_flavor} -k check 
MPIEXEC="mpiexec.$${mpi_flavor} -np 2" ARMCI_USE_WIN_ALLOCATE=1 || cat 
$(CURDIR)/build-$${mpi_flavor}/test-suite.log; \
+ $(MAKE) -C $(CURDIR)/build-$${mpi_flavor} -k check 
MPIEXEC="mpiexec.$${mpi_flavor} -np $${ncpu}" ARMCI_USE_WIN_ALLOCATE=1 || cat 
$(CURDIR)/build-$${mpi_flavor}/test-suite.log; \
done
 endif
 
diff -Nru armci-mpi-0.3.1~beta/debian/tests/control 
armci-mpi-0.3.1~beta/debian/tests/control
--- armci-mpi-0.3.1~beta/debian/tests/control   2022-03-07 13:07:13.0 
+0100
+++ armci-mpi-0.3.1~beta/debian/tests/control   2023-03-19 14:08:54.0 
+0100
@@ -15,3 +15,4 @@
  debhelper, dh-autoreconf,
  gcc
 Restrictions: allow-stderr
+Architecture: !s390x

Bug#1033243: puppet: apt install puppet and puppet modules clash with official upstream repo

[Renato Gallo]

Package: puppet
Version: 7.23.0
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainers,

At work I must install foreman and puppet using the official upstream repos for
a testing environment which are
cat puppet7.list
# Puppet 7 bullseye Repository
deb http://apt.puppetlabs.com bullseye puppet7

cat foreman.list
deb http://deb.theforeman.org/ bullseye nightly
deb http://deb.theforeman.org/ plugins nightly

problem being that the puppet debian version is not 7.23.0 the upstream dep
package has been named puppet7-release (not just puppet) and after having
installed a module via apt I find myself in a broken condition where apt
absolutely wants to install the old version of puppet (even when I try to
uninstall it) which breaks the foreman nightly installation. Can you please I
pray you upgrade the debian repo so that it follows the upstream one ?

else can you tell me how can I set up my preferences so that only the upstream
repo is considered ?

I have tried setting priority 1001 but it doesn't seem to work for all the
packages

Thanks in advance





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

Kernel: Linux 6.2.7 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, 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 puppet depends on:
pn  puppet-agent  

puppet recommends no packages.

puppet suggests no packages.

Bug#1033242: unblock: nwchem/7.0.2-4

[Drew Parsons]

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

Please unblock package nwchem

[ Reason ]

nwchem-mpich had a problem running over multiple nodes with mpich,
discussed at https://github.com/nwchemgit/nwchem/issues/633

It was a problem in mpich which got fixed in mpich 4.0.3, but
currently we have mpich 4.0.2.  The workaround for nwchem is to set
the environment variable ARMCI_USE_WIN_ALLOCATE=0

The need for this workaround is documented in a README.Debian, added
in nwchem/7.0.2-4

[ Impact ]

Without this patch, users may be unaware of the environment variable
setting required to run nwchem over multiple nodes (with mpich)

[ Tests ]

This is a documentation update, no source changes, debci tests
continue to pass (or fail on some arches as before, no regression)

[ Risks ]

Documentation update only. No source change. Negligible rish.

[ Checklist ]
  [x ] all changes are documented in the d/changelog
  [x ] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in testing

unblock nwchem/7.0.2-4
diff -Nru nwchem-7.0.2/debian/changelog nwchem-7.0.2/debian/changelog
--- nwchem-7.0.2/debian/changelog   2022-03-10 17:20:23.0 +0100
+++ nwchem-7.0.2/debian/changelog   2023-03-19 15:01:42.0 +0100
@@ -1,3 +1,13 @@
+nwchem (7.0.2-4) unstable; urgency=medium
+
+  * Team upload.
+  * create nwchem-mpich.README.Debian to document the need to use
+ARMCI_USE_WIN_ALLOCATE=0 when running nwchem with MPICH 4.0.2
+(binary nwchem.mpich, fixed in mpich 4.0.3).
+See upstream Issue#633.
+
+ -- Drew Parsons   Sun, 19 Mar 2023 15:01:42 +0100
+
 nwchem (7.0.2-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru nwchem-7.0.2/debian/nwchem-mpich.README.Debian 
nwchem-7.0.2/debian/nwchem-mpich.README.Debian
--- nwchem-7.0.2/debian/nwchem-mpich.README.Debian  1970-01-01 
01:00:00.0 +0100
+++ nwchem-7.0.2/debian/nwchem-mpich.README.Debian  2023-03-19 
15:01:42.0 +0100
@@ -0,0 +1,38 @@
+Running NWChem with MPICH
+-
+
+tldr:
+   set ARMCI_USE_WIN_ALLOCATE=0 when running nwchem.mpich
+
+
+When nwchem.mpich is run over multiple processes, it may give an error
+e.g. on 2 processes
+
+ iter   energy  gnorm gmax   time
+ - --- - - 
+ 1  -75.9473154351  8.06D-01  3.50D-01  0.2
+  ga_iter_lsolve: convergence stagnant ... aborting solve
+ Increased level shift to 2.00
+  ga_iter_lsolve: convergence stagnant ... aborting solve
+
+
+or on 3 processes
+
+ Symmetry analysis of molecular orbitals - initial
+  -
+
+ sym_movecs_adapt: orbital10 negative proj. 
+   1.00D+00 -2.08D-05 -1.04D-05 -5.55D-17
+ 
+ sym_movecs_adapt: negative proj   0
+ ...
+ For further details see manual section: No section for this category  


 
+[0] ARMCI Error: 0:sym_movecs_adapt: negative proj:
+Abort(-1) on node 0 (rank 0 in comm 496): application called 
MPI_Abort(comm=0x8402, -1) - process 0
+
+
+When this happens, the fix is to set the environment variable
+
+  ARMCI_USE_WIN_ALLOCATE=0
+
+For more discussion, see https://github.com/nwchemgit/nwchem/issues/633

Bug#1033240: Unblock: swe-data

[Stanislas Marquis]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: jald...@debian.org, s...@astrorigin.com

Hello,

I am requesting a review and unblock for a non-key package, 'swe-data'  [1].

The new version fixes the following bug: #1031657  [2].
Missing information in the d/control file did not allow a smooth transition
from bullseye to bookworm.

The fix was tested with first, installation of the packages from bullseye,
then installation of packages from sid. Everything went fine.

You can find the related source debdiff in attachment.

Thanks for attention.


[1] https://tracker.debian.org/pkg/swe-data
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031657
diff -Nru swe-data-4.0-2022/debian/changelog 
swe-data-4.0-2022/debian/changelog
--- swe-data-4.0-2022/debian/changelog  2023-02-08 12:46:57.0 
+0100
+++ swe-data-4.0-2022/debian/changelog  2023-02-27 10:21:27.0 
+0100
@@ -1,9 +1,9 @@
-swe-data (4.0-2022-1.1) unstable; urgency=medium
+swe-data (4.0-2022-2) unstable; urgency=medium

-  * Non-maintainer upload.
-  * Source-only upload.
+  * Add Replaces+Breaks info to swe-standard-data (closes: #1031657).
+  * Add multiarch hints to swe-basic-data, swe-sat-data.

- -- Adrian Bunk   Wed, 08 Feb 2023 13:46:57 +0200
+ -- Stanislas Marquis   Mon, 27 Feb 2023 10:21:27 +0100

 swe-data (4.0-2022-1) unstable; urgency=medium

diff -Nru swe-data-4.0-2022/debian/control 
swe-data-4.0-2022/debian/control
--- swe-data-4.0-2022/debian/control2022-11-11 01:41:55.0 
+0100
+++ swe-data-4.0-2022/debian/control2023-02-27 08:15:11.000
00 +0100
@@ -12,12 +12,17 @@
 Package: swe-basic-data
 Section: libs
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
 Suggests:
  libswe-doc (>= 2.10.03),
  swe-standard-data (= ${binary:Version}),
  swe-extra-data (= ${binary:Version}),
+Replaces:
+ swe-standard-data (<< 4.0-2022),
+Breaks:
+ swe-standard-data (<< 4.0-2022),
 Description: Swiss Ephemeris library (basic set of ephemeris files).
  This set of ephemeris files covers the recent past, contemporary period and
  near future (1800 to 2399 CE). Also included are the static data files for
@@ -56,6 +61,7 @@
 Package: swe-sat-data
 Section: libs
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
 Suggests:


signature.asc
Description: OpenPGP digital signature

Bug#1033241: Unsupported PHP configuration for Zabbix when upgrading from bullseye to testing (bookworm)

[Leigh Brown]

Package: zabbix
Version: 6.0.13+dfsg-1

I upgraded a VM running Zabbix from bullseye to testing (bookworm). This 
upgraded PHP to version

8.2, which is not supported by Zabbix version 6.0.13.

When attempting to access the web front end, the screen is filled with 
deprecated function errors,

and therefore it is not usable:

Creation of dynamic property CList::$attributes is deprecated 
[zabbix.php:22 → require_once() → ZBase->run() → ZBase->processRequest() 
→ ZBase->processResponseFinal() → CView->getOutput() → include() → 
CWidget->show() → CWidget->toString() → get_prepared_messages() → 
makeMessageBox() → CList->__construct() → CTag->__construct() in 
include/classes/html/CTag.php:58]
Creation of dynamic property CList::$tagname is deprecated 
[zabbix.php:22 → require_once() → ZBase->run() → ZBase->processRequest() 
→ ZBase->processResponseFinal() → CView->getOutput() → include() → 
CWidget->show() → CWidget->toString() → get_prepared_messages() → 
makeMessageBox() → CList->__construct() → CTag->__construct() in 
include/classes/html/CTag.php:59]
Creation of dynamic property CList::$paired is deprecated [zabbix.php:22 
→ require_once() → ZBase->run() → ZBase->processRequest() → 
ZBase->processResponseFinal() → CView->getOutput() → include() → 
CWidget->show() → CWidget->toString() → get_prepared_messages() → 
makeMessageBox() → CList->__construct() → CTag->__construct() in 
include/classes/html/CTag.php:60]

[and so on]

According to the release notes of version 6.0.14, it now supports PHP 
8.2.


I am using the following package versions:

libapache2-mod-php8.2 8.2.2-3
php 2:8.2+93
php-bcmath 2:8.2+93
php-common 2:93
php-gd 2:8.2+93
php-mbstring 2:8.2+93
php-pgsql 2:8.2+93
php-xml 2:8.2+93
php8.2 8.2.2-3
php8.2-bcmath 8.2.2-3
php8.2-cli 8.2.2-3
php8.2-common 8.2.2-3
php8.2-gd 8.2.2-3
php8.2-mbstring 8.2.2-3
php8.2-opcache 8.2.2-3
php8.2-pgsql 8.2.2-3
php8.2-readline 8.2.2-3
php8.2-xml 8.2.2-3
zabbix-agent 1:6.0.13+dfsg-1+b1
zabbix-frontend-php 1:6.0.13+dfsg-1
zabbix-server-pgsql 1:6.0.13+dfsg-1+b1

Regards,

Leigh.

Bug#980316: Update on packaging corepack

[Pirate Praveen]

On Thu, 16 Mar 2023 10:23:53 +0100 Israel Galadima 
 wrote:

> Hi,
>
> Michael and I have done some packaging work for corepack.
> Of note, we have updated clipanion and packaged some dependencies of
> proxy-agent.
>
> Although, some of our work is awaiting uploads because of the freeze.
>
> Regards.

We tried to update yarnpkg as part of an outreachy project (in two 
rounds), but we could not complete it in time for bookworm. As shared 
by Israel, we made some good progress and we hope to be able to do it 
in trixie. I request bookworm-ignore tags for these bugs (as such there 
is no immediate breakage, just unmaintained upstreams for these 
packages). Hopefully we can handle any security updates ourselves.


Additionally, even though yarnpkg itself is old, the presence of the 
package makes it easy to obtain a newer yarnpkg. In gitlab, I already 
use the packaged yarnpkg command to install a newer yarnpkg[1]. It is 
also very common in nodejs world to use specific version of yarnpkg for 
each project, these are typically installed in .yarn directory for each 
project.


yarnpkg: 980316,958686, 1002902, 980316
node-har-validator: 1024575
node-request: 956423
node-request-capture-har: 1002901

[1] 
https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/rake-tasks.sh#L44

runuser -u ${gitlab_user} -- sh -c 'yarnpkg set version berry'

Bug#1033239: libsoup-3.0-0: Crash when adding a new calendar in gnome-calendars

[Alberto Garcia]

Package: libsoup-3.0-0
Version: 3.2.2-2
Severity: important
X-Debbugs-Cc: be...@igalia.com

Dear Maintainer,

I'm not sure if this is a problem in libsoup or in gnome-calendar,
but here are the steps to reproduce it:

Open gnome-calendar, go to Calendars -> Manage Calendars -> 
  Add Calendar -> type 'https://' in the address bar and wait for a few seconds

Here's what happens:

Thread 22 "pool-gnome-cale" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f3704bae6c0 (LWP 44978)]
0x7f37149d6f98 in soup_message_cleanup_response (msg=0x0) at 
../libsoup/soup-message.c:1843
1843soup_message_headers_clear (priv->response_headers);
(gdb) bt
#0  0x7f37149d6f98 in soup_message_cleanup_response (msg=0x0) at 
../libsoup/soup-message.c:1843
#1  0x7f37149e2279 in soup_session_append_queue_item 
(session=0x7f36dc01c770 [SoupSession], msg=0x0, async=0, 
cancellable=0x5574be64bb20 [GCancellable]) at ../libsoup/soup-session.c:1330
#2  0x7f37149e65a2 in soup_session_send (session=0x7f36dc01c770 
[SoupSession], msg=0x0, cancellable=0x5574be64bb20 [GCancellable], 
error=0x7f3704bad9d8) at ../libsoup/soup-session.c:3190
#3  0x5574bd3429c2 in  ()
#4  0x5574bd3421a4 in  ()
#5  0x7f3714e69793 in g_task_thread_pool_thread 
(thread_data=0x7f36e4002480, pool_data=) at 
../../../gio/gtask.c:1454
#6  0x7f3714ca16ca in g_thread_pool_thread_proxy (data=) at 
../../../glib/gthreadpool.c:352
#7  0x7f3714ca0cfd in g_thread_proxy (data=0x5574c3b10580) at 
../../../glib/gthread.c:831
#8  0x7f3714700fd4 in start_thread (arg=) at 
./nptl/pthread_create.c:442
#9  0x7f371478166c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

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

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

Versions of packages libsoup-3.0-0 depends on:
ii  glib-networking 2.74.0-4
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-8
ii  libglib2.0-02.74.6-1
ii  libgssapi-krb5-21.20.1-1
ii  libnghttp2-14   1.52.0-1
ii  libpsl5 0.21.2-1
ii  libsoup-3.0-common  3.2.2-2
ii  libsqlite3-03.40.1-2
ii  zlib1g  1:1.2.13.dfsg-1

libsoup-3.0-0 recommends no packages.

libsoup-3.0-0 suggests no packages.

-- no debconf information

Bug#1033159: terminology: When using vim with Terminology the underline atribute gets turned on when scrolling.

[Ross Vandegrift]

Control: -1 tags moreinfo

Hi Jon,

On Sat, Mar 18, 2023 at 03:16:14PM +, Jon Westgate wrote:
> How to produce:
> open vim inside terminology enit a file that is larger than the
> terminal and requires scrolling (it shows best with a 2 page document
> with a reasonable coverage of text) simply scroll up of down past the
> current view point and you will note that new text has the underline
> atribute set. Scrolling back up will result in off screen text being
> rendered with underline attribute set as it comes back down into view.

I've seen this bug occasionally, thanks for the details.  I suspect it's
a bug in terminology, but I can't reproduce with my current window a
large log file I happen to have lying around.

Could you provide some more info?

- what's your window geometry?
- can you provide a sample file (or generation instructions) that
  trigger it?
- what do you mean "scrolling"? (scrolling in vim via mouse or keyboard
  vs. scrolling back in the terminology scrollback buffer)

Thanks,
Ross

Bug#1033237: Wrong Package

[Jannick Loch]

I must admit that i had the nvidia-driver package in my clipboard and 
this bug relates to the debian


kernel team, not the nvidia team. This bug can be closed

Bug#1032351: wireplumber.service: fails to start, reporting 'Failed to connect to session bus'

[James Addison]

Followup-For: Bug #1032351
Control: archive -1

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[James Addison]

Followup-For: Bug #1032347
Control: archive -1

Bug#1033238: Missing Image for linux-image-6.1.0-7-amd64

[Jannick Loch]

Package: linux-image-amd64
Version: 6.1.0-7

Durimg my update routine, i notice that the build for amd64 is missing, so that 
i would broke my installation when i want to
upgrade my system. I dont know whether the package still needs time to build.



I am using Debian GNU/Linux SID with X11 and the Kernel 6.1.15

Bug#1033237: Missing Image for linux-image-6.1.0-7-amd64

[Jannick Loch]

Package: nvidia-driver
Version: 6.1.0-7

Durimg my update routine, i notice that the build for amd64 is missing, so that 
i would broke my installation when i want to
upgrade my system. I dont know whether the package still needs time to build.

I am using Debian GNU/Linux SID with X11 and the Kernel 6.1.15

Bug#1033236: unblock: apktool/2.7.0+dfsg-5

[Hans-Christoph Steiner]

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

Please unblock package apktool

[ Reason ]

To fix the RC bug #1033226.

[ Impact ]

The core feature of `apktool build` will not work at all because it can't find a 
JAR.


[ Tests ]

I added a new test to cover a full cycle:

apktool decode
check if extracted file exists
apktool build
check if new APK file exists

[ Risks ]

Its a trivial fix, just fixing a symlink, I see no risks.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock apktool/2.7.0+dfsg-5diff --git a/debian/changelog b/debian/changelog
index d439603..1884587 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+apktool (2.7.0+dfsg-5) unstable; urgency=medium
+
+  * fix broken symlink to commons-text.jar (Closes: #1033226)
+
+ -- Hans-Christoph Steiner   Mon, 20 Mar 2023 14:00:20 +0100
+
 apktool (2.7.0+dfsg-4) unstable; urgency=medium
 
   * fix arch detection for Depends:
diff --git a/debian/links b/debian/links
index 2c167db..779d62e 100644
--- a/debian/links
+++ b/debian/links
@@ -2,7 +2,7 @@ usr/share/java/antlr3-runtime.jar 
usr/share/apktool/antlr3-runtime.jar
 usr/share/java/commons-cli.jar usr/share/apktool/commons-cli.jar
 usr/share/java/commons-io.jar usr/share/apktool/commons-io.jar
 usr/share/java/commons-lang3.jar usr/share/apktool/commons-lang3.jar
-usr/share/java/commons-text-1.9.jar usr/share/apktool/commons-text-1.9.jar
+usr/share/java/commons-text.jar usr/share/apktool/commons-text.jar
 usr/share/java/guava.jar usr/share/apktool/guava.jar
 usr/share/java/snakeyaml.jar usr/share/apktool/snakeyaml.jar
 usr/share/java/stringtemplate.jar usr/share/apktool/stringtemplate.jar
diff --git a/debian/tests/control b/debian/tests/control
index 298f6e5..af602dd 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,4 @@
 # urzip.apk comes from https://github.com/eighthave/urzip via 
https://gitlab.com/fdroid/fdroidserver
-Test-Command: apktool d debian/tests/urzip.apk && test -e 
urzip/smali/info/guardianproject/urzip/UnZipper.smali
+Test-Command: apktool d debian/tests/urzip.apk && test -e 
urzip/smali/info/guardianproject/urzip/UnZipper.smali && apktool b urzip/ && 
test -e urzip/dist/urzip.apk
 Depends: apktool
 Restrictions: allow-stderr

Bug#1033235: torbrowser launcher fails to start due to an non-empty directory

[Santiago R.R.]

Package: torbrowser-launcher
Version: 0.3.6-2
Severity: important

Hi!

When trying to launch torbrowser, I am getting this:

santiago@bartik ~> torbrowser-launcher
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.6
https://github.com/micahflee/torbrowser-launcher
Traceback (most recent call last):
  File "/usr/bin/torbrowser-launcher", line 30, in 
torbrowser_launcher.main()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/__init__.py", line 
76, in main
common = Common(tor_browser_launcher_version)
 
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/common.py", line 62, 
in __init__
self.torbrowser12_rename_old_tbb()
  File "/usr/lib/python3/dist-packages/torbrowser_launcher/common.py", line 
185, in torbrowser12_rename_old_tbb
os.rename(abs_filename, self.paths["tbb"]["dir_tbb"])
OSError: [Errno 39] Directory not empty: 
'/home/santiago/.local/share/torbrowser/tbb/x86_64/tor-browser_es-AR' -> 
'/home/santiago/.local/share/torbrowser/tbb/x86_64/tor-browser'

I get a similar error with torbrowser-launcher --settings

The workaround is to remove .local/share/torbrowser/

I may suppose this is just me, and it works for others.

Cheers,

 -- Santiago


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

Kernel: Linux 6.1.0-0-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.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 torbrowser-launcher depends on:
ii  ca-certificates20211016
ii  gnupg  2.2.40-1
ii  libdbus-glib-1-2   0.112-3
ii  libgtk-3-0 3.24.36-4
ii  python33.11.2-1
ii  python3-gpg1.18.0-3+b1
ii  python3-packaging  23.0-1
ii  python3-pyqt5  5.15.9+dfsg-1
ii  python3-requests   2.28.1+dfsg-1
ii  python3-socks  1.7.1+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.4.7.13-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  3.0.8-3

-- no debconf information

Bug#1033170: libitext-rups-java: Does not work at all

[tony mancill]

Hi Jorge,

On Sun, Mar 19, 2023 at 10:45:32PM -0400, Jorge Moraleda wrote:
> Hello Tony,
> 
> I propose that we either reduce the severity, ignore the bug for the
> > bookworm release cycle, or remove only the libitext-rups-java binary
> > package from bookworm.
> >
> Thank you. I believe the appropriate action is #3 (remove libitext-rups-java
> binary
> package from bookworm) because it is useless as it stands.

Action #3 (removing libitext-rups-java) makes it much more difficult to
fix the bug in unstable or experimental, and will make it impossible to
introduce the fix to a bookworm point release.  It means that the
package will have to go through NEW again to be be part of Debian.

However, given the low popcon count and the brokenness of the package,
that may be the best path.  If there are users of libitext-rups-java who
think otherwise, now would be the time to speak up.

>  Two other comments for the record
> (1) An apt list libitext*
> reveals
> libitext-java/testing,unstable,testing,now 2.1.7-13 all
> [installed,automatic]
> libitext-rtf-java/testing,unstable,testing 2.1.7-13 all
> libitext-rups-java/testing,unstable,testing 2.1.7-13 all
> libitext1-java/testing,unstable,testing 1.4-7 all
> libitext5-java/testing,unstable,testing 5.5.13.3-2 all
> 
> I am not familiar with libitext, so I don't know if we really need to
> maintain multiple versions of it in the repo. From the comments on the
> ubuntu bug report. It appears that versions 1 and 2 are hopelessly updated,
> but I do see that there are indeep packages that depend on the older
> versions.

Not everything is going to run on the latest version, and there are
multiple versions of the package in Debian because they are needed.
libitext1-java is a dependency of libdoxia-java, which is part of Maven.
I don't see how the multiple itext packages are directly related to the
problem with rups.
 
> 
> (2) If there is a maintainer for libitext-rups-java I would suggest they
> upgrade to use at least libitext5-java and then reupload to
> experimental. (Version 5 is not so old, but upstream is already at 7).

Upgrade requests should be filed as wishlist bugs against the source
package.  However, if we're going to remove libitext-rups-java from the
distribution, then a potential packager could start fresh with a new,
separate package for https://github.com/itext/i7j-rups.

Returning to the focus of this bug, let's wait to see if there are
other opinions regarding rups.  If not, I will prepare an upload of the
libitext-java source package that removes the libitext-rups-java and
file the bugs needed to remove the binary.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#1033234: MariaDB-Server not installing

[Timothy M Butterworth]

package: mariadb-server

On Mon, Mar 20, 2023 at 10:02 AM Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> wrote:

> MariaDB
>
> On Mon, Mar 20, 2023 at 9:16 AM Timothy M Butterworth <
> timothy.m.butterwo...@gmail.com> wrote:
>
>> All,
>>
>> The mariadb-server package fails to install and generates error messages.
>>
>> apt install mariadb-server
>> Reading package lists... Done
>> Building dependency tree... Done
>> Reading state information... Done
>> Suggested packages:
>>  mailx mariadb-test netcat-openbsd
>> The following NEW packages will be installed:
>>  mariadb-server
>> 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
>> 120 not fully installed or removed.
>> Need to get 0 B/3,581 kB of archives.
>> After this operation, 54.5 MB of additional disk space will be used.
>> Preconfiguring packages ...
>> (Reading database ... 327299 files and directories currently installed.)
>> Preparing to unpack .../mariadb-server_1%3a10.11.2-1_amd64.deb ...
>> Failed to stop mariadb.service: Unit mariadb.service not loaded.
>> invoke-rc.d: initscript mariadb, action "stop" failed.
>> Failed to stop mysql.service: Unit mysql.service not loaded.
>> invoke-rc.d: initscript mysql, action "stop" failed.
>> Attempt to stop MariaDB/MySQL server returned exitcode 5
>> There is a MariaDB/MySQL server running, but we failed in our attempts to
>> stop it.
>> Stop it yourself and try again!
>> dpkg: error processing archive
>> /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb (--unpack):
>> new mariadb-server package pre-installation script subprocess returned
>> error exit status 1
>> Errors were encountered while processing:
>> /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb
>>
>> I only have mariadb-client installed. There are no mariadb or mysql unit
>> files even installed.
>>
>> Thanks
>>
>> Tim
>>
>>
>> --
>> ⢀⣴⠾⠻⢶⣦⠀
>> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
>> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
>> ⠈⠳⣄⠀⠀
>>
>
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

On Mon, Mar 20, 2023 at 09:48:36AM -0400, Jeremy Bícha wrote:

> This was a mistake in cherry-picking from the Experimental branch
> where I had previously applied
> https://salsa.debian.org/gnome-team/gnome-builder/-/commit/f87150bc

Maybe it's not a bad idea to let gir:Depends handle this instead, also
for bookworm. But either option is fine with me.

Berto

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Jeremy Bícha]

On Mon, Mar 20, 2023 at 7:15 AM Alberto Garcia  wrote:
> gnome-builder 43.6-2 switched the build dependency from WebtKitGTK 5.0
> to 6.0 since the former API is no longer available and is going away.
>
> However it still contains a dependency on gir1.2-webkit2-5.0, so it
> effectively depends on both 5.0 and 6.0 API builds of WebKitGTK.

This was a mistake in cherry-picking from the Experimental branch
where I had previously applied
https://salsa.debian.org/gnome-team/gnome-builder/-/commit/f87150bc

Your patch is more minimal for Debian Bookworm. Thank you!

Jeremy

Bug#1033233: spurious colour output from git init

[Zefram]

Package: git
Version: 1:2.30.2-1+deb11u2
Severity: minor

"git init" outputs a bunch of lines marked "hint:".  For me it's emitting
those lines with a bunch of ANSI colour escape sequences, despite me
having configured color.ui=never in my ~/.gitconfig.  Some strace output:

write(2, "\33[33mhint: Using 'master' as the"..., 90) = 90
write(2, "\33[33mhint: is subject to change."..., 87) = 87
write(2, "\33[33mhint: of your new repositor"..., 80) = 80
write(2, "\33[33mhint: \33[m\n", 15)= 15
write(2, "\33[33mhint: \tgit config --global "..., 61) = 61
write(2, "\33[33mhint: \33[m\n", 15)= 15
write(2, "\33[33mhint: Names commonly chosen"..., 80) = 80
write(2, "\33[33mhint: 'development'. The ju"..., 86) = 86
write(2, "\33[33mhint: \33[m\n", 15)= 15
write(2, "\33[33mhint: \tgit branch -m "..., 36) = 36

And a configuration extract:

$ sed -n 6,7p ~/.gitconfig
[color]
ui = never

-zefram

Bug#1033232: linux: Please enable support for RZ/G2M-HiHope

[Vincent Stehlé]

Package: linux
Version: 6.1.0-6-arm64
Severity: normal
File: linux

Dear Maintainer,

The RZ/G2M HiHope is the reference board for the Renesas RZ/G2M MPU.
https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg2m-hihope-rzg2m-reference-board

I think the Debian kernel is missing only a few configuration options in
debian/config/arm64/config to run on that board.

For SoC support and UART console:

  CONFIG_ARCH_RENESAS=y
  CONFIG_SERIAL_SH_SCI=y
  CONFIG_ARCH_R8A774A1=y

For SD and eMMC support:

  CONFIG_GPIO_RCAR=m
  CONFIG_MMC_SDHI=m

For USB2 support:

  CONFIG_PHY_RCAR_GEN3_USB2=m

All those options are set by default upstream.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/configs/defconfig

Could you please add those configuration options to the Debian kernel?

Best regards,
Vincent.

Bug#1033231: postgrey: postinst does not create user or install default config files

[Roel van Meer]

Package: postgrey
Version: 1.37-1.1
Severity: important
Tags: patch

Dear Maintainer,

Sometime last year, the postinst file was removed from the postgrey
package. This was done in commit [efe56824 - Remove all debconf bits for
the port migration in 1.32-3].

So, the current package does not install required config files in
/etc/postgrey, and it doesn't create a user to run as.

As it seems the removal of these specific actions was unintended, and
postgrey needs both actions to be completed before it can run, it would
be nice if these could be reinstated.

There's an open merge request doing this: 
https://salsa.debian.org/debian/postgrey/-/merge_requests/1

Could this perhaps be merged before bookworm is released?

Best regards, Roel

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

Kernel: Linux 6.1.0-6-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: sysvinit (via /sbin/init)

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

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

postgrey suggests no packages.

-- debconf information excluded

Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency

[Gianfranco Costamagna]

Source: webkit2gtk
Version: 2.40.0-2
Severity: serious

Hello, for some reasons, now webkit2gtk is not linking anymore libGLESv2.so.2 
causing surf to fail autopkgtests on arm64 and armhf

autopkgtest [05:16:23]: test command3: timeout -v 5m xvfb-run 
debian/tests/test_text.sh
autopkgtest [05:16:23]: test command3: [---

(surf:7196): dbind-WARNING **: 05:16:24.536: AT-SPI: Error retrieving 
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.a11y.Bus was not provided by any .service files
Could not determine the accessibility bus address
Could not read style file: /home/debci/.surf/styles/default.css
Couldn't open libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: 
No such file or directory
web process terminated: crashed


Something is trying to load libGLESv2.so.2, but according to webkitgtk build 
log, that library is now statically built inside webkitgtk?

What is really strange, the detection works, and then its statically built the 
embedded one?
-- Found OpenGLES2: /usr/lib/aarch64-linux-gnu/libGLESv2.so (found version 
"3.2")


[2681/6827] : && /usr/bin/cmake -E rm -f lib/libGLESv2.a && /usr/bin/ar crT lib/libGLESv2.a  
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/egl_ext_stubs.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/egl_stubs.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_egl_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_egl_ext_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_1_0_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_2_0_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_3_0_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_3_1_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_3_2_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/entry_points_gles_ext_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/global_state.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/libGLESv2_autogen.cpp.o 
Source/ThirdParty/ANGLE/CMakeFiles/GLESv2.dir/src/libGLESv2/proc_table_egl_autogen.cpp.o && 
/usr/bin/ranlib lib/libGLESv2.a && :

Why ANGLE did change its behaviour is unknown to me, and I find difficult to 
understand if this is an upstream bug or a Debian specific one.

Gianfranco



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name

[Andreas Hasenack]

The extra randomness suffix happens when you login via ssh/gssapi.

On Sun, Mar 19, 2023 at 9:09 PM Benjamin Kaduk  wrote:
>
> Hmm, on my local machines (one running Debian, one running Ubuntu) I appear
> to be seeing the expected default /tmp/krb5cc_%{uid} behavior.
> I couldn't quite follow how your credentials were obtained; were they
> perhaps obtained as part of the login process?  The PAM configuration might
> well be relevant in that case.
>
> -Ben
>

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

Control: tags -1 patch

debdiff attached

Berto
diff -Nru gnome-builder-43.6/debian/changelog 
gnome-builder-43.6/debian/changelog
--- gnome-builder-43.6/debian/changelog 2023-03-16 01:29:37.0 +0100
+++ gnome-builder-43.6/debian/changelog 2023-03-20 12:45:40.0 +0100
@@ -1,3 +1,11 @@
+gnome-builder (43.6-3) unstable; urgency=medium
+
+  * Team upload
+  * debian/control.in: depend on gir1.2-webkit-6.0 instead of 5.0
+(Closes: #1033224)
+
+ -- Alberto Garcia   Mon, 20 Mar 2023 12:45:40 +0100
+
 gnome-builder (43.6-2) unstable; urgency=medium
 
   * debian/gbp.conf, debian/control.in: Branch for bookworm
diff -Nru gnome-builder-43.6/debian/control gnome-builder-43.6/debian/control
--- gnome-builder-43.6/debian/control   2023-03-16 01:29:37.0 +0100
+++ gnome-builder-43.6/debian/control   2023-03-20 12:45:40.0 +0100
@@ -6,7 +6,7 @@
 Section: editors
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Jeremy Bicha 
+Uploaders: Alberto Garcia , Jeremy Bicha 
 Build-Depends: appstream-util,
at-spi2-core ,
ca-certificates ,
@@ -77,7 +77,7 @@
  gir1.2-jsonrpc-1.0 (>= 3.42.0),
  gir1.2-panel-1 (>= 1.0.0),
  gir1.2-peas-1.0 (>= 1.34.0),
- gir1.2-webkit2-5.0,
+ gir1.2-webkit-6.0,
  python3-gi,
  libvala-dev,
  clang,
diff -Nru gnome-builder-43.6/debian/control.in 
gnome-builder-43.6/debian/control.in
--- gnome-builder-43.6/debian/control.in2023-03-16 01:29:37.0 
+0100
+++ gnome-builder-43.6/debian/control.in2023-03-20 12:45:40.0 
+0100
@@ -73,7 +73,7 @@
  gir1.2-jsonrpc-1.0 (>= 3.42.0),
  gir1.2-panel-1 (>= 1.0.0),
  gir1.2-peas-1.0 (>= 1.34.0),
- gir1.2-webkit2-5.0,
+ gir1.2-webkit-6.0,
  python3-gi,
  libvala-dev,
  clang,

Bug#1033229: unblock: im-config/0.55-2

[Gunnar Hjalmarsson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-input-met...@lists.debian.org

Please unblock package im-config.

[ Reason ]

The file /etc/xdg/autostart/im-launch.desktop had an Exec line which 
proved to be incompatible with the parser of systemd boot. That Exec 
line has therefore been simplified in im-config 0.55-2.


[ Impact ]

The issue resulted in im-config failing to start the IM framework, e.g. 
fcitx5, when logging in to a Plasma (Wayland) session. That's an 
annoyance which will be fixed with the version in unstable.


[ Tests ]

Manually installed the binary built by version 0.55-2 of the im-config 
source, and confirmed that the bug was fixed as expected.


[ Risks ]

The change is a targeted trivial fix to address the issue at hand. Can't 
think of any adverse side effects.


[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing

--
Cheers,
Gunnar Hjalmarssondiff --git a/debian/changelog b/debian/changelog
index 
c5ae651c299c0765505947febdacd33e21490a5d..8f623fc6535339c94bee79c31ce9e891a888d3d5
 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+im-config (0.55-2) unstable; urgency=medium
+
+  * systemd boot compatible Exec line in im-launch.desktop
+- Fixes issue with the IM framework not being started automatically
+  when logging in to a Plasma (Wayland) session (closes: #1033097).
+
+ -- Gunnar Hjalmarsson   Mon, 20 Mar 2023 11:47:27 +0100
+
 im-config (0.55-1) unstable; urgency=medium
 
   * Set GTK_IM_MODULE in GNOME on Xorg sessions (closes: #1031227)
diff --git a/debian/patches/series b/debian/patches/series
index 
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..6639a6d9c04ac850f554da420891f57a857f0275
 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch
diff --git 
a/debian/patches/systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch 
b/debian/patches/systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch
new file mode 100644
index 
..1f0fdbc2aeae3757dc77e9f5f673d12c663d8150
--- /dev/null
+++ 
b/debian/patches/systemd_boot_compatible_Exec_line_in_im-launch.desktop.patch
@@ -0,0 +1,55 @@
+From: Gunnar Hjalmarsson 
+Date: Mon, 20 Mar 2023 09:55:59 +0100
+Subject: systemd boot compatible Exec line in im-launch.desktop
+
+im-launch.desktop is autostarted, and the Exec line has up to now
+contained a condition so /usr/bin/im-launch has only been started in
+wayland sessions.
+
+However, as from KDE Plasma 5.25 systemd boot is enabled by default,
+and that feature fails to parse the previous Exec line in
+im-launch.desktop. An example consequence is that fcitx5 is not started
+automatically at login to a KDE Plasma (Wayland) or Kubuntu (Wayland)
+session.
+
+This commit fixes the issue by moving the mentioned condition from
+im-launch.desktop to the top of /usr/bin/im-launch, resulting in an
+Exec line simple enough for systemd boot to parse.
+
+Bug-KDE: https://bugs.kde.org/show_bug.cgi?id=455252
+Bug-Debian: https://bugs.debian.org/1033097
+Origin: https://salsa.debian.org/input-method-team/im-config/-/commit/5a979231
+---
+ im-launch | 6 ++
+ im-launch.desktop | 2 +-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/im-launch b/im-launch
+index 4845f92..721a24a 100755
+--- a/im-launch
 b/im-launch
+@@ -13,6 +13,12 @@ if [ "x$1" = "x-h" ] || [ "x$1" = "x--help" ] || [ "x$1" = 
"x" ]; then
+ exit 1
+ fi
+ 
++if [ "$1" = 'true' ] && [ "$XDG_SESSION_TYPE" != 'wayland' ]; then
++# This program was autostarted, but was already run at the
++# start of an X session, so don't run it now too.
++exit 0
++fi
++
+ if [ "$IM_CONFIG_CHECK_ENV" = 1 ] && \
+[ "$IM_CONFIG_PHASE" = 1 ]; then
+ # If tweaked, keep hands off :-)
+diff --git a/im-launch.desktop b/im-launch.desktop
+index 7e3b624..e8d5e70 100644
+--- a/im-launch.desktop
 b/im-launch.desktop
+@@ -1,6 +1,6 @@
+ [Desktop Entry]
+ Name=im-launch
+-Exec=sh -c 'if [ "x$XDG_SESSION_TYPE" = "xwayland" ] ; then exec env 
IM_CONFIG_CHECK_ENV=1 im-launch true; fi'
++Exec=sh -c 'IM_CONFIG_CHECK_ENV=1 im-launch true'
+ TryExec=im-launch
+ Type=Application
+ NoDisplay=true

Bug#1005863: binutils: invalid opcode for Geode LX on i386

[James Addison]

Followup-For: Bug #1005863
X-Debbugs-Cc: ballo...@debian.org
Control: reassign -1 binutils 2.38-1

Reassigning this from package 'gcc' to 'binutils':

It looks like it is GNU binutils[1] (and in particular, the GNU assembler)
that is responsible for producing the assembly opcodes for a binary compiled
with gcc.

On Mon, 20 Mar 2023 11:27:40 +0100, Bill Allombert wrote:
> From a purely engineering perspective, without a way to address this problem,
> increasing the severity will not achieve much.

Yep, agreed.  I'd like to learn more about technical fix feasibility before
adjusting the severity.

There was a commit[2] in Y2010 of GNU binutils to stop emitting NOPL on (32bit)
i686 targets.. I'm wondering if it's possible that a regression since then may
have caused the opcodes to reappear.

(it continues to be equally likely that I've completely misunderstood and am
creating noise without making any useful progress)

[1] - https://www.gnu.org/software/binutils/

[2] - 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2210942396dab942a86cb6777c705554b84ebb0e

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[James Addison]

Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: p...@debian.org, ballo...@debian.org

Dear Maintainer and Éric-Martin (with Bill on carbon copy),

Please find linked below a previous release note from Debian 9.0 (stretch)
that we could use to provide relevant user guidance:

https://www.debian.org/releases/stretch/i386/release-notes/ch-information.html#i386-is-now-almost-i686

(I discovered this while reading a 2019 mailing list discussion[1])


On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote:
> Broadly speaking, detecting non-baseline instruction usage isn't
> possible without false positives, because the program could use runtime
> instruction selection based on the current CPU to avoid currently
> unavailable instructions, while the binary would still contain those
> instructions for use on other CPUs.
>
> https://wiki.debian.org/InstructionSelection
>
> Of course you could do the scanning and then use autopkgtests or manual
> tests to find out if the found programs work on the relevant CPUs.

Thank you, that makes sense.

I've run some ad-hoc script analysis[2] on a recent mirror of the bookworm i386
archive, and it appears that ~20% or so of packages are potentially affected in
that (so, in all likelihood, Debian is currently uninstallable and/or unusable
on Geode LX).

In theory I would like to run a comparative analysis against the snapshot
archives from previous points in time, but am not sure whether I'll get around
to doing that.


On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote:
> Perhaps lintian could add classification tags for the relevant CPU
> instructions and then the i386 port could have extra autopkgtest nodes
> that only process the packages detected by lintian.

That's not a bad idea.  Are there any reasons that that might _not_ be a good
idea before filing a wishlist bug?  (performance, implications of scanning
binary packages, ...)


[1] - https://lists.debian.org/debian-user/2019/04/msg01091.html

[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005863#48

Bug#1033228: gnome-initial-setup: when no users exist, privacy policy link for Mozilla location services doesn't work

[Simon McVittie]

Package: gnome-initial-setup
Version: 43.2-4
Severity: important
Tags: upstream fixed-upstream patch
Forwarded: https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/181

To reproduce, scenario 1:

* Have a bookworm installation (I used a qemu VM) with the GNOME desktop task
* Make sure root has a password set
* Log in as root
* Delete the non-root user that was created by d-i
* Reboot
* GNOME starts in "kiosk" mode with gnome-initial-setup running
* Select a language
* Select a keyboard layout
* The next page is "Privacy"
* Click the "_privacy policy_" link in the Location Services toggle

Expected result:

* Mozilla Location Service privacy policy opens in an embedded web browser
  widget within gnome-initial-setup itself

Actual result:

* Nothing happens



To reproduce, scenario 2 (lower-severity but illustrative):

* Log in as an expendable user, or create a new user account and log in
  for the first time
* If this is not the first time the user account has logged in, run:
  /usr/libexec/gnome-initial-setup --existing-user
  (GNOME will run this automatically for first-time logins)
* Select a language
* Select a keyboard layout
* The next page is "Privacy"
* Click the "_privacy policy_" link in the Location Services toggle

Expected result:

* Mozilla Location Service privacy policy opens in an embedded web browser
  widget within gnome-initial-setup itself

Actual result:

* Mozilla Location Service privacy policy opens in Firefox



Upstream fix in

(not yet tested in Debian).

I think we should fix this before bookworm. The kiosk mode is a relatively
rare use-case for Debian (a Debian installation will normally be more like
scenario 2) but inability to open the privacy policy link seems rather bad.

smcv

Bug#1030600: redis breaks python-fakeredis autopkgtest: Connection refused

[Chris Lamb]

Adrian Bunk wrote:

> Control: affects -1 src:beaker
[…]
> beaker has a FTBFS that looks similar, without fakeredis installed:
> https://buildd.debian.org/status/logs.php?pkg=beaker=1.12.1-1

Putting aside the question of the beaker FTBFS for a second, this
issue (ie. #1030600, ie. preventing redis from migrating…) is, as I
now believe, caused by the python-fakeredis testsuite being flaky.

I can reproduce this fairly easily:

  $ PYTHONPATH=. python3.11 -Wd -m pytest -v 
test/test_hypothesis.py::TestString::test
  […]
  test/test_hypothesis.py::TestString::test PASSED
   1 passed in 6.20s =

  $ PYTHONPATH=. python3.11 -Wd -m pytest -v 
test/test_hypothesis.py::TestString::test
  […]
  test/test_hypothesis.py::TestString::test PASSED
   1 passed in 6.20s =

  $ PYTHONPATH=. python3.11 -Wd -m pytest -v 
test/test_hypothesis.py::TestString::test
  […]
  test/test_hypothesis.py::TestString::test FAILED
  […]

In fact, Hypothesis is actually detecting this flakiness:

  E   hypothesis.errors.Flaky: Inconsistent data generation! Data
  generation behaved differently between different runs. Is
  your data generation depending on external state?

There might be other issues with redis (eg. the beaker FTBFS perhaps),
but given that the fakeredis testsuite is currently nondeterministic,
it's difficult to have something solid to reason from. :)

(For the avoidance of doubt, I don't maintain python-fakeredis.)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1033227: unblock: live-tasks-non-free-firmware/12.0.1

[Jonathan Carter]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: live-tasks-non-free-firmw...@packages.debian.org
Control: affects -1 + src:live-tasks-non-free-firmware

Please unblock package live-tasks-non-free-firmware

This is provides meta-packages on live systems to install
non-free firmware packages on those systems.

Sorry for it being so late, it depended on the firmware section itself
existing and being populated.

The package only provides the metapackages, for convenience, I'm
including the control file below:

"""
Source: live-tasks-non-free-firmware
Maintainer: Live Systems Maintainers 
Uploaders: Jonathan Carter 
Section: non-free-firmware/metapackages
Priority: optional
Build-Depends: debhelper-compat (= 13)
Standards-Version: 4.6.2
Vcs-Browser: https://salsa.debian.org/live-team/live-tasks-non-free-firmware
Vcs-Git: https://salsa.debian.org/live-team/live-tasks-non-free-firmware.git
Rules-Requires-Root: no

Package: live-task-non-free-firmware-pc
Architecture: all
Recommends: amd64-microcode, bluez-firmware, firmware-amd-graphics,
firmware-atheros, firmware-brcm80211, firmware-intel-sound,
firmware-ipw2x00, firmware-iwlwifi, firmware-linux,
firmware-linux-nonfree, firmware-realtek, firmware-sof-signed,
intel-microcode 
Suggests: vrms 
Description: selection of oft-used non-free-firmware shipped on live systems
 Provides non-free-firmware packages for Debian live systems.
 .
 Its dependencies, along with this package itself, is safe to remove, provided
 that your device does not depend on them in order to function.

Package: live-task-non-free-firmware-server
Architecture: all
Recommends: firmware-bnx2, firmware-bnx2x, firmware-cavium, firmware-myricom, 
firmware-netronome,
firmware-netxen, firmware-qlogic
Suggests: vrms
Description: provides firmware for server network and storage devices
 Provides non-free firmware packages for Debian live systems.
 .
 This package installs firmware packages for server devices.
 .
 Its dependencies, along with this package itself, is safe to remove, provided
 that your device does not depend on them in order to function.
"""

unblock live-tasks-non-free-firmware/12.0.1

thanks,

-Jonathan

Bug#1033226: java.lang.NoClassDefFoundError: org/apache/commons/text/StringEscapeUtils

[Hans-Christoph Steiner]

Package: apktool
Version: 2.7.0+dfsg-4
Severity: important

$ apktool build org.sajeg.fallingblocks_3
I: Using Apktool 2.7.0-dirty
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/commons/text/StringEscapeUtils
	at 
brut.androlib.meta.YamlStringEscapeUtils.unescapeString(YamlStringEscapeUtils.java:141)
	at 
brut.androlib.meta.ClassSafeConstructor$ConstructStringEx.construct(ClassSafeConstructor.java:58)
	at 
org.yaml.snakeyaml.constructor.Constructor$ConstructScalar.constructStandardJavaInstance(Constructor.java:452)
	at 
org.yaml.snakeyaml.constructor.Constructor$ConstructScalar.construct(Constructor.java:403)
	at 
org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:270)
	at 
org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:253)
	at 
org.yaml.snakeyaml.constructor.SafeConstructor.processDuplicateKeys(SafeConstructor.java:108)
	at 
org.yaml.snakeyaml.constructor.SafeConstructor.flattenMapping(SafeConstructor.java:81)
	at 
org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.constructJavaBean2ndStep(Constructor.java:252)
	at 
org.yaml.snakeyaml.constructor.Constructor$ConstructMapping.construct(Constructor.java:207)
	at 
org.yaml.snakeyaml.constructor.Constructor$ConstructYamlObject.construct(Constructor.java:358)
	at 
org.yaml.snakeyaml.constructor.BaseConstructor.constructObjectNoCheck(BaseConstructor.java:270)
	at 
org.yaml.snakeyaml.constructor.BaseConstructor.constructObject(BaseConstructor.java:253)
	at 
org.yaml.snakeyaml.constructor.BaseConstructor.constructDocument(BaseConstructor.java:207)
	at 
org.yaml.snakeyaml.constructor.BaseConstructor.getSingleData(BaseConstructor.java:191)

at org.yaml.snakeyaml.Yaml.loadFromReader(Yaml.java:477)
at org.yaml.snakeyaml.Yaml.loadAs(Yaml.java:470)
at brut.androlib.meta.MetaInfo.load(MetaInfo.java:70)
at brut.androlib.Androlib.readMetaFile(Androlib.java:280)
at brut.androlib.Androlib.build(Androlib.java:294)
at brut.androlib.Androlib.build(Androlib.java:287)
at brut.apktool.Main.cmdBuild(Main.java:263)
at brut.apktool.Main.main(Main.java:82)
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.text.StringEscapeUtils
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 23 more


The problem is a weird broken symlink "commons-text-1.9.jar":

 ~ $ ls -l /usr/share/apktool/
total 248
lrwxrwxrwx 1 root root 26 14. Feb 15:32 antlr3-runtime.jar -> 
../java/antlr3-runtime.jar

-rw-r--r-- 1 root root259 14. Feb 15:32 apktool-2.7.0.jar
-rw-r--r-- 1 root root  12849 14. Feb 15:32 apktool-cli.jar
-rw-r--r-- 1 root root 184646 14. Feb 15:32 apktool-lib.jar
lrwxrwxrwx 1 root root 20 14. Feb 15:32 baksmali.jar -> ../java/baksmali.jar
-rw-r--r-- 1 root root259 14. Feb 15:32 brut.apktool.jar
-rw-r--r-- 1 root root   2207 14. Feb 15:32 brut.j.common.jar
-rw-r--r-- 1 root root  16834 14. Feb 15:32 brut.j.dir.jar
-rw-r--r-- 1 root root  15930 14. Feb 15:32 brut.j.util.jar
lrwxrwxrwx 1 root root 23 14. Feb 15:32 commons-cli.jar -> 
../java/commons-cli.jar

lrwxrwxrwx 1 root root 22 14. Feb 15:32 commons-io.jar -> 
../java/commons-io.jar
lrwxrwxrwx 1 root root 25 14. Feb 15:32 commons-lang3.jar -> 
../java/commons-lang3.jar
lrwxrwxrwx 1 root root 28 14. Feb 15:32 commons-text-1.9.jar -> 
../java/commons-text-1.9.jar

lrwxrwxrwx 1 root root 19 14. Feb 15:32 dexlib2.jar -> ../java/dexlib2.jar
lrwxrwxrwx 1 root root 17 14. Feb 15:32 guava.jar -> ../java/guava.jar
lrwxrwxrwx 1 root root 17 14. Feb 15:32 smali.jar -> ../java/smali.jar
lrwxrwxrwx 1 root root 22 14. Feb 15:32 smali-util.jar -> 
../java/smali-util.jar
lrwxrwxrwx 1 root root 21 14. Feb 15:32 snakeyaml.jar -> 
../java/snakeyaml.jar
lrwxrwxrwx 1 root root 26 14. Feb 15:32 stringtemplate.jar -> 
../java/stringtemplate.jar

lrwxrwxrwx 1 root root 19 14. Feb 15:32 xmlunit.jar -> ../java/xmlunit.jar
lrwxrwxrwx 1 root root 16 14. Feb 15:32 xpp3.jar -> ../java/xpp3.jar
 ~ $ ls -l /usr/share/apktool/../java/commons-text-1.9.jar
ls: cannot access '/usr/share/apktool/../java/commons-text-1.9.jar': No such 
file or directory

 ~ $


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/16 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 apktool depends on:
ii  aapt  1:10.0.0+r36-10
ii  

Bug#1033225: openboard: Does not monitor user files added while running

[Yvan Masson]

Package: openboard
X-Debbugs-Cc: y...@masson-informatique.fr
Version: 1.6.4+dfsg-1+b1
Severity: normal

Dear Maintainers,

If OpenBoard is running and the user adds a picture inside 
~/Pictures/OpenBoard/, the picture does not immediately appears inside 
OpenBoard's documents, it only appears when OpenBoard is restarted.


As a workaround, it is possible to drag and drop the picture from the 
file manager to OpenBoard's documents. In this case, OpenBoard takes 
care of copying the file to ~/Pictures/OpenBoard/.


The same symptom also appears with sounds and videos.

I did not see this issue reported upstream: do not hesitate to ask if 
you want me to report upstream.


Regards,
Yvan

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openboard depends on:
ii  libavcodec59  7:5.1.2-3
ii  libavformat59 7:5.1.2-3
ii  libavutil57   7:5.1.2-3
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libgomp1  12.2.0-14
ii  libpoppler126 22.12.0-2+b1
ii  libqt5concurrent5 5.15.8+dfsg-3
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5multimedia5 5.15.8-2
ii  libqt5multimediawidgets5  5.15.8-2
ii  libqt5network55.15.8+dfsg-3
ii  libqt5printsupport5   5.15.8+dfsg-3
ii  libqt5svg55.15.8-2
ii  libqt5webkit5 5.212.0~alpha4-30
ii  libqt5widgets55.15.8+dfsg-3
ii  libqt5xml55.15.8+dfsg-3
ii  libquazip5-1  0.9.1-3
ii  libssl3   3.0.8-1
ii  libstdc++612.2.0-14
ii  libswresample47:5.1.2-3
ii  libswscale6   7:5.1.2-3
ii  libx11-6  2:1.8.4-2
ii  openboard-common  1.6.4+dfsg-1
ii  zlib1g1:1.2.13.dfsg-1

openboard recommends no packages.

Versions of packages openboard suggests:
ii  openboard-contrib  1.6.4+dfsg-1

-- no debconf information


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033224: gnome-builder: Depends on obsolete gir1.2-webkit2-5.0 package

[Alberto Garcia]

Package: gnome-builder
Version: 43.6-2
Severity: serious
Justification: Policy 7.2

gnome-builder 43.6-2 switched the build dependency from WebtKitGTK 5.0
to 6.0 since the former API is no longer available and is going away.

However it still contains a dependency on gir1.2-webkit2-5.0, so it
effectively depends on both 5.0 and 6.0 API builds of WebKitGTK.

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

Berto

Bug#1025453: Is there any update

[Dylan Aïssi]

Le sam. 18 mars 2023 à 14:51, graeme vetterlein
 a écrit :
>
> I, for one, have had no sound for the past 4 months. Not personally critical 
> as it's an unstable dev system, not main dev machine.
>

Do you have no sound at all or choppy sound like you said in [1].
Have you tried using speakers not connected via HDMI? I guess it is related
to HDMI connection, can you fill a bug on the upstream bug tracker [2]?

[1] https://bugs.debian.org/1025453#40
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues

Bug#1033223: chromium: #ozone-platform-hint should be set to auto

[Bastien Roucariès]

Package: chromium
Version: 111.0.5563.64-1
Severity: serious
Tags: patch
Justification: unusable under wayland kde

Dear Maintainer,

Under wayland chromium tab are unresponsible to mouse.

#ozone-platform-hint set to auto instead of default help here to detect
wayland.

Could you set this option ?

At least at this freeze time could you add a note on README.Debian ?

Note that in order to change the flags manually, I have executed "chromium
--ozone-platform=wayland"

Bastien

PS: set to patch because changing an option is like a patch


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

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

Versions of packages chromium depends on:
ii  chromium-common111.0.5563.64-1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-2
ii  libdbus-1-31.14.6-1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1
ii  libevent-2.1-7 2.1.12-stable-5+b1
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgbm122.3.3-1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-1
ii  libgtk-3-0 3.24.37-2
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenjp2-7   2.5.0-1+b1
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libre2-9   20220601+dfsg-1+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.1
ii  libwebpdemux2  1.2.4-0.1
ii  libwebpmux31.2.4-0.1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.1+b3
ii  libxnvctrl0525.85.05-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  43.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1
ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]5.27.2-1
ii  zlib1g 1:1.2.13.dfsg-1

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

Versions of packages chromium suggests:
pn  chromium-driver  
pn