Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore

[Jonathan McDowell]

On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote:
> Control: tags 994758 - bookworm-ignore
> 
> Hi Adrian,
> 
> Thanks for caring.
> 
> On 25-02-2023 14:30, Adrian Bunk wrote:
> > With the bookworm-ignore for #994758,
> 
> I'll admit that I misjudged that bug; with this message I'll clear the
> bookworm-ignore tag.
> 
> > bullseye and bookworm
> > will ship libsgutils2-2 packages with different so-name.
> 
> Although the transition freeze has started long time ago, it seems that
> doing a proper transition is the best way to fix this issue. If somebody is
> up to the task to prepare the upload, we can ask ftp-master to process the
> upload swiftly. (Please upload to experimental to avoid the ftp-master from
> rejecting the package immediately and to enable reviewing if that's not done
> before the upload.)

This does not look overly hard and I have some familiarity with the
package having uploaded in the past. If no one else is already looking
at it I'll aim to have a version with a libsgutils2-1.46 library package
uploaded to experimental by the end of today.

J.

-- 
/-\ |   If at first you don't succeed,
|@/  Debian GNU/Linux Developer |   create an "NT" version.
\-  |


signature.asc
Description: PGP signature

Bug#1032179: fill my Librem5 logs with “Failed to read input level” messages

[Daniel Dehennin]

Package: iio-sensor-proxy
Version: 3.0-2
Severity: minor

Dear Maintainer,

I installed the latest Mobian image on my Librem5 phone and my logs are full of 
messages:

mars 01 08:29:40 mobian iio-sensor-prox[634]: Failed to read input level at 
/sys/devices/platform/soc@0/3080.bus/30a3.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw:
 Failed to read from file 
“/sys/devices/platform/soc@0/3080.bus/30a3.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw”:
 Invalid argument

root@mobian:/home/mobian# ls -lh 
'/sys/devices/platform/soc@0/3080.bus/30a3.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw'
-rw-r--r-- 1 root root 4.0K Feb 28 18:29 
/sys/devices/platform/soc@0/3080.bus/30a3.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw

root@mobian:/home/mobian# cat 
'/sys/devices/platform/soc@0/3080.bus/30a3.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw'
cat: 
'/sys/devices/platform/soc@0/3080.bus/30a3.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw':
 Invalid argument


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1-librem5 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
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)

Versions of packages iio-sensor-proxy depends on:
ii  libc6   2.36-8
ii  libglib2.0-02.74.5-1
ii  libgudev-1.0-0  237-2

iio-sensor-proxy recommends no packages.

Versions of packages iio-sensor-proxy suggests:
ii  systemd  252.5-2

-- no debconf information

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature

Bug#1031990: r-cran-memisc_0.99.31.3+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Control: forwarded -1 https://github.com/melff/memisc/issues/63

Hi,

Am Tue, Feb 28, 2023 at 07:06:49PM + schrieb Thorsten Alteholz:
> this package mixes software that is licensed under GPL-2 with software that 
> is licensed under GPL-3+.
> Please explain in your debian/copyright why this should be possible.
> 
> Thanks!
>  Thorsten
> 
> [1] https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

I've forwarded this question upstream[1].

Kind regards
 Andreas.

[1] https://github.com/melff/memisc/issues/63

-- 
http://fam-tille.de

Bug#1031999: r-cran-mclogit_0.9.6-1_amd64.changes REJECTED

[Andreas Tille]

Control: tags -1 pending
Control: block -1 by 1031990

Am Tue, Feb 28, 2023 at 07:06:49PM + schrieb Thorsten Alteholz:
> please add the README.source for the data files.

Uh, sorry, this somehow slipped through.  Its fixed in Git but I wait
for clarification for memisc license which I asked upstream about.

Kind regards and thanks for checking
Andreas. 

-- 
http://fam-tille.de

Bug#1032140: [External] Re: Bug#1032140: Lenovo Z16 Install issue

[Cyril Brulebois]

Control: reassign -1 src:linux 6.1.12-1
Control: forwarded -1 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/667
Control: tag -1 patch

Cyril Brulebois  (2023-03-01):
> Thanks for this confirmation, I'll file the MR against linux later on.

Doing so now.


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


signature.asc
Description: PGP signature

Bug#1032180: openttd: fix build on riscv64 [PATCH]

[Gianfranco Costamagna]

Source: openttd
Version: 13.0-2
tags: patch

Hello, I created and submitted upstream a patch to fix a build failure with 
riscv64 and others, due to missing latomic flag on link.

Changing atomic to atomic is enough to avoid the library completely

https://github.com/OpenTTD/OpenTTD/pull/10527/files

G.

Bug#1031423: rocminfo: rocm_agent_enumerator PermissionError in readFromKFD

[Cordell Bloor]

I went to submit my patch for this bug upstream and found that a fix is 
already scheduled for ROCm 5.5. The upstream patch is not publicly 
available yet, but I was happy to at least confirm that upstream 
considers this behaviour to be a bug.

Bug#1032020: [pkg-apparmor] Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[intrigeri]

Control: tag -1 + unreproducible
Control: severity -1 minor

Hi,

Guillaume B. (2023-02-28):
> Installing fresh sid profiles with both previously stated packages (version
> 3.0.8-3 and 1.35 respectively), I have not seen that specific mistake made.
>
> It may have come from a loose AppArmor profile but, just to be sure, no
> such open "/** r," found in latest sid-provided
> apparmor-profiles/apparmor-profiles-extra Chromium AppArmor profile.

I've looked at the Git history of the relevant apparmor* packages and
found no trace of them having ever distributed a Chromium profile
with a "/** r," rule.

> dpkg-query: no path found matching pattern  /etc/apparmor.d/usr.bin.chromium

This shows that no Debian package is currently maintaining that file.

Frankly, I have no idea how this rule landed on your filesystem, but
I really don't see how this problem could have been directly caused by
a Debian package or upgrade.

Cheers,
-- 
intrigeri

Bug#1032020: [pkg-apparmor] Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

[Guillaume B.]

Hi,

Thanks for clearing it up.

I might just take time and find that faulty profile if it ever existed.

Thanks for clearing everything up.

Cheers

On Wed, Mar 1, 2023, 09:48 intrigeri  wrote:

> Control: tag -1 + unreproducible
> Control: severity -1 minor
>
> Hi,
>
> Guillaume B. (2023-02-28):
> > Installing fresh sid profiles with both previously stated packages
> (version
> > 3.0.8-3 and 1.35 respectively), I have not seen that specific mistake
> made.
> >
> > It may have come from a loose AppArmor profile but, just to be sure, no
> > such open "/** r," found in latest sid-provided
> > apparmor-profiles/apparmor-profiles-extra Chromium AppArmor profile.
>
> I've looked at the Git history of the relevant apparmor* packages and
> found no trace of them having ever distributed a Chromium profile
> with a "/** r," rule.
>
> > dpkg-query: no path found matching pattern
> /etc/apparmor.d/usr.bin.chromium
>
> This shows that no Debian package is currently maintaining that file.
>
> Frankly, I have no idea how this rule landed on your filesystem, but
> I really don't see how this problem could have been directly caused by
> a Debian package or upgrade.
>
> Cheers,
> --
> intrigeri
>

Bug#1029760: evince: AppArmor prevents opening PDF files stored on Google drive

[intrigeri]

Hi,

>> Does it end with ".pdf", like name="/run//pdf", or does it
>> look different?

Since then, Laurent shared details privately (thanks!) and we now know
that the path passed to name="..." does not end with a known
extension, so we can't match on that :/

This is, unfortunately, a good example of the limitations of AppArmor
for desktop apps.

Short term, we need to choose between:

- Option A: works out of the box for files stored behind gvfs, impact
  of exploitation of Evince is higher by default

  Add a rule like the one you suggested initially.

- Option B: opening files stored behind gvfs requires tweaking files
  in /etc, impact of exploitation of Evince is lower by default

I think the maintainers of the app are generally the best placed to
decide what's best.

My 2 cts: personally, given how wide open the Evince profile already
is, I don't think the marginal security improvement of option B is
worth the UX pain, so I would go for option A.


And in passing, another 2 cts: mid term, as long as we ship desktop
apps as Debian packages weakly-sandboxed with AppArmor, as opposed to
Flatpak, perhaps we should consider making them use Desktop Portals
(e.g. via GTK_USE_PORTAL=1). This would allow us to make the AppArmor
policy much stricter, and would solve the whole class of UX problems
that this bug is part of.

Cheers,
-- 
intrigeri

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hi tony,

[...]
> I'm not able to reproduce the autopkgtest failure locally running in
> clean sid chroots.  First, I build the dojo source package and ran the
> autopkgtest against those binaries.  When that didn't fail, I pulled the
> binary packages from the archive and ran the autopkgtest against those.
> Again, no failures.
> 
> I see the autopkgtest failure when I run against a bookworm chroot.
> 
> So it seems like the migration of rhino will resolve the test failure.
> (Or I'm missing something fundamental.)

Strange. I downloaded the source package and ran the autopkgtests manually. I
symlinked js.jar and shrinksafe.jar into util/shrinksafe and then I executed
the runner.sh script. I got the same error message "Cannot set property "dojo"
of null to "[object Object]". Anyway, are the autopkgtests really useful if
they prevent rhino from migration to testing every time we update the package,
even if everything works as expected? The same tests already run at build time.




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

Bug#1032181: checkbashisms: replace with shellchek -s dash?

[Gioele Barabucci]

Package: devscripts
Version: 2.23.2
Severity: wishlist

Dear devscripts maintainers,

what do you think of replacing checkbashisms with a wrapper over 
`shellcheck -s dash`?


shellcheck has evolved to perform all the checks that checkbashisms does 
and many others. A cursory review of the open bugs against checkbashisms 
that report false positives or false negatives shows that pretty much 
all of them are non present in shellcheck (e.g. #531326, #609765, 
#807278, #994718, ...).


Shellcheck also provides more comprehensive explanations and its use of 
codified error messages (e.g. SC3052) allows users to quickly find 
relevant online discussions. (See #556113, #856051.)


Relying on checkbashims also gives developers a false sense of security 
because it lacks many of the more minute checks performed by shellcheck.


Regards,

--
Gioele Barabucci

Bug#1032160: tfortune FTCBFS: multiple reasons

[Helmut Grohne]

On Tue, Feb 28, 2023 at 11:13:24PM +0100, Andre Noll wrote:
> > The immediate failure is failing to find the lopsub library since it
> > configures for the build architecture. This happens as no --build nor --host
> > is passed which would have happened automatically if dh_auto_configure could
> > be used.  Thus it'll have to be passed manually.
> 
> Do you recommend to get rid of the override_dh_auto_configure target
> in debian/rules?

As far as I understand it, you cannot. dh_auto_configure would pass
options that configure does not understand.

> I'm in favor of switching to something more standard, but I will
> need your help. What's the best way forward to improve on the current
> situation? Do you want me to apply your patch as is and push out the
> result to the public repo? Is there anything else I can do to make
> life easier for the Debian people?

If you are upstream, you can try making the build system behave more
like a standard autoconf one. We tend to expect that:
 * It uses a current version of autoconf that understands all options
   passed by dh_auto_configure (which could allow dropping the
   override).
 * Enabling use of dh_autoreconf.
 * Making the Makefile honour the settings (e.g. CC) detected by
   configure.

However, you may also choose to keep the present behaviour and apply my
patch to make it cross buildable.

I recommend scheduling this update for the trixie cycle as bookworm is
frozen and this is not an important bug.

Helmut

Bug#1029720: [Pkg-nagios-devel] Bug

[Markus Köberl]

Some new kernel include the string starting with "Linux version" 2 times in the 
vmlinuz- image.
While the first line ends for example with "# SMP PREEMPT_DYNAMIC.*" missing 
the "1" as mentioned in this bug report the 2nd line matches the /proc/version 
string exactly.
Therefore changing the filter "head -n1" to "tail -n1" would fix it for a 
bookworm kernel.
This works with kernels for buster, bullseye and bookworm.

For kernels from other repositories for surface and proxmox another change is 
necessary to support zst compression.
But for the proxmox kernel the "tail -n1" does not solve the problem because 
the "Linux version" string in the vmlinuz- image ends with 
" ()" which is not included in /proc/version

Therefore the following patch does not solve all problems but still might help 
finding a better solution:

136c136
<   echo "UNKNOWN: filter command '$filter' missing, perhaps 
install xz-utils, lz4 or lzop?" >&2
---
>   echo "UNKNOWN: filter command '$filter' missing, perhaps 
> install xz-utils, lz4, lzop or zstd?" >&2
164a165,166
>   # zst compressed image
>   cat_vmlinux "$image" "\x28\xb5\x2f\xfd"  "zstdcat"  0
204c206
<   on_disk_version="`get_image_linux "$on_disk" | $STRINGS 
| grep 'Linux version' | head -n1`"
---
>   on_disk_version="`get_image_linux "$on_disk" | $STRINGS 
> | grep 'Linux version' | tail -n1`"


Successfully tested with:
linux-image-4.19.0-23-amd64
linux-image-6.0.0-0.deb11.6-amd64
linux-image-6.1.0-5-amd64
linux-image-6.1.13-surface

But does not help with:
pve-kernel-5.15.85-1-pve


regards
Markus Köberl
-- 
Markus Koeberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: markus.koeb...@tugraz.at

smime.p7s
Description: S/MIME cryptographic signature

Bug#1032182: libtpms: New upstream version with vulnerability fixes

[Bastian Germann]

Source: libtpms
Version: 0.9.2-3
Severity: important
Control: tags -1 security

Please import the latest upstream version 0.9.6 which has CVE-2023-1017 and 
CVE-2023-1018 fixed.

Bug#1030048: pgpool2: CVE-2023-22332

[Christoph Berg]

Re: Adrian Bunk
> > CVE-2023-22332[0]:

> Christoph, is there a reason why this cannot be fixed with a backport
> or an upgrade to 4.3.5?

Just time (and the RFH on the package that has been open since 2014
and no activity since 2016).

I've just uploaded 4.3.5 to unstable.

Thanks for the poke,
Christoph

Bug#1032179: fill my Librem5 logs with “Failed to read input level” messages

[Daniel Dehennin]

Hello.

After some discussion on the Mobian matrix room, I started my Librem5
wit hall kill switch on and there is no more failing messages.

Regards.
-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature

Bug#1014593: amd64-microcode: Updated version for bullseye/stable?

[Christian Kastner]

Hi,

On 2022-07-08 15:36, Michael Prokop wrote:
> https://wiki.debian.org/Microcode#Microcode_update_support_for_current_and_older_Debian_releases:
> 
> | Debian 11, codename "Bullseye" is supported, and will receive
> | updates both through the bullseye-backports official backports
> | repository (faster than point-releases), and through Debian stable
> | point-releases and security updates.
> 
> Users seem to be relying on this (as I was just asked about policies
> when microcode updates are updated/backported).
> 
> Would you please consider updating the package in stable? :)
> Thanks!

I'd like to second this.

This [1] popped up in my newsfeed today. I only then realized that the
amd64-microcode package in stable is from 2019.

Since microcode updates are generally fixes, sometimes even important
security fixes, I guess updates to stable (rather than going via
backports) would be permissible?

Best,
Christian

[1] https://lkml.org/lkml/2023/2/22/33

Bug#1031700: Audio s/pdif selection in gnome quick settings (bookworm )

[Dylan Aïssi]

Hi,

Le mer. 22 févr. 2023 à 18:27,  a écrit :
>
> the issue, looks like this description
>
> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6207

If it is the same bug then it is not a pipewire bug but a gnome-shell
bug which was fixed in gnome-shell 43.3.
This version of gnome-shell has migrated into debian/testing three days ago.

Are you still able to reproduce it or is it solved?

Best,
Dylan

Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches

[Shengjing Zhu]

Control: tags -1 + patch

On Wed, Mar 1, 2023 at 3:10 PM Shengjing Zhu  wrote:
> I realized there probably was no need for runtime detection after some
> discussion with others.
>
> After all, it has already dispatched the right _time64 function. But
> on i386, the only case to use _time64 function is when compiled with
> D_TIME_BITS=64.
> So there shouldn't be two variants of stat64 struct. It's just
> fakeroot is using the wrong one.
> fakeroot should compile its all time64 funcs with D_TIME_BITS=64, then
> it should get the right struct. (only these _time64 parts, so be in
> separate files.)
>
> I'm still exploring this idea, but anyone more familiar with autoconf
> would be helpful!
>

Please see the patch
https://salsa.debian.org/clint/fakeroot/-/merge_requests/22

-- 
Shengjing Zhu

Bug#1032183: libgusb-dev: missing dependency on libjson-glib-1.0-dev

[Simon McVittie]

Package: libgusb-dev
Version: 0.4.5-1
Severity: serious
Justification: Policy 7.2

To reproduce:

* Have a minimal Debian chroot or container
* apt install libgusb-dev
* pkg-config --cflags --libs gusb

Expected result: success, compiler flags are shown

Actual result:

> + pkg-config --cflags --libs gusb gobject-2.0 glib-2.0
> Package json-glib-1.0 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `json-glib-1.0.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'json-glib-1.0', required by 'gusb', not found

I'll send the obvious patch when I have a bug number.

It's easy to reproduce this class of issues with an autopkgtest like
the one added by the attached patch, and running autopkgtest before upload
can detect and prevent these missing dependencies before they reach Debian.

smcv

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

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

Versions of packages libgusb-dev depends on:
ii  gir1.2-gusb-1.0 0.4.5-1
ii  libc6   2.36-8
ii  libglib2.0-02.74.5-1
ii  libglib2.0-dev  2.74.5-1
ii  libgusb20.4.5-1
ii  libjson-glib-1.0-0  1.6.6-1
ii  libusb-1.0-0-dev2:1.0.26-1

libgusb-dev recommends no packages.

libgusb-dev suggests no packages.

-- no debconf information
>From e5c5697632a33b004cba3c687357f7408a591904 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 1 Mar 2023 10:25:00 +
Subject: [PATCH 1/2] Add a superficial autopkgtest for libgusb-dev

This checks whether the -dev package has all the required dependencies
to link a simple program with libgusb.

Signed-off-by: Simon McVittie 
---
 debian/tests/control |  5 +
 debian/tests/libgusb-dev | 46 
 2 files changed, 51 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/libgusb-dev

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..2a91858
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,5 @@
+Tests: libgusb-dev
+Restrictions: allow-stderr, superficial
+Depends:
+ build-essential,
+ libgusb-dev,
diff --git a/debian/tests/libgusb-dev b/debian/tests/libgusb-dev
new file mode 100755
index 000..22bec3f
--- /dev/null
+++ b/debian/tests/libgusb-dev
@@ -0,0 +1,46 @@
+#!/bin/sh
+# Copyright 2023 Simon McVittie
+# SPDX-License-Identifier: LGPL-2.1-or-later
+
+set -eux
+
+if [ -n "${AUTOPKGTEST_ARTIFACTS-}" ]; then
+WORKDIR="$AUTOPKGTEST_ARTIFACTS"
+else
+WORKDIR="$(mktemp -d)"
+trap 'cd /; rm -fr "$WORKDIR"' 0 INT QUIT ABRT PIPE TERM
+fi
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cat >> "$WORKDIR"/trivial.c <
+
+#include 
+#include 
+
+int main (int argc, char *argv[])
+{
+  GError *error = NULL;
+  GUsbContext *context = NULL;
+
+  context = g_usb_context_new (&error);
+
+  if (context == NULL)
+g_error ("%s", error->message);
+
+  g_object_unref (context);
+  return 0;
+}
+EOF
+
+cd "$WORKDIR"
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -otrivial trivial.c $("${CROSS_COMPILE}pkg-config" --cflags --libs gusb gobject-2.0 glib-2.0)
+./trivial
-- 
2.39.2

Bug#1032184: kdocker stopped working

[only4com]

Package: kdocker
Version: 5.4-1

Debian distribution: bookworm

$ uname -a
Linux linbox 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) 
x86_64 GNU/Linux

libc-bin Version: 2.36-8

KDE Plasma Version: 5.26.90
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-5-amd64 (64-bit)
Graphics Platform: Wayland


Dear Maintainer,

since last updates (KDE/Plasma/QT/kdocker ? ) kdocker doesn't work any more:

- mouse pointer does not change
- the left clicked window will not be docked
- kdocker stays running in background and can be terminated only with "kill -9"
- kdocker call in the console does not output any error

Bug#1032183: libgusb-dev: missing dependency on libjson-glib-1.0-dev

[Simon McVittie]

Control: tags -1 + patch

On Wed, 01 Mar 2023 at 10:52:44 +, Simon McVittie wrote:
> I'll send the obvious patch when I have a bug number.

Attached, or available from
https://salsa.debian.org/efi-team/libgusb/-/merge_requests/6

smcv
>From 0b82db8fc0333e9d16e3e0eb9c7fa77b6d47f34c Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 1 Mar 2023 10:25:00 +
Subject: [PATCH 1/2] Add a superficial autopkgtest for libgusb-dev

This checks whether the -dev package has all the required dependencies
to link a simple program with libgusb.

Reproduces: #1032183
Signed-off-by: Simon McVittie 
---
 debian/tests/control |  5 +
 debian/tests/libgusb-dev | 46 
 2 files changed, 51 insertions(+)
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/libgusb-dev

diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..2a91858
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,5 @@
+Tests: libgusb-dev
+Restrictions: allow-stderr, superficial
+Depends:
+ build-essential,
+ libgusb-dev,
diff --git a/debian/tests/libgusb-dev b/debian/tests/libgusb-dev
new file mode 100755
index 000..22bec3f
--- /dev/null
+++ b/debian/tests/libgusb-dev
@@ -0,0 +1,46 @@
+#!/bin/sh
+# Copyright 2023 Simon McVittie
+# SPDX-License-Identifier: LGPL-2.1-or-later
+
+set -eux
+
+if [ -n "${AUTOPKGTEST_ARTIFACTS-}" ]; then
+WORKDIR="$AUTOPKGTEST_ARTIFACTS"
+else
+WORKDIR="$(mktemp -d)"
+trap 'cd /; rm -fr "$WORKDIR"' 0 INT QUIT ABRT PIPE TERM
+fi
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cat >> "$WORKDIR"/trivial.c <
+
+#include 
+#include 
+
+int main (int argc, char *argv[])
+{
+  GError *error = NULL;
+  GUsbContext *context = NULL;
+
+  context = g_usb_context_new (&error);
+
+  if (context == NULL)
+g_error ("%s", error->message);
+
+  g_object_unref (context);
+  return 0;
+}
+EOF
+
+cd "$WORKDIR"
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -otrivial trivial.c $("${CROSS_COMPILE}pkg-config" --cflags --libs gusb gobject-2.0 glib-2.0)
+./trivial
-- 
2.39.2

>From d234a8ca7dde5c8d2b0b031270156ea4933e7724 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Wed, 1 Mar 2023 10:39:55 +
Subject: [PATCH 2/2] d/control: Add missing dependency libgusb-dev ->
 libjson-glib-dev

Closes: #1032183
Signed-off-by: Simon McVittie 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 3a1fa8d..98a8f1c 100644
--- a/debian/control
+++ b/debian/control
@@ -26,6 +26,7 @@ Depends: libgusb2 (= ${binary:Version}),
  ${misc:Depends},
  gir1.2-gusb-1.0 (= ${binary:Version}),
  libglib2.0-dev (>= 2.44.0),
+ libjson-glib-dev,
  libusb-1.0-0-dev
 Description: GLib wrapper around libusb1 - development files
  GUsb is a GObject wrapper for libusb1 that makes it easy to do
-- 
2.39.2

Bug#1032185: libgusb 0.4.5 uploaded during freeze, is it intended for Debian 12 'bookworm'?

[Simon McVittie]

Source: libgusb
Version: 0.4.5-1
Severity: important
X-Debbugs-Cc: debian-rele...@lists.debian.org

I notice that libgusb 0.4.5-1 was uploaded a few days ago. Is this package
intended to go into Debian 12 'bookworm'? It seems like a larger diff than
I would have expected at this stage in the release.

Debian has been in soft freeze since 2023-02-12. More information about the
freeze policy: .
.

If this version is intended for bookworm, RC bug #1032183 will need fixing.

If this version is not intended for bookworm, it should have been uploaded
to experimental; please talk to your co-maintainer about the best way to
revert to 0.3.x in unstable if necessary.

Thanks,
smcv

Bug#1009163: import-orig: please make --upstream-vcs-tag=%(version)s strip +dfsg/+ds repack suffixes

[Guido Günther]

Hi,
On Tue, Aug 09, 2022 at 01:07:34PM +0200, Guilhem Moulin wrote:
> Hi Guido,
> 
> On Tue, 09 Aug 2022 at 10:54:54 +0200, Guido Günther wrote:
> > We could fix the replacement to be empty:
> > 
> > https://github.com/agx/git-buildpackage/compare/master...ds
> > 
> > This causes trouble for people though that need this *and* to mangle the
> > version by other means.
> 
> That'd work for me, thanks!  Some ideas to cover other use-cases if
> desired:
> 
>  - Always strip ‘+ds(\.\d*)?’ and ‘+dfsg(\.\d*)?’ repack suffixes
>*after* version mangling.  After all, if upstream uses such suffixes
>in its tags or version number, then the revision has to be mangled so
>it doesn't collide with a repack suffix no?
>  - New option --upstream-vcs-tag-strip='\+ds(\.\d*)?$'

I wonder if a simple:

 --upstream-vcs-tag-strip

that defaults to 'on' would already do the trick (as stripping this
should be the norm (as you elaborate in your first point) and the option
is only there if people want the old behavior.

If that makes sense I'd be happy to apply a patch for this as I assume
this bits many pages that need to repack upstream tarballs *and* want
--upstream-vcs-tag

Cheers,
 -- Guido


>  - AFAIK substitution in tag formats currently support a single
>character; it could be changed so the remaining of the middle portion
>is stripped, so ‘%(version%.+ds%_)’ rewrites ‘1.2.3+ds’ to ‘1_2_3’
>and ‘%(version%.+ds%.)’ rewrite it to ‘1.2.3’.  Odd semantics though
>and not trivial to document…
> 
> cheers
> -- 
> Guilhem.

Bug#1014593: amd64-microcode: Updated version for bullseye/stable?

[Henrique de Moraes Holschuh]

Microcode updates are somewhat plagued with regressions, so usually I won't 
push them to stable without a reasonable level of feedback.  And that is a lot 
harder to come from AMD users than Intel users, for unknown-to-me reasons (I 
can speculate, but that's not helpful).

That said, with enough *it works* feedback, yes, we can push amd64-microcode 
updates to stable.

On Wed, Mar 1, 2023, at 07:09, Christian Kastner wrote:
>> Users seem to be relying on this (as I was just asked about policies
>> when microcode updates are updated/backported).

Really, you should rely on updated *firmware* if you can.  It still is the only 
place where you can actually trust a microcode update (from either AMD or 
Intel) to actually do all it was supposed to do.  I know for a fact the Intel 
ones disable sections of the update that cannot be activated when not loaded 
early enough.  For AMD, I know for a fact several updates of earlier processors 
were never shipped to users because they *must* be done by the firmware, 
nowadays maybe they do it like Intel.

> Since microcode updates are generally fixes, sometimes even important
> security fixes, I guess updates to stable (rather than going via
> backports) would be permissible?

Yes, they usually are.  We can even send them in as security updates when we 
get enough data to know it is going to fix a security issue **even when loaded 
by the O.S.* (see remark above) and that it is not causing serious 
regressions...

-- 
  Henrique de Moraes Holschuh 

Bug#1032023: intel-microcode: Use non-native package format

[Henrique de Moraes Holschuh]

tags 1032023 + wontfix  wishlist
thanks

No.  The quilt format is not suitable for this package.  It can be made to 
work, but it will result in an strictly worse source package.

I would have to switch to multi-upstream tarballs, and end up with a worse 
result: larger, and harder to handle. We need decent control of symlinks, and 
binary data for this package to avoid possible issues, diff/patch/quilt is 
*not* the appropriate tool.

Also, what we ship in intel-microcode is *not* what upstream ships, it is a 
curated, expanded version of the microcode data set using several past packages 
to still update older, EOLd processors (and we sometimes disable some microcode 
updates as well).

-- 
  Henrique de Moraes Holschuh 

Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore

[Jonathan McDowell]

On Wed, Mar 01, 2023 at 08:07:09AM +, Jonathan McDowell wrote:
> On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote:
> > On 25-02-2023 14:30, Adrian Bunk wrote:
> > > With the bookworm-ignore for #994758,
> > 
> > I'll admit that I misjudged that bug; with this message I'll clear the
> > bookworm-ignore tag.
> > 
> > > bullseye and bookworm
> > > will ship libsgutils2-2 packages with different so-name.
> > 
> > Although the transition freeze has started long time ago, it seems that
> > doing a proper transition is the best way to fix this issue. If somebody is
> > up to the task to prepare the upload, we can ask ftp-master to process the
> > upload swiftly. (Please upload to experimental to avoid the ftp-master from
> > rejecting the package immediately and to enable reviewing if that's not done
> > before the upload.)
> 
> This does not look overly hard and I have some familiarity with the
> package having uploaded in the past. If no one else is already looking
> at it I'll aim to have a version with a libsgutils2-1.46 library package
> uploaded to experimental by the end of today.

Now sitting in NEW for experimental:

https://ftp-master.debian.org/new/sg3-utils_1.46-2.html

I have confirmed:

 * It will not co-exist with the libsgutils2-2 package in bookworm
   (thanks to the versioned breaks/replaces)
 * It will co-exist with the libsgutils2-2 package in bullseye (which is
   1.45-1 and has no overlapping files)
 * Operation of the sg3-utils package with this new build

It turns out I do not have access to the salsa git repo at present, but
I've requested it and will push the changes there when it is granted.

J.

-- 
No one told you when to run, you missed the starting gun.
This .sig brought to you by the letter L and the number 39
Product of the Republic of HuggieTag


signature.asc
Description: PGP signature

Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too

[Axel Beckert]

Package: raspi-firmware
Severity: serious
Tags: patch

Hi,

if /boot/firmware is (nearly) full, raspi-firmware prevents (!)
uninstalling a kernel image, because it still insists on copying stuff
to /boot/firmware upon kernel image removal.

An additional condition might be that another kernel image is present
and not fully configured for the same reason (not enough
diskspace). It's unlcear for me, if this additional condition is
required for this issue to reproduce.

In general you can run into such an issue within months if you have
automatic updates enabled and don't clear up old kernels
automatically. (And yes, in my case the VFAT partition is rather small
as this is a very old installation.

  # df -h /boot/firmware/
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/mmcblk0p1  121M  121M  2.0K 100% /boot/firmware
  # dpkg --purge linux-image-6.1.0-1-armmp-lpae
  (Reading database ... 350731 files and directories currently installed.)
  Removing linux-image-6.1.0-1-armmp-lpae (6.1.4-1) ...
  /etc/kernel/postrm.d/initramfs-tools:
  update-initramfs: Deleting /boot/initrd.img-6.1.0-1-armmp-lpae
  /etc/kernel/postrm.d/z50-raspi-firmware:
  cp: error writing '/boot/firmware/vmlinuz-6.1.0-2-armmp-lpae': No space left 
on device
  run-parts: /etc/kernel/postrm.d/z50-raspi-firmware exited with return code 1
  dpkg: error processing package linux-image-6.1.0-1-armmp-lpae (--purge):
   installed linux-image-6.1.0-1-armmp-lpae package post-removal script 
subprocess returned error exit status 1
  Errors were encountered while processing:
   linux-image-6.1.0-1-armmp-lpae
  # ls -l /boot/firmware/{initrd.img,vmlinuz}-*
  -rwxr-xr-x 1 root root 25319457 Oct 13 08:32 
/boot/firmware/initrd.img-5.19.0-2-armmp-lpae
  -rwxr-xr-x 1 root root 25268327 Dec  7 08:29 
/boot/firmware/initrd.img-6.0.0-5-armmp-lpae
  -rwxr-xr-x 1 root root 25266000 Jan 18 08:21 
/boot/firmware/initrd.img-6.0.0-6-armmp-lpae
  -rwxr-xr-x 1 root root  5210624 Oct 24 00:52 
/boot/firmware/vmlinuz-5.19.0-2-armmp-lpae
  -rwxr-xr-x 1 root root  5267968 Dec  7 08:29 
/boot/firmware/vmlinuz-6.0.0-5-armmp-lpae
  -rwxr-xr-x 1 root root  5267968 Dec 27 08:05 
/boot/firmware/vmlinuz-6.0.0-6-armmp-lpae
  -rwxr-xr-x 1 root root  5370368 Jan 18 08:21 
/boot/firmware/vmlinuz-6.1.0-1-armmp-lpae
  -rwxr-xr-x 1 root root  3817472 Mar  1 05:31 
/boot/firmware/vmlinuz-6.1.0-2-armmp-lpae
  # dpkg --audit
  The following packages have been unpacked but not yet configured.
  They must be configured using dpkg --configure or the configure
  menu option in dselect for them to work:
   linux-headers-armmp-lpae Header files for Linux armmp-lpae configuration 
(meta
   linux-image-armmp-lpae Linux for ARMv7 multiplatform compatible SoCs 
supportin
  
  The following packages are only half configured, probably due to problems
  configuring them the first time.  The configuration should be retried using
  dpkg --configure  or the configure menu option in dselect:
   initramfs-tools  generic modular initramfs generator (automation)
   linux-headers-6.1.0-2-armmp-lpae Header files for Linux 6.1.0-2-armmp-lpae
   linux-image-6.1.0-2-armmp-lpae Linux 6.1 for ARMv7 multiplatform compatible 
So
   raspi-firmware   Raspberry Pi family GPU firmware and bootloaders
  
  The following packages are only half installed, due to problems during
  installation.  The installation can probably be completed by retrying it;
  the packages can be removed using dselect or dpkg --remove:
   linux-image-6.1.0-1-armmp-lpae Linux 6.1 for ARMv7 multiplatform compatible 
So

In the end, this also causes apt to abort rather early and not upgrade
or install anything anymore since then. This is also the reason why only
outdated kernel are (partially) installed.

So please stop copying stuff to /boot/firmware on kernel image removal
or purging. There will be an occasion for that at a later time anyway.

A patch (without the proper indentation probably wanted for readability)
which seems to have helped for me:

diff --git a/kernel/postinst.d/z50-raspi-firmware 
b/kernel/postinst.d/z50-raspi-firmware
index 1d3ae16..d898847 100755
--- a/kernel/postinst.d/z50-raspi-firmware
+++ b/kernel/postinst.d/z50-raspi-firmware
@@ -115,6 +115,7 @@ else
   dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
 fi
 
+if [ "$1" != "remove" ]; then
 if [ "$KERNEL" = "auto" ] ; then
   for dtb in "${dtb_path}"/bcm*.dtb; do
 [ -e "${dtb}" ] || continue
@@ -128,6 +129,7 @@ if [ "$KERNEL" = "auto" ] ; then
   cp "$latest_kernel" /boot/firmware/
   cp "$latest_initrd" /boot/firmware/
 fi
+fi
 
 
 

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
merged-usr: no
Architecture: armhf

Kernel: Linux 6.0.0-5-armmp-lpae (SMP)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell

Bug#1031821: libreswan: remote crash, CVE-2023-23009

[Salvatore Bonaccorso]

Hi Daniel,

On Fri, Feb 24, 2023 at 01:35:46PM -0500, Daniel Kahn Gillmor wrote:
> On Thu 2023-02-23 15:03:21 +0100, Salvatore Bonaccorso wrote:
> > Can you confirm on the following point: Is my understanding from the
> > upstream issue discussion correct, that this requires an authenticated
> > peer
> 
> I'm afraid i'm taking cagney's word for it there, i haven't followed the
> C far enough to be confident that the only way this codepath can be
> reached is for an already-authenticated peer.
> 
> > and for an authenticated peer, and then it leads to at most
> > self-DoS'ing his own connection?
> 
> I'm not sure i'd describe it as a "self-DOS" -- consider an IPSec-based
> encrypted internet proxy tunnelling service (aka "VPN") that arbitrary
> customers can sign up for.
> 
> If the service's entry nodes are running libreswan, and Alice is known
> to use the service, and Bob doesn't want Alice to be able to tunnel,
> then Bob could sign up for the service (thereby gaining an
> "authenticated" identity) and crash the entry node, right?
> 
> If i were Bob, i'd just repeat it until all the service's entry nodes
> were dead.  Then i'd observe Alice's non-tunneled traffic.
> 
> Is there a better way to understand the situation?

Yes it does thank you. So even tough that's a bit a borderline case
(mean with it as with the vpn service case, where you have
authennticated users, but you might not entirely trust the entities)
let's release a DSA for it. Can you prepare a final debdiff for a
quick review for bullseye-security?

Regards,
Salvatore

Bug#1032187: fuse3 FTBFS on hppa

[Helge Deller]

Package: fuse3
Tags: ftbfs, hppa, patch
Version: 3.14.0-2

fuse3 fails to build from source on the big-endian hppa platform because the 
testcase fails:
https://buildd.debian.org/status/fetch.php?pkg=fuse3&arch=hppa&ver=3.14.0-2&stamp=1677387190&raw=0

Please add hppa to the other big-endian platforms for which the testcase 
shouldn't run,
in debian/rules line 57 add to this line "hppa":
ifeq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x))
to become:
ifeq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x hppa))

Thanks,
Helge

Bug#1032189: Krusader does not bring the Viewer (F3) or Editor (F4) to foreground IF IT IS ALREADY OPEN WITH ANOTHER FILE

[only4com]

Package: krusader
Version: 2:2.8.0-1

Debian distribution: bookworm

$ uname -a
Linux linbox 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) 
x86_64 GNU/Linux

libc-bin Version: 2.36-8

KDE Plasma Version: 5.26.90
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-5-amd64 (64-bit)
Graphics Platform: Wayland


Dear Maintainer,

since last KDE updates:

Krusader won't bring the Viewer (F3) or Editor (F4) to foreground IF IT IS 
ALREADY OPEN WITH ANOTHER FILE

Thank you!

Bug#1032188: node-css-what: CVE-2022-21222/CVE-2021-33587

[Bastien Roucariès]

Package: node-css-what
Version: 4.0.0-3
Severity: serious
Tags: security
Justification: security
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

Find the minimal ReDoS fix for 4.0.0, checked with recheck

Bastien>From eeb1fafd26a9f09114b6f8282a9569f99d52d716 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Wed, 1 Mar 2023 11:45:48 +
Subject: [PATCH 5/5] Final ReDos Fix

Replace \s that could match whitespace in \u00b0-\u, by [ \t\n\r\f]* that is space according to css specification
---
 src/parse.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/parse.ts b/src/parse.ts
index fcae1e3..278eecf 100644
--- a/src/parse.ts
+++ b/src/parse.ts
@@ -81,7 +81,7 @@ export type TraversalType =
 const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
 const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
 // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
-const reAttr = /^(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4\s*|(#(?:\\.|[\w\u00b0-\u-])*|(?:\\.|[\w\u00b0-\u-])+)\s*|)|)([iI])?\]/;
+const reAttr = /^(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)[ \t\n\r\f]*(?:([~|^$*!]?)=[ \t\n\r\f]*(?:(['"])((?:[^\\]|\\[^])*?)\4[ \t\n\r\f]*|(#(?:\\.|[\w\u00b0-\u-])*|(?:\\.|[\w\u00b0-\u-])+)[ \t\n\r\f]*|)|)([iI])?\]/;
 
 const actionTypes: { [key: string]: AttributeAction } = {
 undefined: "exists",
-- 
2.39.2

>From 68319750685dc65fa63e1ef12686ca0ddae11007 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Wed, 1 Mar 2023 08:12:48 +
Subject: [PATCH 1/5] Partial fix of reDos

Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.

Add also != that is checked as invalid latter in order to pass testsuite.

So replace \S by [~|^$*!]
---
 src/parse.ts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/parse.ts b/src/parse.ts
index 677a029..628561b 100644
--- a/src/parse.ts
+++ b/src/parse.ts
@@ -81,7 +81,7 @@ export type TraversalType =
 const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
 const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
 // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
-const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:(\S?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
 
 const actionTypes: { [key: string]: AttributeAction } = {
 undefined: "exists",
-- 
2.39.2

>From 2d4e734ab30e8b19cdfedccc19923d2d69f40510 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Wed, 1 Mar 2023 10:10:47 +
Subject: [PATCH 2/5] Partial fix of ReDos

Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
---
 src/parse.ts | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/parse.ts b/src/parse.ts
index 628561b..ad11230 100644
--- a/src/parse.ts
+++ b/src/parse.ts
@@ -81,7 +81,7 @@ export type TraversalType =
 const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
 const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
 // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
-const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+const reAttr = /^(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
 
 const actionTypes: { [key: string]: AttributeAction } = {
 undefined: "exists",
@@ -263,8 +263,13 @@ function parseSelector(
 namespace: null,
 });
 } else if (firstChar === "[") {
+		const wmatch = selector
+		  .slice(selectorIndex + 1)
+		  .match(/^\s*/);
+		const woffset = !wmatch ? 0 : wmatch[0].length;
+
 const attributeMatch = selector
-.slice(selectorIndex + 1)
+.slice(selectorIndex + 1 + woffset)
 .match(reAttr);
 
 if (!attributeMatch) {
@@ -286,7 +291,7 @@ function parseSelector(
 ignoreCase,
 ] = attributeMatch;
 
-selectorIndex += completeSelector.length + 1;
+selectorIndex += completeSelector.length + 1 + woffset;
 let name = unescapeCSS(baseName);
 
 if (options.lowerCaseAttributeNames ?? !options.xmlMode) {
-- 
2.39.2

>From 05ff66f7eb1533866713de590fdc26e779db8516 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20Roucari=C3=A8s?= 
Date: Wed, 1 Mar 

Bug#1032190: Don't release with bookworm

[Shengjing Zhu]

Source: golang-github-jesseduffield-yaml
Version: 2.2.2+git20190702.b900b7e-3
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-gopkg-yaml.v2, golang-gopkg-yaml.v3.
No new development in https://github.com/jesseduffield/yaml since 2019.
No reverse-depends.

Bug#1031847: gnome-shell: Gnome crashes when laptop connected to ThinkPad Universal Thunderbolt 4 Dock (40B0), Oh no! Something has gone wrong error appears.

[Simon McVittie]

On Mon, 27 Feb 2023 at 09:27:25 +, Simon McVittie wrote:
> On Sun, 26 Feb 2023 at 18:34:12 +, Simon McVittie wrote:
> > The stack trace that you quoted looks like it could be memory corruption,
> > so it's not necessarily entirely obvious how to link a stack trace to
> > a root cause, and there might be more than one situation that leads to a
> > similar stack trace.
> 
> I'm reassigning this back to gnome-shell for now, because we don't know
> for sure that this is a lcms2 or colord bug (although it seems likely to at
> least be *related to* lcms2 or colord).

I found another potential cause:
https://gitlab.gnome.org/GNOME/mutter/-/issues/2659

Kuba (or anyone else who can reproduce this), please could
you try with mutter-related packages (at least libmutter-11-0)
upgraded to the version 43.3-3+1+g8c42befe7 that I have uploaded to
?

You might still need the colord packages from there *as well*, I'm not
100% sure how necessary the colord change is.

Whether this resolves the crash or not, please report back what
combination of packages you're using (`reportbug --template gnome-shell`
might be useful) and what the result was.

Thanks,
smcv

Bug#1014593: amd64-microcode: Updated version for bullseye/stable?

[Christian Kastner]

Thank you for the fast reply!

On 2023-03-01 12:07, Henrique de Moraes Holschuh wrote:
> Microcode updates are somewhat plagued with regressions, so usually I won't 
> push them to stable without a reasonable level of feedback.  And that is a 
> lot harder to come from AMD users than Intel users, for unknown-to-me reasons 
> (I can speculate, but that's not helpful).

Oh, I wasn't aware of this. I admittedly simply assumed that CPU
microcode updates are minimal (targeted fixes for errata, or some such),
and are thoroughly tested by the manufacturer.

> That said, with enough *it works* feedback, yes, we can push amd64-microcode 
> updates to stable.

I'd be happy to serve as a beta-tester.

I guess this could be automated to some degree with the help of
autopkgtests for a subset of packages, e.g. the scientific ones tend to
get really "close" to the CPU with their optimizations, and they usually
come with massive test suites.

> On Wed, Mar 1, 2023, at 07:09, Christian Kastner wrote:
>>> Users seem to be relying on this (as I was just asked about policies
>>> when microcode updates are updated/backported).
> 
> Really, you should rely on updated *firmware* if you can.  It still is the 
> only place where you can actually trust a microcode update (from either AMD 
> or Intel) to actually do all it was supposed to do.  I know for a fact the 
> Intel ones disable sections of the update that cannot be activated when not 
> loaded early enough.  For AMD, I know for a fact several updates of earlier 
> processors were never shipped to users because they *must* be done by the 
> firmware, nowadays maybe they do it like Intel.

Good to know, thanks.

With firmware, you mean BIOS updates, correct?

Makes sense but that would suck if still true for AMD, as manufacturers
stop providing updates far earlier than the useful live of the product.

>> Since microcode updates are generally fixes, sometimes even important
>> security fixes, I guess updates to stable (rather than going via
>> backports) would be permissible?
> 
> Yes, they usually are.  We can even send them in as security updates when we 
> get enough data to know it is going to fix a security issue **even when 
> loaded by the O.S.* (see remark above) and that it is not causing serious 
> regressions...

Best,
Christian

Bug#1032191: ITP: django-compression-middleware -- Django middleware to compress responses using several algorithms

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: django-compression-middleware
  Version : 0.4.2
  Upstream Author : Friedel Wolff 
* URL : 
https://github.com/friedelwolff/django-compression-middleware
* License : MPL-2.0
  Programming Lang: Python
  Description : Django middleware to compress responses using several 
algorithms

  This middleware implements compressed content encoding for HTTP. It is
  similar to Django's GZipMiddleware, but additionally supports other
  compression methods. It is meant to be a drop-in replacement for Django's
  GZipMiddleware.

  The middleware is focussed on the task of compressing typical Django
  responses such as HTML, JSON, etc.  Both normal (bulk) and streaming
  responses are supported. For static file compression, have a look at other
  projects such as WhiteNoise.

  Zstandard is a new method for compression with little client support so far.
  Most browsers now support Brotli compression. The middleware will choose the
  best compression method supported by the client as indicated in the
  request's Accept-Encoding header.

I plan to maintain this package as part of the Python team.

Bug#1032192: inadyn-2.10 does not ship a systemd service file

[Otmar Stahl]

Package: inadyn
Version: 2.10.0-1
Severity: normal

Dear Maintainer,

inadyn-2.10 does not ship a systemd service file, although upstream offers a 
service file.
The bug was already reported against inaddyn-2.9 ( #983309) and closed as 
fixed. However, the bug
appears again in the new upstream version inaddyn-2.10, which is in bookworm.

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/4 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 inadyn depends on:
ii  adduser  3.131
ii  init-system-helpers  1.65.2
ii  libc62.36-8
ii  libconfuse2  3.3-3
ii  libgnutls30  3.7.9-1
ii  libnettle8   3.8.1-2
ii  sysvinit-utils   3.06-2

inadyn recommends no packages.

inadyn suggests no packages.

-- Configuration Files:
/etc/default/inadyn changed:
RUN_DAEMON="yes"
RUN_IPUP="no"
USER="debian-inadyn"
GROUP="debian-inadyn"

/etc/inadyn.conf
## FreeDNS -- https://freedns.afraid.org
provider freedns.afraid.org {
username = 
password = 
hostname = 
}

-- no debconf information

Bug#1029523: ruby-net-http-persistent want Ruby (~> 2.1)

[Pirate Praveen]

Control: severity -1 important

On Thu, 23 Feb 2023 21:33:31 +0100 Paul Gevers  
wrote:

> Hi,
>
> On Tue, 24 Jan 2023 00:21:06 +0530 Pirate Praveen
>  wrote:
> >   net-http-persistent (~> 3.0, >= 3.0.0) was resolved to 3.1.0,
> > which depends on
> > Ruby (~> 2.1)
>
> This doesn't seem to be an issue on reproducible builds [1] when
> building ruby-faraday. Does that make sense?

Only bundler or rubygems checks this dependency requirement. It might 
just work fine on ruby 3.1. For now the easiest fix was to update to 
4.0 (for gitlab, where this bug appeared - in gitlab postinst, we use 
bundle install --local to verify all dependency requirements are 
satisfied), in which upstream has removed this constraint. May be we 
can ignore it for now (lowered the severity, as gitlab is not in 
bookworm).

Bug#1032193: pajeng: Please backport fix for Field count does not match definition for line

[Samuel Thibault]

Package: pajeng
Version: 1.3.6-3+fix
Severity: normal
Tags: patch upstream

Hello,

We are seeing these kinds of errors:

+ pj_dump -e 0
This is the event definition of the problematic event:
  %EventDef PajeStartLink 24
  %Time date
  %Type string
  %Container string
  %Value string
  %StartContainer string
  %Key string
  %Handle string
  %HName string
  %X string
  %Y string
  %EndEventDef
Line field count: 9
Definition field count: 11
Field count does not match definition for line (Line: 10672, Fields: 9, 
Contents: '24 299.383423000 TF p 1024 mm0 com_1 7f1c38c7e998 "  0   0')
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 9) >= this->size() (which is 9)
Aborted

That's because the field is an empty string:

24  299.383423000   TF  p   1024mm0 com_1   7f1c38c7e998
""  0   0

That has been fixed upstream:
https://github.com/schnorr/pajeng/commit/ca24c95cc5b4e53455058e180f01d5a5febccac6
also attached to this mail, verified as fixing the bug.

Could you backport the patch to the Debian package?

Thanks,
Samuel

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

Kernel: Linux 6.2.0 (SMP w/8 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 pajeng depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libpaje2 1.3.6-3+fix
ii  libstdc++6   12.2.0-14
ii  r-base-core  4.2.2.20221110-2

pajeng recommends no packages.

pajeng suggests no packages.

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
commit ca24c95cc5b4e53455058e180f01d5a5febccac6
Author: Lucas Schnorr 
Date:   Wed Oct 19 12:55:19 2022 -0300

fix legacy parsing when empty fields are double-quotes""

diff --git a/src/libpaje/PajeEventDecoder.cc b/src/libpaje/PajeEventDecoder.cc
index 98602b3..a8224e4 100644
--- a/src/libpaje/PajeEventDecoder.cc
+++ b/src/libpaje/PajeEventDecoder.cc
@@ -76,13 +76,16 @@ char *PajeEventDecoder::break_line (char *s, paje_line 
*line)
 }
 if (!in_word && !isspace(*p)) {
   if (*p == '"') {
-p++;
 in_string = true;
   } else {
 in_word = true;
   }
   if (line->word_count < PAJE_MAX_FIELDS) {
-line->word[line->word_count] = p;
+if(in_string){
+  line->word[line->word_count] = p+1; //ignore "
+}else{
+  line->word[line->word_count] = p;
+}
 line->word_count ++;
   }
   continue;

Bug#1032194: musescore: no new debian version since nearly 5 years ...

[Heinz Repp]

Package: musescore
Version: 2.3.2+dfsg4-15
Severity: wishlist




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

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

Versions of packages musescore depends on:
ii  desktop-file-utils   0.26-1
ii  fonts-freefont-ttf   20120503-10
ii  libasound2   1.2.8-1+b1
ii  libc62.36-8
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libportaudio219.6.0-1.2
ii  libportmidi0 1:217-6.1
ii  libpulse016.1+dfsg1-2+b1
ii  libqt5core5a 5.15.8+dfsg-2
ii  libqt5gui5   5.15.8+dfsg-2
ii  libqt5help5  5.15.8-2
ii  libqt5network5   5.15.8+dfsg-2
ii  libqt5printsupport5  5.15.8+dfsg-2
ii  libqt5qml5   5.15.8+dfsg-2
ii  libqt5quick5 5.15.8+dfsg-2
ii  libqt5svg5   5.15.8-2
ii  libqt5widgets5   5.15.8+dfsg-2
ii  libqt5xml5   5.15.8+dfsg-2
ii  libqt5xmlpatterns5   5.15.8-2
ii  libsndfile1  1.2.0-1
ii  libstdc++6   12.2.0-14
ii  libvorbisfile3   1.3.7-1
ii  musescore-common 2.3.2+dfsg4-15
ii  qml-module-qtquick-controls  5.15.8-2
ii  qml-module-qtquick-dialogs   5.15.8-2
ii  qml-module-qtquick-layouts   5.15.8+dfsg-2
ii  qml-module-qtquick2  5.15.8+dfsg-2
ii  shared-mime-info 2.2-1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages musescore recommends:
ii  libmp3lame0  1:3.100-dmo2

Versions of packages musescore suggests:
ii  pulseaudio-utils  16.1+dfsg1-2+b1

-- no debconf information
Version 2.3.2 has been released in July 2018. Since then a lot has been changed 
and added, especially regarding muse-sounds.
Many 3.x versions appeared, starting December 2018. And December 2022, version 
4.0 has been released.
Latest version is 4.0.1, released January 13, 2023.

As there has been added a plethora of new features, please consider providing a 
recent version.

Thank you

Heinz Repp 

Bug#1032195: gr-air-modes: modes_rx fails with AttributeError: module 'numpy' has no attribute 'float'

[Sophie Brun]

Package: gr-air-modes
Version: 0.0.20210211-2+b7
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: bott...@debian.org, sop...@offensive-security.com


Hello,

modes_rx fails to run:

Traceback (most recent call last):
  File "/usr/bin/modes_rx", line 26, in 
import air_modes
  File "/usr/lib/python3/dist-packages/air_modes/__init__.py", line 59, in 

from .flightgear import output_flightgear
  File "/usr/lib/python3/dist-packages/air_modes/flightgear.py", line 9, in 

from air_modes import mlat
  File "/usr/lib/python3/dist-packages/air_modes/mlat.py", line 40, in 
dtype=numpy.float)
  ^^^
  File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 305, in 
__getattr__
raise AttributeError(__former_attrs__[attr])
AttributeError: module 'numpy' has no attribute 'float'.
`np.float` was a deprecated alias for the builtin `float`. To avoid this error 
in existing code, use `float` by itself. Doing this will not modify any 
behavior and is safe. If you specifically wanted the numpy scalar type, use 
`np.float64` here.
The aliases was originally deprecated in NumPy 1.20; for more details and 
guidance see the original release note at:
https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations. Did you 
mean: 'cfloat'?

Since python3-numpy version 1.24.0, the aliases have been removed.

Regards,


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

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

Versions of packages gr-air-modes depends on:
ii  libc6   2.36-8
ii  libgcc-s1   12.2.0-14
ii  libgnuradio-air-modes1  0.0.20210211-2+b7
ii  libgnuradio-runtime3.10.5   3.10.5.1-2
ii  libstdc++6  12.2.0-14
ii  python3 3.11.2-1
ii  python3-numpy [python3-numpy-abi9]  1:1.24.2-1
ii  python3-zmq 24.0.1-4+b1

Versions of packages gr-air-modes recommends:
ii  gnuradio   3.10.5.1-2
ii  gr-osmosdr 0.2.4-1
ii  python3-scipy  1.10.0-4

gr-air-modes suggests no packages.

-- no debconf information

Bug#1031700: Audio s/pdif selection in gnome quick settings (bookworm)

[dev . lkq1u]

Hello,

Indeed this bug is linked to gnome-shell 43.2
Since the migration to gnome-shell 43.2 I could not reproduce the problem.
I think this bug report can be closed

Thanks, this is my first bug report
Best,
Vincent

Bug#1032196: kinfoc: Plasma incorrectly displays 5.26.90 in info center when synaptic displays 5.27 as the installed version

[Andrés Segarra]

Package: kinfoc
Version: kinfocenter
Severity: normal

Dear Maintainer,

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

   * What led up to the situation? I full-upgraded my system including kde
plasma, and checked the info center and it doesn't display the correct version


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


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

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

Bug#1032197: systemd: journalctl -o short-iso-precise not compatible with RFC 3339

[Thomas Parmelan]

Package: systemd
Version: 252.5-2
Severity: wishlist
X-Debbugs-Cc: tom+deb...@ankh.fr.eu.org

Dear Maintainer,

Recent versions of rsyslog (as used in sid) are now using by default
timestamps based on RFC 3339 (Date and Time on the Internet:
Timestamps).

The "-o short-iso-precise" journalctl option uses an ISO 8601 profile
that is not compatible with RFC 3339 (it misses a ':' between the hours
and minutes in the timezone offset).

Making journalct's ISO 8601 format compatible with RFC 3339 would make
things easier for people comparing journalctl output with rsyslog
output, for instance those like me using the 'logcheck' package (which,
in sid, recently started checking by default the systemd journal too).

Would it be possible to change the short-iso-precise in this way, or if
you prefer not changing it, maybe adding a new short-rfc3339-precise
option ? (and probably doing the same thing for short-iso / short-rfc339
too) ?

Best regards,
Tom

-- 
Thomas Parmelan

Bug#1032198: wapiti fails to start with Python 3.11

[Sophie Brun]

Package: wapiti
Version: 3.0.4+dfsg-1
Severity: grave
Justification: renders package unusable
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: sop...@offensive-security.com

Hello

Wapiti fails to start with

Traceback (most recent call last):
  File "/usr/bin/wapiti", line 33, in 
sys.exit(load_entry_point('wapiti3==3.0.4', 'console_scripts', 'wapiti')())
 ^^^
  File "/usr/bin/wapiti", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/wapitiCore/main/wapiti.py", line 41, in 

from wapitiCore.language.language import _
  File "/usr/lib/python3/dist-packages/wapitiCore/language/language.py", line 
62, in 
lan = gettext.translation(
  
TypeError: translation() got an unexpected keyword argument 'codeset'

It is caused by a change in Python 3.11

The latest upstream release no longer contains this code. But we
can't update the package now because of the freeze.

The code can be patched easily to get rid of this issue, but I don't know if
there are any other issues with Python 3.11

This issue has first been reported here:
https://bugs.kali.org/view.php?id=8197

Regards,

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

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

Versions of packages wapiti depends on:
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  python3 3.11.2-1
ii  python3-bs4 4.11.2-1
ii  python3-importlib-metadata  4.12.0-1
ii  python3-mako1.2.4+ds-1
ii  python3-markupsafe  2.1.2-1+b1
ii  python3-requests2.28.1+dfsg-1
ii  python3-six 1.16.0-4
ii  python3-socks   1.7.1+dfsg-1
ii  python3-tld 0.11.11-4
ii  python3-yaswfp  0.9.3-2

wapiti recommends no packages.

wapiti suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/lib/python3/dist-packages/wapitiCore/language/language.py (from wapiti 
package)

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

If reproducible: would this bug be a good candidate for upload of a
fix to 'experimental' so that it can be alpha-tested by others?

On Wed, 1 Mar 2023 at 02:55, Jérémy Lal  wrote:
>
>
>
> Le mer. 1 mars 2023 à 02:30, Thorsten Glaser  a écrit :
>>
>> Jérémy Lal dixit:
>>
>> >I can build nodejs on amhdal.debian.org if you're not comfortable with that.
>>
>> The problem with the DSA porterboxen is that you cannot install your own
>> built packages in the chroot to use them there… unless there’s a
>> solution not yet known to me?
>
>
> Indeed, but the binary can be run from build dir, so I just need to try and 
> reproduce the bug from there.
>

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Jérémy Lal]

Le mer. 1 mars 2023 à 14:39, James Addison  a écrit :

> If reproducible: would this bug be a good candidate for upload of a
> fix to 'experimental' so that it can be alpha-tested by others?
>

Sure.

For now I'm unlucky with the porterbox, because /var/run/schroot
disappeared yesterday.
Notified debian-admin.

Jérémy

Bug#1032199: Native compilation fails to generate trampolines on certain scenarios

[Sergio Durigan Junior]

Package: emacs
Version: 1:28.2+1-11
Severity: important
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61880

[ This is the downstream equivalent of
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61880 ]

Hello,

While investigating a few bugs affecting Debian's and Ubuntu's Emacs
packages (for example,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028725), I stumbled
upon a problem that's affecting native compilation on Emacs 28.1+,
currently reproducible with git master as well.

I haven't been able to fully understand why the problem is happening,
but when there are two primitive functions (that would become
trampolines) being used sequentially, Emacs doesn't generate the
corresponding .eln file for the second function.

I spent some time investigating the problem and came up with a "minimal"
reproducer:

--8<---cut here---start->8---
(require 'cl-lib)

(defmacro foo--flet (funcs &rest body)
  "Like `cl-flet' but with dynamic function scope."
  (declare (indent 1))  

  
  (let* ((names (mapcar #'car funcs))
 (lambdas (mapcar #'cdr funcs))
 (gensyms (cl-loop for name in names
   collect (make-symbol (symbol-name name)
`(let ,(cl-loop for name in names
for gensym in gensyms
collect `(,gensym (symbol-function ',name)))
   (unwind-protect
   (progn
 ,@(cl-loop for name in names
for lambda in lambdas
for body = `(lambda ,@lambda)
collect `(setf (symbol-function ',name) ,body))
 ,@body)
 ,@(cl-loop for name in names
for gensym in gensyms
collect `(setf (symbol-function ',name) ,gensym))

(defun bar (file)
  (and (file-exists-p file) (file-readable-p file)))

(defun test ()
  (foo--flet ((file-exists-p (file) t)
  (file-readable-p (file) nil))
(message "%s" (bar "/home/sergio/.lesshst"
--8<---cut here---end--->8---

When I run it using the following Emacs:

--8<---cut here---start->8---
GNU Emacs 30.0.50
Development version 68cc286c0495 on master branch; build date 2023-02-28.
--8<---cut here---end--->8---

here is the output I see:

--8<---cut here---start->8---
$ emacs -batch -Q -l t.el -f test -L .
Error: native-lisp-load-failed ("file does not exists" 
"/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
  debug-early-backtrace()
  debug-early(error (native-lisp-load-failed "file does not exists" 
"/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln"))
  
native-elisp-load("/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln")
  comp-trampoline-search(file-readable-p)
  comp-subr-trampoline-install(file-readable-p)
  fset(file-readable-p (lambda (file) nil))
  (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 'file-readable-p 
#'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst")))
  (unwind-protect (progn (fset 'file-exists-p #'(lambda (file) t)) (fset 
'file-readable-p #'(lambda (file) nil)) (message "%s" (bar 
"/home/sergio/.lesshst"))) (fset 'file-exists-p file-exist
s-p) (fset 'file-readable-p file-readable-p))
  (let ((file-exists-p (symbol-function 'file-exists-p)) (file-readable-p 
(symbol-function 'file-readable-p))) (unwind-protect (progn (fset 
'file-exists-p #'(lambda (file) t)) (fset 'file-re
adable-p #'(lambda (file) nil)) (message "%s" (bar "/home/sergio/.lesshst"))) 
(fset 'file-exists-p file-exists-p) (fset 'file-readable-p file-readable-p)))
  test()
  command-line-1(("-l" "t.el" "-f" "test" "-L" "."))
  command-line()
  normal-top-level()
Native elisp load failed: "file does not exists", 
"/home/sergio/.emacs.d/eln-cache/30.0.50-23de7b18/subr--trampoline-66696c652d7265616461626c652d70_file_readable_p_0.eln"
--8<---cut here---end--->8---

Do note that this is already affecting a few packages, like buttercup
(see https://github.com/jorgenschaefer/emacs-buttercup/issues/230) and
emacs-web-server, for example.

Please let me know if you need more information regarding the problem.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1032200: mosquitto: leaves behind mosquitto user and group on purge

[наб]

Package: mosquitto
Version: 2.0.11-1
Severity: normal
Tags: patch

Dear Maintainer,

I purged mosquitto a few weeks ago; imagine my surprise when:
-- >8 --
$ getent passwd mosquitto
mosquitto:x:131:144::/var/lib/mosquitto:/usr/sbin/nologin
$ getent group mosquitto
mosquitto:x:144:
$ dpkg -l mosquitto
dpkg-query: no packages found matching mosquitto
-- >8 --

I'm attaching a patch that fixes this, based on the debian HEAD (1ca9e5984b2);
modelled off snmpd.postinst, so presumably correct.

Best,
наб

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mosquitto depends on:
ii  adduser  3.118
ii  libc62.31-13+deb11u5
pn  libcjson1
pn  libdlt2  
pn  libmosquitto1
ii  libssl1.11.1.1n-0+deb11u4
ii  libsystemd0  247.3-7+deb11u1
pn  libwebsockets16  
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0

mosquitto recommends no packages.

Versions of packages mosquitto suggests:
ii  apparmor  2.13.6-10


signature.asc
Description: PGP signature

Bug#1032200: mosquitto: leaves behind mosquitto user and group on purge

[наб]

One day I'll attach a patch when I say I am.
From 67c3d7fb00b2e538d19eaa354afa51efe44dd7bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Wed, 1 Mar 2023 14:51:03 +0100
Subject: [PATCH] Remove mosquitto UID and GID on purge
X-Mutt-PGP: OS

---
 debian/mosquitto.postrm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/mosquitto.postrm b/debian/mosquitto.postrm
index 17052329..ac5a13c4 100644
--- a/debian/mosquitto.postrm
+++ b/debian/mosquitto.postrm
@@ -19,6 +19,8 @@ case "$1" in
 		if [ -d /run/mosquitto ]; then
 			rmdir --ignore-fail-on-non-empty /run/mosquitto
 		fi
+		deluser --quiet --system mosquitto || :
+		delgroup --quiet --system mosquitto || :
 APP_PROFILE="usr.sbin.mosquitto"
 rm -f /etc/apparmor.d/disable/$APP_PROFILE >/dev/null 2>&1 || true
 	;;
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1032201: snmpd: uses chown user.group syntax

[наб]

Package: snmpd
Version: 5.9.3+dfsg-2
Severity: normal
Tags: patch

Dear Maintainer,

chown user.group is an ancient BSD remnant, and also invalid, since,
naturally, usernames can have dots in them
(coreutils really ought to start warning on this nonstandard usage).

Attaching patch based on current Salsa HEAD (e2da187de2da19a4aa8e9520)
to turn the one usage into correct user:group.

Best,
наб

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages snmpd depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u5
ii  libsnmp-base   5.9+dfsg-4+deb11u1
ii  libsnmp40  5.9+dfsg-4+deb11u1
ii  lsb-base   11.1.0

snmpd recommends no packages.

Versions of packages snmpd suggests:
pn  snmptrapd  

-- Configuration Files:
/etc/snmp/snmpd.conf [Errno 13] Permission denied: '/etc/snmp/snmpd.conf'

-- debconf information excluded
From 6f657dbc5a1bcdaab4000eea628f4561a5228f18 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Wed, 1 Mar 2023 14:54:47 +0100
Subject: [PATCH] snmpd.postinst: use legal chown syntax
X-Mutt-PGP: OS

---
 debian/snmpd.postinst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/snmpd.postinst b/debian/snmpd.postinst
index 51b949f..e73f4c4 100644
--- a/debian/snmpd.postinst
+++ b/debian/snmpd.postinst
@@ -19,9 +19,9 @@ case "$1" in
 --shell "$SNMP_SHELL" --force-badname "$SNMP_USER"
 
 # care if SNMP_DIR is used by previous "snmp" user
-chown "$SNMP_USER"."$SNMP_GROUP" "$SNMP_DIR"
+chown "$SNMP_USER":"$SNMP_GROUP" "$SNMP_DIR"
 	if [ -f "$SNMP_DIR/snmpd.conf" ]; then
-chown "$SNMP_USER"."$SNMP_GROUP" "$SNMP_DIR/snmpd.conf"
+chown "$SNMP_USER":"$SNMP_GROUP" "$SNMP_DIR/snmpd.conf"
 	fi
 
 	# Change group of snmpd.conf to SNMP_GROUP #998152
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1032188: debdiff

[Bastien Roucariès]

Dear security team,

For bullseye will you find the debdiff attached.

Waiting for your instruction

Bastiendiff -Nru node-css-what-4.0.0/debian/changelog node-css-what-4.0.0/debian/changelog
--- node-css-what-4.0.0/debian/changelog	2021-01-09 21:06:15.0 +
+++ node-css-what-4.0.0/debian/changelog	2023-03-01 13:47:23.0 +
@@ -1,3 +1,15 @@
+node-css-what (4.0.0-3+deb11u1) bullseye-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 13:47:23 +
+
 node-css-what (4.0.0-3) unstable; urgency=medium
 
   * Team upload
diff -Nru node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	2023-03-01 13:47:23.0 +
@@ -0,0 +1,36 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 08:12:48 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+---
+ src/parse.ts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/parse.ts b/src/parse.ts
+index 677a029..628561b 100644
+--- a/src/parse.ts
 b/src/parse.ts
+@@ -81,7 +81,7 @@ export type TraversalType =
+ const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
+ const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
+ // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:(\S?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
++const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+ 
+ const actionTypes: { [key: string]: AttributeAction } = {
+ undefined: "exists",
diff -Nru node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	2023-03-01 13:47:23.0 +
@@ -0,0 +1,55 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 10:10:47 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ src/parse.ts | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/parse.ts b/src/parse.ts
+index 628561b..ad11230 100644
+--- a/src/parse.ts
 b/src/parse.ts
+@@ -81,7 +81,7 @@ export type TraversalType =
+ const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
+ const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
+ // Modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-const reAttr = /^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
++const reAttr = /^(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+ 
+ const actionTypes: { [key: string]: AttributeAction } = {
+ undefined: "exists",
+@@ -263,8 +263,13

Bug#1029821: change gnome-desktop's default choice of Japanese input methods

[YOSHINO Yoshihito]

Control: severity -1 grave

Dear Maintainer,

This bug is critical to most Japanese language users. In a fresh GNOME
desktop installation by bookworm d-i, after the first login
gnome-initial-setup pops up and breaks the default Japanese input method
with the inappropriate config in this package.

I really hope this will be fixed before the release.

Thanks in advance,
-- 
YOSHINO Yoshihito 

Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck

[Marc Leeman]

Note that updating ext2fs with these new features also breaks other
software components like refind (volume detection) in bookworm (this is how
I came to this bug).

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

On Wednesday, 1 March 2023 07:24:23 CET Otto Kekäläinen wrote:
> 
> The fact that his issue surfaced now about something that changed in
> Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> Also I don't have any easy way to fire up a container and reproduce
> the issue.

It isn't really so mysterious, and I tried to explain it in the original bug I 
filed against Kontact:

1. A change in MariaDB 10.6 broke Qt's MySQL support back in 2021.

2. Someone decided to let this change leak into MariaDB 10.3.38.

3. A Debian package for 10.3.38 was finalised in the last couple of weeks and 
arrived last week.

4. Suddenly, Akonadi cannot connect to MySQL properly and Kontact won't show 
the contents of mail messages any more.

How the change leaked is more mysterious. However, going to the 10.3 branch of 
the server, following the link to libmariadb and the mariadb-connector-c 
repository and using the "blame" tool yields this commit:

https://github.com/mariadb-corporation/mariadb-connector-c/commit/
d204e83104222844251b221e9be7eb3dd9f8d63d

That was made two months ago, but I imagine that the workflow propagated it in 
various branches for a while before a release was actually made.

> However, as a clear patch was suggested I did it in
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863-> 
> libmariadb3-version-id

I realised that I had messed up my own patch, explaining why I didn't see any 
change in behaviour with my revised package, but rebuilding again and testing 
now, I can confirm that the above patch fixes the problem. Reverting to the 
distribution-supplied libqt5sql5-mysql package and using the patched version 
of libmariadb3 makes Kontact and Akonadi work again.

> The the Salsa runner comes back online and pipeline works again, there
> will be build artifacts available at
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
> you can download the libmariadb3 with this patched and test if it
> fixes your mail client situation.

It seems that the pipeline failed, but I managed to build a revised package 
anyway.

I have no idea about whether other software has been broken by this, but 
anyone using the distribution-supplied packages for libmariadb3 and 
libqt5sql5-mysql will have seen programs break.

Maybe only the Akonadi stack is affected as a consequence. Since people tend 
to abandon the KDE groupware programs every time something breaks, it is 
entirely possible that there are relatively few users left to complain.

All this effort for a single-token change in a file that shouldn't have been 
made in the first place!

Paul

Bug#1026539: How much do we lose if we remove theano (+keras, deepnano, invesalius)?

[Andreas Tille]

Control: tags -1 pending

Hi,

> Andrius Merkys wrote:
> That said, it is OK to omit keras in bookworm if need be, but I would 
> like to see it back for trixie.

I've spent some time into theano and it builds and runs its test suite
in Salsa CI[1].  Since despite some tests are failing in my local
pbuilder environment I'd be happy if someone else could run some test
build before uploading.  I decided for the latest upstream that was
prepared by Rebecca and I also sneaked into the aesara fork[2] to copy
some solutions they found for numpy 1.24 compatibility.

I think we can not really loose much by taking this code from
experimental since if we break something it can be removed which is
the consensus we've somehow found before.  In case it might work we
have saved something for bookworm.  Regarding future releases we
should probably check whether those packages we want to save will
work with aesara.

Kind regards
   Andreas.

[1] https://salsa.debian.org/science-team/theano/-/pipelines/506598
[2] https://github.com/aesara-devs/aesara

-- 
http://fam-tille.de

Bug#1032202: New buttercup_eval directive

[Sergio Durigan Junior]

Source: dh-elpa
Version: 2.0.16
Severity: normal

Hi,

I would like to propose the inlined patch to implement a new
buttercup_eval directive on dh-elpa.  Aside from the fact that this is a
good-to-have feature, there is a bigger problem at play here: it's
currently not possible to eval elisp code when buttercup is invoked
during autopkgtest, which makes workarounds like the one uploaded for
flycheck (at bug #1028725) incomplete.

It'd be great if we could have this in bookworm, but due to the freeze
I'd understand if it's not possible.  I'd like to have this in unstable
ASAP, though, if that's OK with you.

Thank you,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index f4bee52..7782294 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dh-elpa (2.0.17) unstable; urgency=medium
+
+  * dh_elpa_test: Implement new buttercup_eval directive.
+
+ -- Sergio Durigan Junior   Wed, 01 Mar 2023 10:26:11 
-0500
+
 dh-elpa (2.0.16) unstable; urgency=medium
 
   * Drop dependencies on emacs-el introduced in 2.0.11.
diff --git a/dh_elpa_test b/dh_elpa_test
index c2504bf..d0a252d 100755
--- a/dh_elpa_test
+++ b/dh_elpa_test
@@ -86,6 +86,10 @@ run.  If this key is not defined, all tests that can be found
 will be run.  Will be passed to buttercup(1) with its B<-p> command
 line argument.
 
+=item B
+
+Emacs Lisp code to be run by buttercup's --eval option.
+
 =item B
 
 A comma-separated list of file globs matching files containing ERT
@@ -341,6 +345,8 @@ if ($control->source->Build_Depends->has( "elpa-buttercup" 
)) {
 push @args, ('-p', "$pattern");
 }
 }
+push @args, ("--eval", $options->{_}->{'buttercup_eval'})
+  if (defined $options->{_}->{'buttercup_eval'});
 print_and_doit(@args);
 }
 


signature.asc
Description: PGP signature

Bug#1032203: Please backport version 4.4.0

[Enrico Zini]

Package: python3-typing-extensions
Version: 4.4.0-1
Severity: wishlist

Hello,

thanks for packaging python3-typing-extensions!

Now that 4.4.0 is in testing, would it be possible to also upload it to
backports?

It contains support for python 3.11 typing additions, and since python
3.11 is the version that is going to be in the new stable, having it in
bullseye-backports would allow to start targeting bookworm a bit more
during Python development.

Thanks,

Enrico


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

Kernel: Linux 6.1.0-3-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 python3-typing-extensions depends on:
ii  python3  3.11.2-1

python3-typing-extensions recommends no packages.

python3-typing-extensions suggests no packages.

-- no debconf information

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Otto Kekäläinen]

> > The fact that his issue surfaced now about something that changed in
> > Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> > Also I don't have any easy way to fire up a container and reproduce
> > the issue.
>
> It isn't really so mysterious, and I tried to explain it in the original bug I
> filed against Kontact:

i was referring to steps to reproduce.

> https://github.com/mariadb-corporation/mariadb-connector-c/commit/d204e83104222844251b221e9be7eb3dd9f8d63d

Thanks for pointing this one. I was reading the commit
https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306
that another reporter posted earlier.

> > However, as a clear patch was suggested I did it in
> > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863->
> >  libmariadb3-version-id
>
..
> It seems that the pipeline failed, but I managed to build a revised package
> anyway.

Salsa-CI is back online and
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/292377544983e0db9b702399a977b900cdacbcee
is building.

Bug#1032186: [Pkg-raspi-maintainers] Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too

[Diederik de Haas]

On Wednesday, 1 March 2023 12:48:49 CET Axel Beckert wrote:
> A patch (without the proper indentation probably wanted for readability)
> which seems to have helped for me:
> 
> diff --git a/kernel/postinst.d/z50-raspi-firmware
> b/kernel/postinst.d/z50-raspi-firmware index 1d3ae16..d898847 100755
> --- a/kernel/postinst.d/z50-raspi-firmware
> +++ b/kernel/postinst.d/z50-raspi-firmware
> @@ -115,6 +115,7 @@ else
>dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
>  fi
> 
> +if [ "$1" != "remove" ]; then
>  if [ "$KERNEL" = "auto" ] ; then
>for dtb in "${dtb_path}"/bcm*.dtb; do
>  [ -e "${dtb}" ] || continue
> @@ -128,6 +129,7 @@ if [ "$KERNEL" = "auto" ] ; then
>cp "$latest_kernel" /boot/firmware/
>cp "$latest_initrd" /boot/firmware/
>  fi
> +fi

https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/32 contains a 
variation of your patch.

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

Bug#1032204: plover: Please upgrade to new version 4.0.0.dev12

[Boyuan Yang]

Source: plover
Severity: normal
Tags: sid
Version: 4.0.0~dev10-1

Dear Debian plover package maintainer,

Please consider packaging the new release of plover as released at
https://github.com/openstenoproject/plover/releases .

Just in case the new version needs some new dependency, I have packaged
plover-stroke at https://tracker.debian.org/pkg/plover-stroke . You are
welcome to examine and co-maintain plover-stroke as necessary.

Thanks,
Boyuan Yang


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

Bug#1032137: ITP: python-hardware -- hardware detection and classification utilities

[Antoine Beaupré]

On 2023-02-28 15:18:33, Thomas Goirand wrote:
> * Package name: python-hardware
>   Description : hardware detection and classification utilities
>
>  Detect hardware features of a Linux systems:
>   * RAID
>   * hard drives
>   * IPMI
>   * network cards
>   * DMI infos
>   * memory settings
>   * processor features
>  .
>  Filter hardware according to hardware profiles.

Oh, this is interesting! There's very little documentation on the
upstream site, what do you plan on using this for?

It looks like a library I could very well use to rewrite stressant
into something more sane... It seems it even has benchmarks...

Thanks for any clarification!

-- 
We all pay for life with death, so everything in between should be
free.
 - Bill Hicks


signature.asc
Description: PGP signature

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

On Wednesday, 1 March 2023 17:09:54 CET Otto Kekäläinen wrote:
> > > The fact that his issue surfaced now about something that changed in
> > > Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> > > Also I don't have any easy way to fire up a container and reproduce
> > > the issue.
> > 
> > It isn't really so mysterious, and I tried to explain it in the original
> > bug I filed against Kontact:
> i was referring to steps to reproduce.

Sorry, I can only really report how the bug arose on my system. Reproducing it 
would presumably involve creating an environment where Akonadi is initialised 
and then trying to access resources via Akonadi. Without some kind of test 
suite, which I presume does not already exist for Akonadi, that would 
potentially be a lot of work.

> > https://github.com/mariadb-corporation/mariadb-connector-c/commit/d204e831
> > 04222844251b221e9be7eb3dd9f8d63d
> Thanks for pointing this one. I was reading the commit
> https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965
> 706f9a062baaba0c494dd6efb2c306 that another reporter posted earlier.

Yes, it is difficult to navigate to the commit on the appropriate branch, and 
the involvement of mysql_get_client_info in that patch also confused me.

> > > However, as a clear patch was suggested I did it in
> > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031
> > > 863-> libmariadb3-version-id
> ..
> 
> > It seems that the pipeline failed, but I managed to build a revised
> > package
> > anyway.
> 
> Salsa-CI is back online and
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/292377544983e0db
> 9b702399a977b900cdacbcee is building.

Thank you for activating this again.

Paul

Bug#1032205: bugs.debian.org: i915 GPU, displayport connector, monitor turns on and off randomly

[Vladimir Egorin]

Package: bugs.debian.org
Severity: normal

Dear Maintainer,

A NEC EA275UHD display is connected using DP cable
to an i3-8100 system. After turning the display
off using DPMS, the screen does not stay off.
It turns on at random intervals, displays a message that there
is no signal on the DP port, and goes back to sleep, repeat the cycle.

"cat /sys/devices/pci:00/:00:02.0/power/control"

outputs "auto".

echo "on" >  /sys/devices/pci:00/:00:02.0/power/control

eliminates this behavior.

I am using quality DP cables listed in VESA database, 2 meters long, and I tried
several cables from different manufactures.

I observe the same behavior with a different monitor connected
to the same machine.

Thanks.

Bug#1032160: tfortune FTCBFS: multiple reasons

[Andre Noll]

On Wed, Mar 01, 01:12, Helmut Grohne wrote
> On Tue, Feb 28, 2023 at 11:13:24PM +0100, Andre Noll wrote:
> > > The immediate failure is failing to find the lopsub library since it
> > > configures for the build architecture. This happens as no --build nor 
> > > --host
> > > is passed which would have happened automatically if dh_auto_configure 
> > > could
> > > be used.  Thus it'll have to be passed manually.
> > 
> > Do you recommend to get rid of the override_dh_auto_configure target
> > in debian/rules?
> 
> As far as I understand it, you cannot. dh_auto_configure would pass
> options that configure does not understand.

This could be changed easily as the configure script of tfortune
is just a trivial wrapper which calls autoconf to create a standard
configure script and runs it. All arguments passed to configure are
passed through to the generated script.

> > I'm in favor of switching to something more standard, but I will
> > need your help. What's the best way forward to improve on the current
> > situation? Do you want me to apply your patch as is and push out the
> > result to the public repo? Is there anything else I can do to make
> > life easier for the Debian people?
> 
> If you are upstream, you can try making the build system behave more
> like a standard autoconf one. We tend to expect that:
>  * It uses a current version of autoconf that understands all options
>passed by dh_auto_configure (which could allow dropping the
>override).
>  * Enabling use of dh_autoreconf.
>  * Making the Makefile honour the settings (e.g. CC) detected by
>configure.
> 
> However, you may also choose to keep the present behaviour and apply my
> patch to make it cross buildable.

Let's take this easy route for now. I've applied your patch and used
most of the text of your original mail as the commit message. However,
I omitted the last part because I felt that the rant about the build
system, albeit justified, does not belong there :)

If you are OK with the commit message shown below, I'll merge the
commit into the master branch and push it out to the public repo.

> I recommend scheduling this update for the trixie cycle as bookworm is
> frozen and this is not an important bug.

This is where I need your help, as I'm unfamiliar with the usual
Debian procedures. How exactly do I schedule an update for trixie?

Thanks
Andre
---
commit 51a5a39de6d9527e38b84744abfa330ef36ab779
Author: Helmut Grohne 
Date:   Wed Mar 1 17:03:24 2023 +0100

Fix cross build.

The cross build fails to find the lopsub library since it configures
for the build architecture. This happens as no --build nor --host is
passed which would have happened automatically if dh_auto_configure
could be used. Thus it'll have to be passed manually. Then configure
fails finding config.h.in, which for some reason is not created (nor
asked for) by the override_dh_autoreconf. And finally, the actual
Makefile does not pick up the compiler detected by configure and
rather uses plain cc, so we'll have to tell it as well.

Signed-off-by: Andre Noll 

diff --git a/debian/changelog b/debian/changelog
index b54c641..ef53fa1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+tfortune (1.0.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Also ask for generating config.h.in, which otherwise goes missing in
+  cross builds.
++ Pass --build and --host to configure as we cannot use dh_auto_configure.
++ Also export cross tools for make.
+
+ -- Helmut Grohne   Tue, 28 Feb 2023 05:42:58 +0100
+
 tfortune (1.0.1-1) unstable; urgency=low
 
   * No changes relative to 1.0.0-2.
diff --git a/debian/rules b/debian/rules
index 03a9279..a360dc7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,13 +1,18 @@
 #!/usr/bin/make -f
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
+include /usr/share/dpkg/architecture.mk
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
+
 %:
dh "$@"
 
 # plain dh_auto_configure uses options which configure does not understand
 override_dh_auto_configure:
./configure --prefix=/usr --bindir=/usr/games \
-   --datadir=/usr/share/games
+   --datadir=/usr/share/games --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
 # needed because dh_autoreconf overwrites our configure wrapper
 override_dh_autoreconf:
-   $(MAKE) configure.sh
+   $(MAKE) config.h.in configure.sh
-- 
Max Planck Institute for Biology
Tel: (+49) 7071 601 829
Max-Planck-Ring 5, 72076 Tübingen, Germany
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

Bug#1032186: [Pkg-raspi-maintainers] Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too

[Axel Beckert]

Hi Diederik,

Diederik de Haas wrote:
> On Wednesday, 1 March 2023 12:48:49 CET Axel Beckert wrote:
> > A patch (without the proper indentation probably wanted for readability)
> > which seems to have helped for me:
[…]
> https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/32 contains a 
> variation of your patch.

Thanks!

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

Bug#1032188: Old stable debdiff

[Bastien Roucariès]

Hi,

The debdiff for buster. Please review, will upload, after a while.

ReDoS was checked by using (not yet packaged) rechek.

Bastiendiff -Nru node-css-what-2.1.0/debian/changelog node-css-what-2.1.0/debian/changelog
--- node-css-what-2.1.0/debian/changelog	2016-02-05 20:41:17.0 +
+++ node-css-what-2.1.0/debian/changelog	2023-03-01 15:33:15.0 +
@@ -1,3 +1,15 @@
+node-css-what (2.1.0-1+deb10u1) buster-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 15:33:15 +
+
 node-css-what (2.1.0-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	2023-03-01 15:29:40.0 +
@@ -0,0 +1,37 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:08:01 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/index.js b/index.js
+index 859324c..d7105f9 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:(\S?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
diff -Nru node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	2023-03-01 15:29:40.0 +
@@ -0,0 +1,43 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:15:20 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/index.js b/index.js
+index d7105f9..1e7f145 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
+@@ -146,7 +146,10 @@ function parseSelector(subselects, selector, options){
+ 	ignoreCase: false
+ });
+ 			} else if(firstChar === "["){
+-selector = selector.substr(1);
++			selector = selector.substr(1);
++			var wspace = selector.match(/^\s*/);
++			 

Bug#1028549: Acknowledgement (xserver-xorg-video-radeon: [Radeon 680M]: not rendering/refreshing fullscreen properly with VSync off)

[Linus Lüssing]

Just for a small update:

Issue still persists, even with all packages updated to a current
Debian Sid (including adding the new "non-free-firmware" section
to apt).

ii  xserver-xorg-video-radeon1:19.1.0-3
ii  libc6:amd64  2.36-8
ii  libc6:i386   2.36-8
ii  libdrm-radeon1:amd64 2.4.114-1
ii  libdrm-radeon1:i386  2.4.114-1
ii  libgbm1:amd6422.3.6-1
ii  libgbm1:i386 22.3.6-1
ii  libudev1:i386252.6-1
ii  xserver-xorg-core2:21.1.7-1
ii  firmware-amd-graphics20230210-2

$ uname -a
Linux linus-lptp 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 
(2023-02-15) x86_64 GNU/Linux

Regards, Linus

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[James Addison]

Package: libgnome-desktop-4-2
Followup-For: Bug #1029821
X-Debbugs-Cc: yy.y.ja...@gmail.com

I'd like to contribute by testing d-i with Japanese input (I'm not a Japanese
speaker, but can offer some time to help).

My plan is to:

  1. run the graphical d-i install of a fresh GNOME 43 system
  2. select 'anthy' in 'gnome-initial-setup'
  3. attempt Japanese keyboard input

  4. run the graphical d-i install of a fresh GNOME 43 system
  5. select 'mozc-jp' in 'gnome-initial-setup'
  6. attempt Japanese keyboard input

For each path I may need help: how will I verify that Japanese input support
is working?  (maybe a naive question, but I don't know; I will search the web
to find out soon, but any guidance before then would be appreciated)

Also:

My understanding is that the _only_ difference that the patch will make is
that it will change the default in 'gnome-initial-setup'.  Users could still
choose 'anthy' -- or another input method -- if they want, for some reason.  Is
that correct?

Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed

[Sébastien Villemot]

Le mercredi 01 mars 2023 à 17:58 +0100, Sébastien Villemot a écrit :
> I ended up implementing this “solution” in octave-io 2.4.6-3.

Sorry, I meant octave-io 2.6.4-3

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1012016: libapache-poi-java breaks octave-io autopkgtest: assert (size (d) == [1001, 2]) failed

[Sébastien Villemot]

Control: severity -1 important

Le mardi 31 janvier 2023 à 18:09 +0100, Sébastien Villemot a écrit :
> Alternatively, I could try to patch octave-io so that it no longer uses
> libapache-poi-java for reading XLSX files. That is an inferior
> solution, because that will remove an important functionality from the
> package, but I may not have the choice.

I ended up implementing this “solution” in octave-io 2.4.6-3. So in
effect it no longer relies on libapache-poi-java + libxmlbeans-java for
reading XLSX files (fortunately octave-io has another, less efficient,
backend for reading XLSX files).

As a consequence, downgrading the severity of this bug.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1032188: old old stable debdiff

[Bastien Roucariès]

Hi,

The old old stable debdiff now

diff -Nru node-css-what-2.1.0/debian/changelog node-css-what-2.1.0/debian/changelog
--- node-css-what-2.1.0/debian/changelog	2016-02-05 20:41:17.0 +
+++ node-css-what-2.1.0/debian/changelog	2023-03-01 15:33:15.0 +
@@ -1,3 +1,15 @@
+node-css-what (2.1.0-1+deb9u1) stretch-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 15:33:15 +
+
 node-css-what (2.1.0-1) unstable; urgency=medium
 
   * new upstream version
diff -Nru node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch	2023-03-01 15:33:15.0 +
@@ -0,0 +1,37 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:08:01 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = ~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/index.js b/index.js
+index 859324c..d7105f9 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:(\S?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
diff -Nru node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	1970-01-01 00:00:00.0 +
+++ node-css-what-2.1.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch	2023-03-01 15:33:15.0 +
@@ -0,0 +1,43 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 15:15:20 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+Signed-off-by: Bastien Roucariès 
+---
+ index.js | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/index.js b/index.js
+index d7105f9..1e7f145 100644
+--- a/index.js
 b/index.js
+@@ -5,7 +5,7 @@ module.exports = parse;
+ var re_name = /^(?:\\.|[\w\-\u00c0-\u])+/,
+ re_escape = /\\([\da-f]{1,6}\s?|(\s)|.)/ig,
+ //modified version of https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-re_attr = /^\s*((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
++re_attr = /^((?:\\.|[\w\u00c0-\u\-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])(.*?)\3|(#?(?:\\.|[\w\u00c0-\u\-])*)|)|)\s*(i)?\]/;
+ 
+ var actionTypes = {
+ 	__proto__: null,
+@@ -146,7 +146,10 @@ function parseSelector(subselects, selector, options){
+ 	ignoreCase: false
+ });
+ 			} else if(firstChar === "["){
+-selector = selector.substr(1);
++			selector = selector.substr(1);
++			var wspace = selector.match(/^\s*/);
++			var woffset = !wspace ? 0 : wspace[0].length;
++			selector = selector.substr(woffs

Bug#1032206: fakeroot: [INTL:de] Updated German Translation

[Chris Leick]

Package: fakeroot
Version: 1.31-1
Severity: wishlist
Tags: l10n patch



Hi,

please find attached the newest German translation.

Kind regards,
Chris

de.po.gz
Description: application/gzip

Bug#995156: easy-rsa: vars Autodetection

[Adrian Bunk]

On Tue, Feb 14, 2023 at 10:28:16PM +0100, Lee Garrett wrote:
> I'm bumping the bug severity because currently it will ignore
> security-relevant settings like keysize and algo, and the defaults are
> pretty weak.

Has anyone discussed this with upstream?

This seems to be an area with frequent changes upstream, adding a patch 
that is not a backport from upstream might be a bad idea.

cu
Adrian

Bug#1025141: powermgmt-base: Doesn't correctly detect we are on AC power

[Raymond S Brand]

Followup to Santiago's report:

The script is also reporting that my Dell 3260CFF (Compact Form Factor) 
is not on AC power when it is since it doesn't have a battery option.


The following may be of some help:

$ sh -x /sbin/on_ac_power
+ set -e
+ OFF_LINE_P=no
+ [ -d /sys/class/power_supply/ ]
+ test -d /sys/class/power_supply/hidpp_battery_0
+ test -r /sys/class/power_supply/hidpp_battery_0/type
+ cat /sys/class/power_supply/hidpp_battery_0/type
+ type=Battery
+ test -d /sys/class/power_supply/ucsi-source-psy-USBC000:001
+ test -r /sys/class/power_supply/ucsi-source-psy-USBC000:001/type
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:001/type
+ type=USB
+ [ -r /sys/class/power_supply/ucsi-source-psy-USBC000:001/online ]
+ cat /sys/class/power_supply/ucsi-source-psy-USBC000:001/online
+ online=0
+ [ 0 = 1 ]
+ [ 0 = 0 ]
+ OFF_LINE_P=yes
+ [ yes = yes ]
+ exit 1
$

The H/W doesn't actually have a battery option but does use a laptop 
style power brick or USB-C to supply power.

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Rai]

Hi Paul,

Thanks for clearification.
At least we are 2 users and over the years I'm really happy with debian. ;)

Regards
Rai

Am 01.03.2023 um 16:13 schrieb Paul Boddie:

> On Wednesday, 1 March 2023 07:24:23 CET Otto Kekäläinen wrote:
>> 
>> The fact that his issue surfaced now about something that changed in
>> Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
>> Also I don't have any easy way to fire up a container and reproduce
>> the issue.
> 
> It isn't really so mysterious, and I tried to explain it in the original bug 
> I 
> filed against Kontact:
> 
> 1. A change in MariaDB 10.6 broke Qt's MySQL support back in 2021.
> 
> 2. Someone decided to let this change leak into MariaDB 10.3.38.
> 
> 3. A Debian package for 10.3.38 was finalised in the last couple of weeks and 
> arrived last week.
> 
> 4. Suddenly, Akonadi cannot connect to MySQL properly and Kontact won't show 
> the contents of mail messages any more.
> 
> How the change leaked is more mysterious. However, going to the 10.3 branch 
> of 
> the server, following the link to libmariadb and the mariadb-connector-c 
> repository and using the "blame" tool yields this commit:
> 
> https://github.com/mariadb-corporation/mariadb-connector-c/commit/
> d204e83104222844251b221e9be7eb3dd9f8d63d
> 
> That was made two months ago, but I imagine that the workflow propagated it 
> in 
> various branches for a while before a release was actually made.
> 
>> However, as a clear patch was suggested I did it in
>> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863->
>>  libmariadb3-version-id
> 
> I realised that I had messed up my own patch, explaining why I didn't see any 
> change in behaviour with my revised package, but rebuilding again and testing 
> now, I can confirm that the above patch fixes the problem. Reverting to the 
> distribution-supplied libqt5sql5-mysql package and using the patched version 
> of libmariadb3 makes Kontact and Akonadi work again.
> 
>> The the Salsa runner comes back online and pipeline works again, there
>> will be build artifacts available at
>> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
>> you can download the libmariadb3 with this patched and test if it
>> fixes your mail client situation.
> 
> It seems that the pipeline failed, but I managed to build a revised package 
> anyway.
> 
> I have no idea about whether other software has been broken by this, but 
> anyone using the distribution-supplied packages for libmariadb3 and 
> libqt5sql5-mysql will have seen programs break.
> 
> Maybe only the Akonadi stack is affected as a consequence. Since people tend 
> to abandon the KDE groupware programs every time something breaks, it is 
> entirely possible that there are relatively few users left to complain.
> 
> All this effort for a single-token change in a file that shouldn't have been 
> made in the first place!
> 
> Paul

Bug#1032197: systemd: journalctl -o short-iso-precise not compatible with RFC 3339

[Michael Biebl]

Control: tags -1 + upstream

Hi

Am 01.03.23 um 14:32 schrieb Thomas Parmelan:

Would it be possible to change the short-iso-precise in this way, or if
you prefer not changing it, maybe adding a new short-rfc3339-precise
option ? (and probably doing the same thing for short-iso / short-rfc339
too) ?


I think this could be a useful addition. That said, this should be 
discussed/implemented upstream and not via a downstream patch.


Can you thus please file an issue upstream at
https://github.com/systemd/systemd/

Thanks,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031969: this is an important bug, can't use torch on bookworm any longer

[Sam Watkins]

The package is not installable, and it's necessary for anyone who uses bookworm 
for AI work and anything else that might need 3.10.

I was using Debian "testing" with torch. Torch is not fully compatible with 
3.11,
and now the 3.10 packaging is broken and we can no longer create a 3.10 venv.

Bug#1032207: libpam-modules: Drop pam_userdb

[Bastian Germann]

Package: libpam-modules
Severity: wishlist
Version: 1.5.2-6

libpam-modules is the only pseudo-essential module that depends on libdb5.3 via 
its pam_userdb module.
I have never seen a system actually using this so I suggest to remove during 
the trixie release cylce,
i.e. dropping the Build-Depends on libdb-dev.

Alternatively, it could be split out to a separate binary package, possibly 
with other less used modules.

Bug#1032208: ITP: python-aiohttp-retry -- Simple aiohttp retry client

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-aiohttp-retry
  Version : 2.8.3
  Upstream Author : Dmitry Inyutin 
* URL : https://github.com/inyutin/aiohttp_retry
* License : MIT
  Programming Lang: Python
  Description : Simple aiohttp retry client

This package provides aiohttp-retry - the python3 library extending
aiohttp with retry support.

Bug#1032209: ITP: python-linesep -- Python3 library for manipulation with lines with separators

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-linesep
  Version : 0.5.0
  Upstream Author : John Thorvald Wodder II 
* URL : https://linesep.readthedocs.org/
* License : MIT
  Programming Lang: Python
  Description : Python3 library for manipulation with lines with separators

linesep provides basic functions & classes for reading, writing, splitting,
& joining text with custom separators that can occur either before, between, or
after the segments they separate

Bug#1032211: ITP: python-outdated -- Check if a version of a PyPI package is outdated

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko , Vasyl Gello 

Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-outdated
  Version : 0.2.2
  Upstream Author : Alex Hall 
* URL : https://github.com/alexmojaki/outdated
* License : MIT
  Programming Lang: Python
  Description : Check if a version of a PyPI package is outdated

This is a mini-library which, given a package name and a version,
checks if it's the latest version available on PyPI.

It does not check which version of package is actually installed,
but only checks if the provided version string of the given package
is latest or not.

Bug#1032210: ITP: python-methodtools -- Python3 library expanding standard functools to methods

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-methodtools
  Version : 0.4.7
  Upstream Author : Jeong YunWon 
* URL : https://methodtools.readthedocs.org/
* License : BSD-2-clause
  Programming Lang: Python
  Description : Python3 library expanding standard functools to methods

Expand functools features to methods, classmethods, staticmethods
and even for (unofficial) hybrid methods.

For now, methodtools only provides `methodtools.lru_cache`.

Bug#1032212: ITP: python-wirerope -- Python3 library for manipulation with methods

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-wirerope
  Version : 0.4.7
  Upstream Author : Jeong YunWon 
* URL : https://wirerope.readthedocs.org/
* License : BSD-2-clause
  Programming Lang: Python
  Description : Python3 library for manipulation with methods

It turns functions and methods into fully controllable object

Used in conjunction with methodtools.

Bug#1032214: ITP: python-www-authenticate -- Parser for WWW-Authentication headers for Python 3

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko , Vasyl Gello 

Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-www-authenticate
  Version : 0.9.2
  Upstream Author : Alexandre Dutton 
* URL : https://github.com/alexsdutton/www-authenticate
* License : BSD-3-clause
  Programming Lang: Python
  Description : Parser for WWW-Authentication headers for Python 3

This Python 3 library parses various WWW-Authenticate headers
including ones emitted by servers not conformant to RFCs.

Bug#1032213: ITP: python-wsgidav -- Generic and extendable WebDAV server

[Vasyl Gello]

Package: wnpp
Owner: Yaroslav Halchenko ,
Vasyl Gello 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: python-wsgidav
  Version : 4.2.0
  Upstream Author : Martin Wendt 
* URL : https://wsgidav.readthedocs.org/
* License : MIT
  Programming Lang: Python
  Description : Generic and extendable WebDAV server

WsgiDAV is a stand-alone WebDAV server with SSL support,
that can be installed and run as Python command line script
on Linux, OSX, and Windows

Bug#1032215: RM: libmath-units-perl -- NPOASR; No longer required for Geo::Calc

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: libmath-units-p...@packages.debian.org
Control: affects -1 + src:libmath-units-perl

Please remove libmath-units-perl from the archive, it was required for 
Geo::Calc which got removed (#1031604).

Kind Regards,

Bas

Bug#1032165: gcc-12-cross-ports: not binNMU safe

[Sebastian Ramacher]

Control: clone -1 -2 -3 -4
Control: reassign -2 gcc-9-cross-ports 25
Control: retitle -2 gcc-9-cross-ports: not binNMU-safe  
Control: reassign -3 gcc-9-cross 27
Control: retitle -3 gcc-9-cross: not binNMU-safe
Control: reassign -4 gcc-10-cross-mipsen 3+c5
Control: retitle -4 gcc-10-cross-mipsen: not binNMU-safe

On 2023-02-28 22:18:14 +0100, Sebastian Ramacher wrote:
> Control: clone -1 -2
> Control: reassign -2 gcc-11-cross-mipsen 5+c3
> Control: retitle -2 gcc-11-cross-mipsen: not binNMU-safe
> 
> On 2023-02-28 22:13:59 +0100, Sebastian Ramacher wrote:
> > Source: gcc-12-cross-ports
> > Version: 12
> > Severity: serious
> > 
> > The method to compute the version of the binary packages is not
> > binNMU-safe. This can be seen from the latest round of binNMUs to
> > rebuild for outdated Built-Using fields. See
> > https://buildd.debian.org/status/fetch.php?pkg=gcc-12-cross-ports&arch=amd64&ver=12%2Bb1&stamp=1677602107&raw=0
> > 
> > As it can be seen from the log, the version computed for the binary
> > packages is the same as the one of the build of the initial upload of
> > version 12. The binNMU version -- b1 in this case -- is missing.
> 
> gcc-11-cross-mipsen is affected by the same issue. Cloning and
> reassigning.

… and there are more.

Cheers
-- 
Sebastian Ramacher

Bug#1032105: pkg-perl-tools: [dpt prepare] gitddiff shouldn't use last tag but last tag in current branch

[gregor herrmann]

On Wed, 01 Mar 2023 07:27:13 +0400, Yadd wrote:

> > > > In lib/dpt-lib.sh, maybe you could replace
> > > > TAG=$(git rev-list -n1 --tags)
> > > or simply
> > >TAG=$(git describe --abbrev=0)

> > But this works:
> > 
> >% git describe --abbrev=0 --match "debian/*" --tags # [1]
> >debian/1.62-3

> > Maybe, in order to git rid of the separation between native and
> > non-native package, something funky as
> > 
> >% git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed 
> > -e 's/%(version)s/*/g;')" --tags # [2]
> >debian/1.62-3
> > 

> > Alright, maybe we all try out either [1] or [2] a bit?
> > I've updated my .gitconfig and my local version of
> > scripts/lib/dpt-lib.sh to use [2].

> I tried also [2], perfect with all Perl packages I've locally + 1500 nodejs
> packages, works perfectly!

Thanks for trying and reporting back!

I was also quite happy so far -- until I hit a repository with no
debian tags (new package, in this case libjson-schema-modern-perl),
and there I got (at the end of dpt-import-orig):

  Git diff against last Debian tag
  
  fatal: No names found, cannot describe anything.


Directly in the shell:

  % git rev-list -n1 --tags=debian
  %

(No output, exit code 0)

  % git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed -e 
's/%(version)s/*/g;')" --tags
  fatal: No names found, cannot describe anything.

(Exit code 128)

Not sure what to do here; I mean

  % git describe --abbrev=0 --match "$(gbp config DEFAULT.debian-tag | sed -e 
's/%(version)s/*/g;')" --tags 2>/dev/null || true

works but …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1031821: libreswan: remote crash, CVE-2023-23009

[Daniel Kahn Gillmor]

On Wed 2023-03-01 12:52:58 +0100, Salvatore Bonaccorso wrote:
> Yes it does thank you. So even tough that's a bit a borderline case
> (mean with it as with the vpn service case, where you have
> authennticated users, but you might not entirely trust the entities)
> let's release a DSA for it. Can you prepare a final debdiff for a
> quick review for bullseye-security?

Sure, a proposed final debdiff is attached.  The code is also in the
debian/bullseye branch on https://salsa.debian.org/debian/libreswan.

Please let me know if you think anything else should be done
differently.

Thanks for keeping an eye on this, Salvatore!

  --dkg

diff --git libreswan-4.3/debian/changelog libreswan-4.3/debian/changelog
index ff60ad1b7b..8f709eec58 100644
--- libreswan-4.3/debian/changelog
+++ libreswan-4.3/debian/changelog
@@ -1,3 +1,9 @@
+libreswan (4.3-1+deb11u2) bullseye-security; urgency=high
+
+  * Fixes CVE-2023-23009 (Closes: #1031821)
+
+ -- Daniel Kahn Gillmor   Wed, 01 Mar 2023 13:11:05 -0500
+
 libreswan (4.3-1+deb11u1) bullseye-security; urgency=high
 
   * Fixes CVE-2022-23094
diff --git libreswan-4.3/debian/patches/0004-Fix-CVE-2023-23009.patch libreswan-4.3/debian/patches/0004-Fix-CVE-2023-23009.patch
new file mode 100644
index 00..851aa0d71d
--- /dev/null
+++ libreswan-4.3/debian/patches/0004-Fix-CVE-2023-23009.patch
@@ -0,0 +1,25 @@
+From: Daniel Kahn Gillmor 
+Date: Wed, 22 Feb 2023 14:57:02 -0500
+Subject: Fix CVE-2023-23009
+
+See https://github.com/libreswan/libreswan/issues/954
+---
+ programs/pluto/ikev2_ts.c | 5 +
+ 1 file changed, 5 insertions(+)
+
+diff --git a/programs/pluto/ikev2_ts.c b/programs/pluto/ikev2_ts.c
+index fba776a..c8ce761 100644
+--- a/programs/pluto/ikev2_ts.c
 b/programs/pluto/ikev2_ts.c
+@@ -421,6 +421,11 @@ static bool v2_parse_ts(struct payload_digest *const ts_pd,
+ 		d = pbs_in_struct(&ts_pd->pbs, &ikev2_ts_header_desc,
+ 			  &ts_h, sizeof(ts_h), &ts_body_pbs);
+ 
++		if (d != NULL) {
++			llog_diag(RC_LOG, logger, &d, "%s", "");
++			return false;
++		}
++
+ 		switch (ts_h.isath_type) {
+ 		case IKEv2_TS_IPV4_ADDR_RANGE:
+ 		case IKEv2_TS_IPV6_ADDR_RANGE:
diff --git libreswan-4.3/debian/patches/series libreswan-4.3/debian/patches/series
index ccb5ae82f7..7039666566 100644
--- libreswan-4.3/debian/patches/series
+++ libreswan-4.3/debian/patches/series
@@ -1,3 +1,4 @@
 0001-do-not-use-git-version.patch
 0002-debian-pam.d-pluto.patch
 CVE-2022-23094.patch
+0004-Fix-CVE-2023-23009.patch


signature.asc
Description: PGP signature

Bug#1032168: meson: autopkgtest fills disk completely

[Paul Gevers]

Hi Jussi,

On 01-03-2023 00:17, Jussi Pakkanen wrote:

On Tue, 28 Feb 2023 at 23:30, Paul Gevers  wrote:


With your last upload of meson, we're seeing issues on
ci.debian.net. It turns out that the autopkgtest of meson is using so
much disk space that the most of our hosts runs out of it when meson
is tested.


This is weird. As far as we know we have not made any changes that
should affect disk usage in 1.0.1.


Well, maybe something that meson uses has changed?


Is /tmp on the same file system as the rest of the image or is it a
separate partition?


Inside the lxc container, everything is on the same partition. Or are 
you really interested on the host that runs autopkgtest? There it's not 
the same across the workers.



Is it possible to know how close to filling up the disk the old
succeeding builds got?


No, but e.g. on s390x it never ever came close to filling the disk, so
the peaks of before today here are really new:
https://ci.debian.net/munin/ci-worker-s390x-01/ci-worker-s390x-01/df.html 
(but apparently another package is also suddenly misbehaving, so maybe 
it's indeed something *below* meson. I'll try to figure out tonight or 
tomorrow morning.



And how much disk space is given to the build
in total?


I've wished for a long time to provide that information on our site. To 
be able to quickly provide the info, I decided to quickly set up this wiki:

https://wiki.debian.org/ContinuousIntegration/WorkerSpecs

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031821: libreswan: remote crash, CVE-2023-23009

[Salvatore Bonaccorso]

Daniel,

On Wed, Mar 01, 2023 at 01:18:11PM -0500, Daniel Kahn Gillmor wrote:
> On Wed 2023-03-01 12:52:58 +0100, Salvatore Bonaccorso wrote:
> > Yes it does thank you. So even tough that's a bit a borderline case
> > (mean with it as with the vpn service case, where you have
> > authennticated users, but you might not entirely trust the entities)
> > let's release a DSA for it. Can you prepare a final debdiff for a
> > quick review for bullseye-security?
> 
> Sure, a proposed final debdiff is attached.  The code is also in the
> debian/bullseye branch on https://salsa.debian.org/debian/libreswan.
> 
> Please let me know if you think anything else should be done
> differently.
> 
> Thanks for keeping an eye on this, Salvatore!

Thanks to you actually. Looks good to me, please do upload.

Regards,
Salvatore

Bug#1031210: mitmproxy: please update to 9.0.1

[Gianfranco Costamagna]

Hello,

On Mon, 13 Feb 2023 18:13:24 +0100 Bastian Germann  wrote:

On Mon, 13 Feb 2023 09:41:15 +0100 Gianfranco Costamagna 
 wrote:
> mitmproxy-wireguard is already available as kali package, I think I'll just 
go ahead and start from that
> https://gitlab.com/kalilinux/packages/mitmproxy-wireguard

Please see https://github.com/mitmproxy/mitmproxy/pull/5909 and note
that upstream has already switched away from that for the next version.



thanks!
So we will have a newer mitmproxy soon?

G.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032219: apt-setup: Regression in a string which was correctly translated (es.po)

[Santiago Vila]

Package: apt-setup
Version: 1:0.177
Tags: patch

Hello.

After trying debian-installer alpha2 today I've noticed there is an
error in debian/po/es.po for the string "release updates",
introduced in commit 11c8e244 dated 2023-02-07.

Apparently, somebody has misinterpreted it as if "release" acted
as a verb and "updates" was the direct object of such verb (!).
The end result is a screen like this:

[ ] actualizaciones de seguridad (de security.debian.org)
[ ] Publicar actualizaciones
[ ] programas migrados a nuevas versiones


The old translation ("actualizaciones de la distribución")
was essentially correct (except that the previous extra ":"
is not needed).

(X-Debian-CC to debian-l10n-span...@lists.debian.org in
case they want to comment on this).

Patch attached.

Thanks.--- a/debian/po/es.po
+++ b/debian/po/es.po
@@ -219,7 +219,7 @@ msgstr "actualizaciones de seguridad (de ${SEC_HOST})"
 #. :sl1:
 #: ../apt-setup-udeb.templates:11001
 msgid "release updates"
-msgstr "Publicar actualizaciones"
+msgstr "actualizaciones de la distribución"
 
 #. Type: multiselect
 #. Choices

Bug#1032220: multipath-tools: reports job failed on upgrade

[Ross Boylan]

Package: multipath-tools
Version: 0.8.5-2+deb11u1
Severity: normal
X-Debbugs-Cc: rossboy...@stanfordalumni.org, t...@security.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Running on Debian 11.6 and applying the latest security update results in
some reported failures.

It is unclear to me if there is any real problem, as it is unclear if the
package
is operating properly.  The journalctl logs seem to show a successful start,
but
the aptitude messages indicate a job failed.

The apparent failure messages buried in the logs are
Mar 01 09:49:46 barley systemd[1]: multipathd.socket: Socket service
multipathd.service already active, refusing.
Mar 01 09:49:46 barley systemd[1]: Failed to listen on multipathd control
socket.

A start job for unit multipathd.socket has finished with a failure.

Mar 01 09:49:47 barley multipathd[842874]: failed to increase buffer size

So multipathd.socket reports failure, but multipathd.service reports success

Details
- ---


Setting up kpartx (0.8.5-2+deb11u1) ...
Setting up multipath-tools (0.8.5-2+deb11u1) ...
Installing new version of config file /etc/init.d/multipath-tools ...
Job failed. See "journalctl -xe" for details.
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.31-13+deb11u5) ...



Mar 01 09:49:39 barley systemd[1]: multipathd.socket: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit multipathd.socket has successfully entered the 'dead' state.
Mar 01 09:49:39 barley systemd[1]: Closed multipathd control socket.
░░ Subject: A stop job for unit multipathd.socket has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit multipathd.socket has finished.
░░
░░ The job identifier is 168534 and the job result is done.
Mar 01 09:49:44 barley systemd[1]: Reloading.
Mar 01 09:49:45 barley systemd[1]: /lib/systemd/system/plymouth-
start.service:16: Unit configured to use KillMode=none. This is unsafe, as it
disables systemd's process lifecycle management for the service. Please update
your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
Mar 01 09:49:46 barley systemd[1]: multipathd.socket: Socket service
multipathd.service already active, refusing.
Mar 01 09:49:46 barley systemd[1]: Failed to listen on multipathd control
socket.
░░ Subject: A start job for unit multipathd.socket has failed
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit multipathd.socket has finished with a failure.
░░
░░ The job identifier is 168535 and the job result is failed.
Mar 01 09:49:46 barley systemd[1]: Reloading.
Mar 01 09:49:46 barley systemd[1]: /lib/systemd/system/plymouth-
start.service:16: Unit configured to use KillMode=none. This is unsafe, as it
disables systemd's process lifecycle management for the service. Please update
your service to use a safer KillMode=, such as 'mixed' or 'control-group'.
Support for KillMode=none is deprecated and will eventually be removed.
Mar 01 09:49:47 barley multipathd[1378]: exit (signal)
Mar 01 09:49:47 barley systemd[1]: Stopping Device-Mapper Multipath Device
Controller...
░░ Subject: A stop job for unit multipathd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit multipathd.service has begun execution.
░░
░░ The job identifier is 168538.
Mar 01 09:49:47 barley multipathd[1378]: shut down---
Mar 01 09:49:47 barley systemd[1]: multipathd.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit multipathd.service has successfully entered the 'dead' state.
Mar 01 09:49:47 barley systemd[1]: Stopped Device-Mapper Multipath Device
Controller.
░░ Subject: A stop job for unit multipathd.service has finished
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A stop job for unit multipathd.service has finished.
░░
░░ The job identifier is 168538 and the job result is done.
Mar 01 09:49:47 barley systemd[1]: multipathd.service: Consumed 1min 17.748s
CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit multipathd.service completed and consumed the indicated resources.
Mar 01 09:49:47 barley systemd[1]: Starting Device-Mapper Multipath Device
Controller...
░░ Subject: A start job for unit multipathd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit multipathd.service has begun execution.
░░
░░ The job identifier is 168538.
Mar 01 09:49:47 barley multipathd[842874]: start up
Mar 01 09:49:47 barley multipathd[842874]: read /etc/multipath.conf
Mar 01 09:49:47 barley multipathd[842874]: failed to increase buffer size
Mar 01 09:49:

Bug#1032220: multipath-tools: reports job failed on upgrade

[Chris Hofstaedtler]

* Ross Boylan  [230301 21:09]:
> It is unclear to me if there is any real problem, as it is unclear if the
> package
> is operating properly.  The journalctl logs seem to show a successful start,
> but
> the aptitude messages indicate a job failed.
> 
> The apparent failure messages buried in the logs are
> Mar 01 09:49:46 barley systemd[1]: multipathd.socket: Socket service
> multipathd.service already active, refusing.

Thats the part causing the failed message in the apt/dpkg postinst
output, and is TTBOMK harmless.

Chris

Bug#1032160: tfortune FTCBFS: multiple reasons

[Helmut Grohne]

Hi,

On Wed, Mar 01, 2023 at 05:27:04PM +0100, Andre Noll wrote:
> If you are OK with the commit message shown below, I'll merge the
> commit into the master branch and push it out to the public repo.

Sure.

> This is where I need your help, as I'm unfamiliar with the usual
> Debian procedures. How exactly do I schedule an update for trixie?

This isn't exactly about scheduling and more about waiting. Do you mind
if I refer to https://release.debian.org/testing/freeze_policy.html for
details? In essence, this bug does not qualify as "targeted fix".

Helmut

Bug#1030709: libvirt 7.0.0-3+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1030709 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libvirt
Version: 7.0.0-3+deb11u2

Explanation: fix test failures when combined with newer Xen versions

Bug#920913: 2023 status for fakeroot under docker?

[Olliver Schinagl]

I've been using a docker container (either debian or alpine based) to 
build openwrt on my Arch system :)


OpenWRT pulls and builds fakeroot to do stuff with, but both containers 
choke in some form.


The debian based container launches 1 faked 100% process at a time, and 
takes forever to do things (but finishes eventually). A 'build' takes 
about 30 - 60 minutes.



```

buildbot@99419141cf36:/workdir$ cat /proc/sys/fs/file-max
9223372036854775807
buildbot@99419141cf36:/workdir$ cat /proc/sys/fs/nr_open
1073741816
buildbot@99419141cf36:/workdir$ ulimit
unlimited
buildbot@99419141cf36:/workdir$ ulimit -Hn
1073741816
buildbot@99419141cf36:/workdir$
```

On alpine (the same numbers) faked also gets lauched, and also takes 
100% CPU on a single core, but for some reason on alpine I see dozens of 
faked processes launched. Not sure how they related. Builds finish in 10 
or so minutes, so at least that's not so bad.



On my host, with systemd, I get far different numbers


```

% cat /proc/sys/fs/file-max
9223372036854775807
% cat /proc/sys/fs/nr_open
1073741816
%  ulimit -Hn
524288
% ulimit
unlimited

```

I'll find out if I can set ulimit during container creation/start to 
workaround the issue, but it's still quite annoying.


The reason for the ping/follow up? There where some good suggestions in 
this thread earlier, as having to close 524288 file descriptors isn't as 
bad as a billion, its still quite a lot of wasted resources for nothing. 
Think of the tree's ;)



Olliver