Bug#1069679: ofono: CVE-2023-2794

2024-04-22 Thread Moritz Mühlenhoff
Source: ofono
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for ofono.

CVE-2023-2794[0]:
| A flaw was found in ofono, an Open Source Telephony on Linux. A
| stack overflow bug is triggered within the decode_deliver() function
| during the SMS decoding. It is assumed that the attack scenario is
| accessible from a compromised modem, a malicious base station, or
| just SMS. There is a bound check for this memcpy length in
| decode_submit(), but it was forgotten in decode_deliver().

https://bugzilla.redhat.com/show_bug.cgi?id=2255387
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=a90421d8e45d63b304dc010baba24633e7869682
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=7f2adfa22fbae824f8e2c3ae86a3f51da31ee400
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=07f48b23e3877ef7d15a7b0b8b79d32ad0a3607e
https://git.kernel.org/pub/scm/network/ofono/ofono.git/commit/?id=8fa1fdfcb54e1edb588c6a5e260b065a39c9

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.



Bug#1069678: openjdk-8: CVE-2024-21011 CVE-2024-21068 CVE-2024-21085 CVE-2024-21094

2024-04-22 Thread Moritz Mühlenhoff
Source: openjdk-8
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for openjdk-8.

CVE-2024-21011[0]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle
| GraalVM Enterprise Edition product of Oracle Java SE (component:
| Hotspot).  Supported versions that are affected are Oracle Java SE:
| 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for
| JDK: 17.0.10, 21.0.2, 22;   Oracle GraalVM Enterprise Edition:
| 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows
| unauthenticated attacker with network access via multiple protocols
| to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM
| Enterprise Edition.  Successful attacks of this vulnerability can
| result in unauthorized ability to cause a partial denial of service
| (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle
| GraalVM Enterprise Edition. Note: This vulnerability can be
| exploited by using APIs in the specified Component, e.g., through a
| web service which supplies data to the APIs. This vulnerability also
| applies to Java deployments, typically in clients running sandboxed
| Java Web Start applications or sandboxed Java applets, that load and
| run untrusted code (e.g., code that comes from the internet) and
| rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7
| (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).

CVE-2024-21068[1]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle
| GraalVM Enterprise Edition product of Oracle Java SE (component:
| Hotspot).  Supported versions that are affected are Oracle Java SE:
| 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK:
| 17.0.10, 21.0.2 and  22; Oracle GraalVM Enterprise Edition: 21.3.9.
| Difficult to exploit vulnerability allows unauthenticated attacker
| with network access via multiple protocols to compromise Oracle Java
| SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.
| Successful attacks of this vulnerability can result in  unauthorized
| update, insert or delete access to some of Oracle Java SE, Oracle
| GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data.
| Note: This vulnerability can be exploited by using APIs in the
| specified Component, e.g., through a web service which supplies data
| to the APIs. This vulnerability also applies to Java deployments,
| typically in clients running sandboxed Java Web Start applications
| or sandboxed Java applets, that load and run untrusted code (e.g.,
| code that comes from the internet) and rely on the Java sandbox for
| security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).


CVE-2024-21085[2]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise
| Edition product of Oracle Java SE (component: Concurrency).
| Supported versions that are affected are Oracle Java SE: 8u401,
| 8u401-perf, 11.0.22; Oracle GraalVM Enterprise Edition: 20.3.13 and
| 21.3.9. Difficult to exploit vulnerability allows unauthenticated
| attacker with network access via multiple protocols to compromise
| Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful
| attacks of this vulnerability can result in unauthorized ability to
| cause a partial denial of service (partial DOS) of Oracle Java SE,
| Oracle GraalVM Enterprise Edition. Note: This vulnerability can be
| exploited by using APIs in the specified Component, e.g., through a
| web service which supplies data to the APIs. This vulnerability also
| applies to Java deployments, typically in clients running sandboxed
| Java Web Start applications or sandboxed Java applets, that load and
| run untrusted code (e.g., code that comes from the internet) and
| rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7
| (Availability impacts).  CVSS Vector:
| (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).


CVE-2024-21094[3]:
| Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle
| GraalVM Enterprise Edition product of Oracle Java SE (component:
| Hotspot).  Supported versions that are affected are Oracle Java SE:
| 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for
| JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13
| and  21.3.9. Difficult to exploit vulnerability allows
| unauthenticated attacker with network access via multiple protocols
| to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM
| Enterprise Edition.  Successful attacks of this vulnerability can
| result in  unauthorized update, insert or delete access to some of
| Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise
| Edition accessible data. Note: This vulnerability can be exploited
| by using APIs in the specified Component, e.g., through a web
| service which supplies data to the APIs. This vulnerability also
| applies to Java 

Bug#1069677: rust-rustls: CVE-2024-32650

2024-04-22 Thread Moritz Mühlenhoff
Source: rust-rustls
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for rust-rustls.

CVE-2024-32650[0]:
| Rustls is a modern TLS library written in Rust.
| `rustls::ConnectionCommon::complete_io` could fall into an infinite
| loop based on network input. When using a blocking rustls server, if
| a client send a `close_notify` message immediately after
| `client_hello`, the server's `complete_io` will get in an infinite
| loop. This vulnerability is fixed in 0.23.5, 0.22.4, and 0.21.11.

https://github.com/rustls/rustls/security/advisories/GHSA-6g7w-8wpp-frhj
https://github.com/rustls/rustls/commit/2123576840aa31043a31b0770e6572136fbe0c2d
 (v/0.23.5)
https://github.com/rustls/rustls/commit/6e938bcfe82a9da7a2e1cbf10b928c7eca26426e
 (v/0.23.5)
https://rustsec.org/advisories/RUSTSEC-2024-0336.html


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.



Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

2024-04-22 Thread Luca Boccassi
On Sat, 20 Apr 2024 20:48:06 +0100 Luca Boccassi 
wrote:
> On Mon, 15 Apr 2024 at 10:34, Peter Pentchev 
wrote:
> >
> > On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote:
> > > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit :
> > > >
> > > > > I'm pretty sure that we can, at some point in the future,
drop the
> > > > offending
> > > > > patch from the RPM package and all of this will be redundant.
It
> > > > just requires a
> > > > > bit of work to make sure that older use cases (mostly alien)
don't
> > > > break due to
> > > > > this, which might require a bit of development on RPM itself.
It's
> > > > on my TODO
> > > > > list for very rainy and boring days, but unfortunately
there's
> > > > almost always a
> > > > > truckload of other things to do, so I keep dragging it out.
> > > > >
> > > > >
> > > > >
> > > > > Mihai
> > > > >
> > > >
> > > > I fully agree on removing the RPM patch that causes all of our
issues
> > > > on packages depending on it. If needed, I'm willing to be part
of
> > > > reviewing what would be the impact of returning to a standard
RPM
> > > > package on Debian and to help into solving those issues. Don't
> > > > hesitate to ping me for that.
> > >
> > > I think the time has come to drop the RPM Debian-specific patches
and
> > > avoid these workarounds altogether.
> > >
> > > Once upon a time it made sense to redirect the RPM DB, and to go
out of
> > > our way to stop users installing RPMs locally, when RPMs were
popular
> > > as a way to distribute upstream applications.
> > >
> > > Nowadays, the most common way to distribute upstream apps is via
> > > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb
> > > repositories, so the chances someone tries to 'sudo rpm -i
foo.rpm' are
> > > very low.
> > >
> > > The main use of having rpm/dnf/zypper in Debian is not to convert
RPMs
> > > with Alien or so, but it's to be able to do cross-distribution
> > > bootstraps and image building using native tools, like we do in
mkosi
> > > (and in other tools as well).
> > >
> > > So these patches to print warnings and divert the database and so
on
> > > are a hindrance.
> > >
> > > Hence, for Trixie I think we should just drop them all.
> > >
> > > It should also make it easier to maintain the RPM stack, which
has
> > > languished. We are trying to move everything under the RPM Team
Salsa
> > > org, which should also help.
> > >
> > > If there are any objections please speak up.
> >
> > I've thought about making this change at least once a year, but
> > I have always been, hm, should I say "too careful" (when of course
> > I actually mean "too scared")... so if you feel the time has come,
> > yeah, go ahead!

This is now in experimental, unless I hear something I'll upload to
unstable during the weekend.

-- 
Kind regards,
Luca Boccassi


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


Bug#1069676: timeshift-launcher unable to start on fresh install. pkexec required but not listed as dependency.

2024-04-22 Thread MA Jansma
Package: timeshift
Version: 22.11.2-1
Severity: normal
X-Debbugs-Cc: marnixjan...@gmail.com

Dear Maintainer,

I manually installed timeshift using apt. I tried launching the graphical 
interface from the applications menu and it failed with no feedback. Running it 
from the terminal indicated that it tried to run pkexec and failed as it was 
not available. Installing pkexec manually resolved the issue. I suppose pkexec 
may need to be added as a dependency (perhaps optional, to enable the gui).

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

Kernel: Linux 6.1.0-20-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages timeshift depends on:
ii  cron [cron-daemon]   3.0pl1-162
ii  libc62.36-9+deb12u4
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libvte-2.91-00.70.6-2~deb12u1
ii  libxapp1 2.4.2-3
ii  psmisc   23.6-1
ii  rsync3.2.7-1

timeshift recommends no packages.

timeshift suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = (unset),
LC_TIME = "en_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory



Bug#1069675: pure-ftpd broken APPE after STOU

2024-04-22 Thread Federico Sabbatini
Package: pure-ftpd
Version: 1.0.50

When I run a STOU command I can't run an APPE properly. It seems to run a
STOR instead. Here is an example using Python's ftplib.

```python
#!/usr/bin/env python3
from ftplib import FTP


pureftp = FTP('ftphost')
pureftp.login('username', 'password')
pureftp.cwd('/www')
pureftp.set_debuglevel(1)

# If you comment these two lines it does work
with open('/etc/passwd', 'rb') as f:
pureftp.storbinary('STOU', f)


with open('/etc/passwd', 'rb') as f:
pureftp.storbinary('STOR test1', f)
with open('/etc/hosts', 'rb') as f:
pureftp.storbinary('APPE test1', f)
a = []
pureftp.retrbinary('RETR test1', a.append)
print(len(b''.join(a)))

pureftp.quit()

# pure-ftpd logs:
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [cwd] [/www]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [type] [I]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [pasv] []
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [stou] []
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [NOTICE]
/ftproot/www/pureftpd.66266b3c.02. uploaded  (2638 bytes, 1228.57KB/sec)
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [cwd] [/www]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [type] [I]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [pasv] []
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [stor] [test1]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [NOTICE]
/ftproot/www/test1 uploaded  (2638 bytes, 1558.52KB/sec)
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [type] [I]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [pasv] []
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [appe] [test1]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [NOTICE]
/ftproot/www/test1 uploaded  (1124 bytes, 750.19KB/sec)
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [type] [I]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [pasv] []
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [DEBUG]
Command [retr] [test1]
# Apr 22 13:50:52 ftphost pure-ftpd: (username@192.168.74.254) [NOTICE]
/ftproot/www/test1 downloaded  (1124 bytes, 3420.43KB/sec)
```

As you can see from the logs, it uploads 2638 bytes with STOU to a file with
a random name.
Then it creates a new file (named test1) with 2368 bytes. Then it appends
another 1124 bytes to the same file. 
As you can see from the RETR, the retrieved bytes are only 1124 instead of
the expected 3762 (it only contains /etc/hosts instead of passwd + hosts).
It means it interpreted APPE as STOR after a STOU was performed.



Bug#1060330: sccache: Please enable distributed storage before the migration to testing/next release

2024-04-22 Thread Jonas Smedegaard
Quoting Sylvestre Ledru (2024-04-22 15:28:30)
> Le 09/01/2024 à 23:27, Jonas Smedegaard a écrit :
> > Quoting Sylvestre Ledru (2024-01-09 19:07:47)
> >> I really would like to avoid shipping sccache without distributed support.
> >> Currently, these key features have been disabled:
> >> https://salsa.debian.org/debian/sccache/-/blob/debian/latest/debian/patches/2002_no_opendal_backends.patch
> >>
> >> Happy to help with the packaging of opendal if it helps.
> > I would appreciate help packaging opendal.
> 
> Done:
> 
> https://tracker.debian.org/pkg/rust-opendal

Yes, I noticed already.  That's great!

> Could you please enable it in the next upload? Thanks!

Not exactly the next, but yes: I will first upload to experimental, to
ensure that the introduction of these added features do not cause
regressions in Debian - e.g. failure to build on some weaker
architectures, which are already struggling.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

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

signature.asc
Description: signature


Bug#1069674: openssh-client: multiplexed connections use incorrect DISPLAY etc, but no TOKENS exist to modify the connection socket

2024-04-22 Thread Tim Connors
Package: openssh-client
Version: 1:9.2p1-2+deb12u2
Severity: normal


With .ssh/config:

ControlMaster auto
ControlPath ~/.ssh/cm_master/%r@%h:%p
ControlPersist yes

Set up the mux master on host a to host c:

> echo $DISPLAY
:0
> ssh c xterm

xterm fires up on host a.  Kill that

Now, if we arrange for DISPLAY to point to another display (I sshed to
another host b, set DISPLAY=:0, verified xterm opened up on that host,
then sshed back to my original host a), and try to fire up ssh again:

> echo $DISPLAY
localhost:11.0
> ssh c xterm

xterm fires up on host a instead of host b, which was where $DISPLAY
was pointing.

OK, so the muxing protocol isn't smart enough to allow DISPLAY to be
dynamically set (a bit like bug #931187, ssh not properly acting as if
a new connection has been made and handing out /etc/motd properly).
So let's work around it by setting ControlPath according to what
DISPLAY is being asked for.  Hmmmf, there are no appropriate TOKENS.

Perhaps there should be a %D TOKEN value for $DISPLAY?  Or since I'm
sure there's other connection properties that shouldn't be shared
between multiplexed connections, can the protocol be modified to allow
DISPLAY and other values to be properly set per multiplexed
connection?



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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 openssh-client depends on:
ii  adduser   3.134
ii  libc6 2.36-9+deb12u4
ii  libedit2  3.1-20221030-2
ii  libfido2-11.12.0-2+b1
ii  libgssapi-krb5-2  1.20.1-2+deb12u1
ii  libselinux1   3.4-1+b6
ii  libssl3   3.0.11-1~deb12u2
ii  passwd1:4.13+dfsg1-1+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1

Versions of packages openssh-client suggests:
ii  keychain  2.8.5-3
pn  libpam-ssh
pn  monkeysphere  
ii  ssh-askpass   1:1.2.4.1-16

-- Configuration Files:
/etc/ssh/ssh_config changed [not included]

-- no debconf information



Bug#1060330: sccache: Please enable distributed storage before the migration to testing/next release

2024-04-22 Thread Sylvestre Ledru

Hello,

Le 09/01/2024 à 23:27, Jonas Smedegaard a écrit :

Quoting Sylvestre Ledru (2024-01-09 19:07:47)

I really would like to avoid shipping sccache without distributed support.
Currently, these key features have been disabled:
https://salsa.debian.org/debian/sccache/-/blob/debian/latest/debian/patches/2002_no_opendal_backends.patch

Happy to help with the packaging of opendal if it helps.

I would appreciate help packaging opendal.


Done:

https://tracker.debian.org/pkg/rust-opendal

Could you please enable it in the next upload? Thanks!


Personally I have no need for distributed storage, so motivitation for
getting that done is low, but would certainly be happy to keep it afloat
if you and others (in the Rust team, I guess) were to help out with
maintaining the needed dependencies.


Yeah. sccache is also very interesting for cloud storage.

Thanks again,
Sylvestre



Bug#1069673: RM: openstack-nose -- ROM; obsolete, nose removal

2024-04-22 Thread Thomas Goirand
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: openstack-n...@packages.debian.org
Control: affects -1 + src:openstack-nose

Hi,

Swift was the only use of this plugin, but I have just uploaded removing
that build-depends from Swift, so this package can go.

Please remove openstack-nose from Debian.

Cheers,

Thomas Goirand (zigo)



Bug#1069672: bookworm-pu: package flatpak/1.14.6-1~deb12u1 or 1.14.7-1~deb12u1

2024-04-22 Thread Simon McVittie
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: flat...@packages.debian.org
Control: affects -1 + src:flatpak

After the dust has settled from CVE-2024-32462, I would like to do a
stable-update of Flatpak using the upstream 1.14.x branch.

At the moment bookworm-security has 1.14.4 plus the patches for
CVE-2024-32462. The current upstream release is 1.14.6 (also available in
unstable and in testing-proposed-updates), which moves the security fix
from patches into the upstream source and fixes various less serious bugs.

We are also hoping to do a 1.14.7 upstream release soon, perhaps this
week. Would the stable release team prefer this to be proposed as one
big update from 1.14.4 to 1.14.7, or two smaller updates
1.14.4 → 1.14.6 → 1.14.7, or do you not mind either way?

[ Impact ]
If not accepted, several known bugs remain present in stable.
The highest-visibility is that the developer name of an app appears
in the CLI where the app name should be, for example "The Chromium Authors"
instead of the correct "Chromium Web Browser".

Also, if we keep up with upstream stable releases, then next time there
is a CVE, we can take upstream's stable release directly instead of
having to backport individual patches.

[ Tests ]
There is a fairly comprehensive test suite. It cannot be run under schroot
or lxc due to limitations of nested containers, but I run in
autopkgtest-virt-qemu before each upload, and ci.debian.net has now been
configured to run flatpak's tests under autopkgtest-virt-qemu has well.

I will test a final version manually on a bookworm system before upload.

[ Risks ]
Somewhat low risk, all changes are targeted bug fixes. I would say that
the highest-risk are the alterations to how AppStream metadata is parsed
and displayed, but several distributions are already using those changes
via the 1.15.x branch and we have not had regression reports.

[ Checklist ]
The changes in 1.14.7 will not be finalized until the release actually
happens, but I have reviewed and attached a proposed diff.

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

[ Changes in 1.14.5 and 1.14.6 ]
See attached flatpak-1.14.6-bookworm.diff.gz

* Makefile.am,
  configure.ac,
  data/Makefile.am.inc,
  data/tmpfiles.d/flatpak.conf,
  debian/flatpak.install,
  sideload-repos-systemd/Makefile.am.inc:
  - Delete obsolete /var/tmp/flatpak-cache-* (if any) during boot

* app/flatpak-builtins-build.c,
  common/flatpak-dir.c,
  common/flatpak-run.c,
  tests/test-run.sh:
  - Fix CVE-2024-32462 (previously done via a patch)

* app/flatpak-builtins-remote-info.c:
  - Fix display of app info in `flatpak remote-info`
  - Fix some uses of deprecated libappstream API
  - Forward-compatibility with libappstream 0.17.x and 1.0

* app/flatpak-builtins-remote-ls.c,
  app/flatpak-builtins-search.c,
  app/flatpak-builtins-utils.c,
  app/flatpak-builtins-utils.h,
  config.h.in,
  configure.ac:
  - Fix some uses of deprecated libappstream API
  - Forward-compatibility with libappstream 0.17.x and 1.0

* app/flatpak-builtins-run.c,
  common/flatpak-dir.c,
  tests/testlibrary.c:
  - Silence some compiler warning false-positives

* common/flatpak-appdata.c,
  tests/make-test-app.sh,
  tests/test-info.sh:
  - Don't parse the app developer name as though it was the app name

* common/flatpak-run.c,
  doc/flatpak-run.xml:
  - Don't let the sandboxed app inherit a wrong value for $VK_DRIVER_FILES,
$VK_ICD_FILENAMES

* common/flatpak-utils-http.c:
  - Cancel downloads if they become very slow

* common/flatpak-utils.c,
  tests/test-exports.c,
  tests/test-instance.c:
  - Forward-compatibility with newer GLib releases

* NEWS,
  common/flatpak-version-macros.h,
  configure.ac,
  tests/package_version.txt:
  - The usual release management noise

* debian/test.sh:
  - Unset proxy environment variables to make sure a test http server on
localhost is reachable

* doc/flatpak-metadata.xml:
  - Provide anchors for internal linking
  - Clarify documentation on which D-Bus names are allowed by default

* doc/reference/html/*.html:
  - Regenerated with Debian 12 toolchain
(these are also re-regenerated during build)
  (Filtered from debdiff)

* po/*.po,
  po/flatpak.pot:
  - Regenerated during upstream release procedure (different line numbering)
  (Filtered from debdiff)

* portal/flatpak-portal.c:
  - Save the original environment before setting GIO_USE_VFS, and restore it
before starting sandboxed programs, so that GVfs can work

* revokefs/main.c:
  - Forward-compatibility with libostree 2023.4

* session-helper/flatpak-session-helper.c:
  - Same as portal/, but for programs run on the host system by trusted
Flatpak apps

* tests/make-test-runtime.sh:
  - Fail tests earlier, with a better error message, if a 

Bug#1069671: linux-image-6.6.15-amd64: stalled processes

2024-04-22 Thread Michael Becker
Package: src:linux
Version: 6.6.15-2
Severity: normal

If I start a compile run on a ramdisk or download a file of some GB to the 
ramdisk and switch to another virtual desktop in the meantime to browse the 
internet I often have the effect theaz the make or download is stalled during 
my activity on the other virtual desktop.
The system has 64GB memory and 8 cores. It is far from beeing overloaded – so 
why are processes stalled?


-- Package-specific info:
** Version:
Linux version 6.6.15-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-13) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP 
PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.6.15-amd64 
root=UUID=3bea0c09-9dee-4690-b00f-ac1d12366926 ro amdgpu.dcdebugmask=0x10 quiet

** Not tainted

** Kernel log:
[676326.843496] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[676337.178902] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[677034.534722] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[677034.834756] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[677045.181949] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[679997.486382] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[679997.782385] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[680008.121864] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[680982.314820] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[680982.610555] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[680992.954585] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[694239.164874] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[694239.464885] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[694249.808989] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[696386.222582] perf: interrupt took too long (4052 > 3991), lowering 
kernel.perf_event_max_sample_rate to 49250
[702209.448465] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[702209.748782] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[703274.002900] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[703274.299055] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[703284.642775] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[705899.455574] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[705899.755210] usb 1-5: reset full-speed USB device number 4 using xhci_hcd
[705912.422144] audit: type=1400 audit(1713721841.403:62): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931" pid=618404 
comm="apparmor_parser"
[705912.422262] audit: type=1400 audit(1713721841.403:63): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931//passt" pid=618404 
comm="apparmor_parser"
[705912.515903] audit: type=1400 audit(1713721841.499:64): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931" pid=618407 
comm="apparmor_parser"
[705912.555183] audit: type=1400 audit(1713721841.539:65): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931//passt" 
pid=618407 comm="apparmor_parser"
[705912.650726] audit: type=1400 audit(1713721841.635:66): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931" pid=618411 
comm="apparmor_parser"
[705912.675354] audit: type=1400 audit(1713721841.659:67): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931//passt" 
pid=618411 comm="apparmor_parser"
[705912.773385] audit: type=1400 audit(1713721841.755:68): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931" 
pid=618415 comm="apparmor_parser"
[705912.773467] audit: type=1400 audit(1713721841.755:69): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931//passt" 
pid=618415 comm="apparmor_parser"
[705912.794063] virbr0: port 1(vnet0) entered blocking state
[705912.794072] virbr0: port 1(vnet0) entered disabled state
[705912.794082] vnet0: entered allmulticast mode
[705912.794172] vnet0: entered promiscuous mode
[705912.794495] virbr0: port 1(vnet0) entered blocking state
[705912.794501] virbr0: port 1(vnet0) entered listening state
[705912.884088] audit: type=1400 audit(1713721841.867:70): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="libvirt-95a61e4e-cf72-4fb8-834e-01419643e931" 

Bug#1069614: erfs: isolation-machine autopkgtest fails: sshfs failed

2024-04-22 Thread Skyper x
The erfs service was shut down and this tool is no longer functional. It should 
be removed.

> On 21 Apr 2024, at 14:57, Paul Gevers  wrote:
> 
> Source: erfs
> Version: 1.4-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: isolation-machine
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. I recently added support for 
> isolation-machine tests on ci.debian.net for amd64 and added your package to 
> the list to use that. However, it fails. Can you please investigate the 
> situation and fix it? I copied some of the output at the bottom of this 
> report.
> 
> The release team has announced [1] that failing autopkgtest on amd64 and 
> arm64 are considered RC in testing, but because machine-isolation support by 
> ci.debian.net is new I have not marked this bug as serious (yet).
> 
> More information about this bug and the reason for filing it can be found on 
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html
> 
> https://ci.debian.net/packages/e/erfs/testing/amd64/45706002/
> 
> 49s autopkgtest [13:48:31]: test upstream-tests: [---
> 50s read: Connection reset by peer
> 50s ERROR: sshfs failed.
> 50s 1. The volume is already mounted.
> 50s 2. Wrong SHARE-SECRET.
> 50s 3. The server can not be reached.
> 50s autopkgtest [13:48:32]: test upstream-tests: ---]
> 



Bug#1069670: RFP: qft -- Resilient P2P UDP file transfer

2024-04-22 Thread Jari Aalto
Package: wnpp
Severity: wishlist

* Package name: qft
  Version : 0.5.6
  Upstream Author : 
* URL : https://github.com/tudbut/qft
* License : GP-3
  Programming Lang: Rust
  Description : Resilient P2P UDP file transfer

UDP file transfer program for two clients
sending their data directly to eachother,
without a server. contains reliability
measures in place to avoid broken files. With
shaky connections, QFT can pause transmission
until the connection is back. Resume can be
done after fully stopped transfer (e.g. PC
hibernate or suspend). Transferring wil
continue where it left of. Even latency of
1000ms network connections can be used.



Bug#1069669: rust-uuid: please update to v1.7

2024-04-22 Thread Jonas Smedegaard
Source: rust-uuid
Version: 1.6.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.7.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmQIMACgkQLHwxRsGg
ASGiYxAAgc4JllgdS/GE3ZncxV3cjeIqFfVxyBNHXV5yXOJHYPKHm4FKQUJIdolY
Pc2aEmXqa8XSjLJy1xF+8Jz7M7WGNJiHHvoPzZLJQgkl9IRbtArxUZMWrtL0Iapz
MZpM279LGHTbQ2XcIOmcda5eHfiQ3Ho3/Hla9ztpibEaOrGKhinophVxvbndQTF1
4j9YidFSDT8fUI+v4Lyc9HIFCUWJkUZ/Px9aeHP5Do2D6ljf0oRRusHW5rKOdRjh
8WfIsvkAW1PV0J8xk/PPrtW5rvgB/3ajp0Vaskqp1owTRc0OZLqn2q8L7+v8ILk4
3SfFlHHcXAmZ7/XYXnX7JxcCya6pbHZHAKjfU6+pLj397gyxMcPZEAZv3dRQ6RuO
apTWLaeBCgijAvaMR/c1PLJgQUviiY7G1g6wZQpOB7WP8htCe2fr4psoJz9lTU2T
xaiSubwA9s0zBnm7MuV8aAsvNv57DLRBlSu1v7FgI1ybolJmax5F0aw4FH+7BU+8
c8ugwtQWG/p4jWefwdbQJQI0Z6ASCHqtdcBTaVaEmMZ0lqTy8dzeO77q98Qn0Nsy
K0Y9dOslDfHCARJ97feas7IAaDLRetjZlXHbFij/Qb7pyhsLDJgTC3o6duTu+CX1
xYNo+2WRKccByW8ur0GK8SslphEskU7+zvalsUY2C7stEEKuX44=
=b7f5
-END PGP SIGNATURE-



Bug#1069668: python3-colored: Please provide PEP-0561 "py.typed" marker

2024-04-22 Thread Niels Thykier

Package: python3-colored
Version: 2.2.3-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: ni...@thykier.net

Hi

When depending on `python3-colored` and using `mypy`, `mypy` will 
complain about `python3-colored` is not typed. Upstream does seem to 
have some typing, but has not marked the their library has typed in a 
PEP-0561 complaint way.


As I understand the PEP, all that is needed is that 
`/usr/lib/python3/dist-packages/colored/py.typed` exists as an empty 
file in this case (a simple `touch` in `debian/rules` would be 
sufficient as a work around for now). I have tried that locally and that 
seems to solve my `mypy` error.


This is really an upstream bug. I have not reported this to upstream as 
they are on `gitlab.com`, since I do not have an account there. For 
upstream, there is guidance in PEP-0561 
(https://peps.python.org/pep-0561/). But basically it is creating the 
empty file and ensuring it is included in the dist (usually via 
`setup(..., package_data=...)` or similar).


Best regards,
Niels



Bug#1069667: rust-chrono: please update to v0.4.33

2024-04-22 Thread Jonas Smedegaard
Source: rust-chrono
Version: 0.4.31-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.4.33.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmPp4ACgkQLHwxRsGg
ASEAzA//VljX4rTfNSgAKqIZ8HUWJIQKAhcFCOQx4oVlyo4Kqez2bdy5zkRiF2Rb
cxyqyPqKQ5QcDqhNN1Rkrg2cG7oExiVwxXQhrZ9DytYCwGOXRXrCAd+ZPdc5g5Ta
7mlt739wxKAO879K8omCrrJySfgMLmcQJ4xDjHHGrr1yWzGqNZ9h9n18i/MB49se
P32v4ZSaZbKODffy3txLFbmg5DE337mT+JUwJhrtb3ZwLxFe4Fuzzykj0stPw+6b
meyJEbRruIQu/DIoRxBq/rNGXQj/th95MKCTbR+l9SRutXt3alcusLdW5jViE5Ix
E8Na7QIzakhZAob4IBHaMzE2+y+U4UlUnXrzdfXXFHTDOSPszJ7gvF2z4jJOuyjB
gsKp7X2zURXkQ/UPQQVb8TWI8TIGfy7Z1o4oz3mNH3GWsKGboRzpDlpvrsHclcbn
CrmvbGgD+Leze70QjFwfyHW0Ucp+fo/PfBKp9TqK8aHZS+TH9Xxfojz/7zZscYq5
gkZDMOcyxnKmqFoopO+IdFCVntbm2WCEtiHbDNHZQEYRYMYkxehCrkORpjYbfOXQ
+0+zknRSwU68N2CvigkVHU+Rmj6VzeZpdETypDU8ksfG8oKSUcDcSTwaahfRURf0
VUkXinsu97ecHKE9URB1RGwIv7rK7B9SNDGXCXzoJfO77IL5umY=
=Mq5K
-END PGP SIGNATURE-



Bug#1064459: refining DEP17 patches for glibc and base-files

2024-04-22 Thread Santiago Vila

I've updated my demo repository with your patch.

https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo/-/commit/6425c8cde53596199cd37bb1625d1dfb2a4b74d0


Great. I'll take a look.


I'm happy to call it guest upload while I find team upload slightly
misleading.

I avoid patching changelogs in the demo to avoid the need for
unnecessary rebasing. It's a functional demo.

For util-linux, I think Chris will send me an encrypted version of a
signed .changes file such that I only perform the upload not even the
signing. Please let me know if you prefer that approach.


I'd like to use that approach too. At least until I make
the package reproducible-from-git (which currently it's not).

BTW: There is a minor glitch in postinst which I introduced
a long time ago: /var/run and /var/lock are created
as real directories, but then, at debootstrap time, the
function migrate_directory() function converts them to symlinks.

(I do not remember why it's done that way, maybe shipping
a real symlink would confuse dpkg?)

Do you think I should try to do this in a more orthodox way?
Or maybe it does not worth the effort?

(I ask because, as in the usr-merge patch, this is also
about "avoiding dpkg to follow symlinks")

Thanks.



Bug#1066491: libt3window: FTBFS: .config.c:8:13: error: implicit declaration of function ‘setupterm’; did you mean ‘set_term’? [-Werror=implicit-function-declaration]

2024-04-22 Thread Bo YU

Hi,
On Wed, Mar 13, 2024 at 12:52:51PM +0100, Lucas Nussbaum wrote:

https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration

Relevant part (hopefully):

gcc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection `pkg-config 
--cflags tinfo` -c -o .config.o .config.c
.config.c: In function ‘main’:
.config.c:8:13: error: implicit declaration of function ‘setupterm’; did you 
mean ‘set_term’? [-Werror=implicit-function-declaration]
8 | if (setupterm(NULL, fd, ) == OK) {
  | ^
  | set_term
.config.c:12:17: error: implicit declaration of function ‘tputs’; did you mean 
‘puts’? [-Werror=implicit-function-declaration]
   12 | tputs("\033[0m", 1, putchar);
  | ^
  | puts
cc1: some warnings being treated as errors
make[2]: *** [.Makefile:19: .config.o] Error 1


I have sent one RFS[0] to fix the issue.

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069662

Regards,
--
  Bo YU



signature.asc
Description: PGP signature


Bug#1059412: netcat-openbsd: diff for NMU version 1.226-1.1

2024-04-22 Thread Guilhem Moulin
Hi Chris,

On Mon, 22 Apr 2024 at 01:43:26 +0200, Chris Hofstaedtler wrote:
> I've prepared an NMU for netcat-openbsd (versioned as 1.226-1.1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I
> should delay it longer.

Ooops sorry, that bug fell off-screen.  No issue with the NMU, feel free
to push your changes to the repository too.

Cheers
-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#1069666: python-levenshtein: Current upstream looks dead, consider rebasing on https://github.com/rapidfuzz/Levenshtein

2024-04-22 Thread Niels Thykier

Package: python3-levenshtein
Version: 0.12.2-2+b5
Severity: normal
X-Debbugs-Cc: ni...@thykier.net


Hi

Based on the discussions in
https://github.com/ztane/python-Levenshtein/issues/86, it seems that the 
current upstream has been superseded by 
https://github.com/rapidfuzz/Levenshtein/


This also fits with https://pypi.org/project/Levenshtein/ referencing 
https://rapidfuzz.github.io/Levenshtein/ as documentation page and 
https://github.com/rapidfuzz/Levenshtein being the (current) project 
homepage.


Please migrate to rapidfuzz's Levenshtein since it seems to be actively 
maintained, it provides proper Python type hints and other improvements.


Best regards,
Niels



Bug#1053334: galera-4: FTBFS because of expired certificates

2024-04-22 Thread Santiago Vila

El 22/4/24 a las 8:47, Otto Kekäläinen escribió:

I was able to reproduce this for Bookworm both locally and in CI at
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/5620032

After importing latest upstream build/test passes:
https://salsa.debian.org/otto/galera/-/jobs/5624466

Stable upload request filed at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069639


Thanks a lot!

What about bullseye, which is also a supported distribution?

I have not reached the point where I want to do NMUs for these kind
of bugs, but if this were my package, I would certainly do an upload
for bullseye as well. If I can be of any help, please say so.

Thanks.



Bug#1069665: rust-predicates: please update to v3.1.0

2024-04-22 Thread Jonas Smedegaard
Source: rust-predicates
Version: 3.0.3-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v3.1.0.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmORQACgkQLHwxRsGg
ASF+tg/8DG400xCN1hEZaKkwaRaoKek0+RGc0sKpgGJWnBjd6gg20k3ybrEYTC5j
2eef1MIW1vhQsCdH6TMU14+EOGmODv0L+Z/wlaq3gkDhPNWvnI1De0TwW26NJozX
qKHC5roXUVzuSLfljdhaRuaToC/yu3BfHwMU6LCHCfI1G2n6V9fB/qO7uUq1W3Dy
fDyaacxd/tOdJDSvXLornRmjBOuYOFpqlQzh+r35Wr2fqiBjlqvaJxG8eq5KqVK2
FItP5ctU8CSOiSwU4ta4rWppMxvgaCZZ1v9vnue7H6MIfkV+BazK4jen5Xq2+6r3
3EpFeiVLnt6Ca2PBKMyFdYIbL37qVPLiq9wqeQFovIy9zVn6QhSpV/I+S35IqQAD
LSkDM7w/cOs32YUuoKqd4+7L2uMjd5q7nf7GONWFkpM2Nhy1aChtNGbwhm2ptkEH
Gid6DPzA04BBO+DRuO/AWHaZoKncstOKzXDr7lENrYRvMbjKdBWAq3MuV4sBMX1E
vvPdZIEmjJnZtRpjUYueQHpqsCx6fV9FRPyF3xLiLYZHuzXYBNI+gz+fnUyJr64L
ZPvrA8aGOTXOs8OsNPiepGC9ViZQlI9XWfTp/yGeU6OM5KP1/MVHfdS2EHZmZ5Ga
SwUaXFyw3WzrFDLbVK4sftEzfdqQnYHqvTA6YH8lDOX2giAwOAM=
=hdHB
-END PGP SIGNATURE-



Bug#1069664: rust-is-terminal: please update to v0.4.12

2024-04-22 Thread Jonas Smedegaard
Source: rust-is-terminal
Version: 0.4.9-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.4.12.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmOKIACgkQLHwxRsGg
ASFbpQ/5AcvtmvOUinKN2P1w7B3qNZiUR80dXH0lVW9KS4tKCfCaxJRFvNGLMeLf
remldYCelff66LSkMsc912Sg55T+qKCwb9/80SO3/u2JLjawG+HnTgReMrvhyzxG
RLatHV1bpySOm7kUTyaUpuWESd8SNQJNTu6WjSfWEUx7R0+c77e1EaHqqrqn+ReS
wUOpWxRs3jHUIZL8p0qWdobp4mmIpp+rUHuJ/bv1kMVzeY/3VkVRHxeNzA0Jgj5r
tL2CG1Hbud/SbafZPvEOkjwJjtwPxysMjmvriNJSgsVLiMGEEDznqR3BP0kpw+nO
rbwz0NtKCAKx5yo4k8v1iZ28NvtcY0Gkcy8QVqFQNJnT6mgJr4FQpkNUAfcXosCN
/II2GXuk8P9lsbPufAsUYYr7HIQenoIb2rC09j9xDz5oipcWDObxaAIv2TBNbK+g
bh75/EEV6ODfK6pwjO4kxPruAY6PGkadbVPvYf2gX+wvJUTroihI92mRpyXjqxa+
atCMu0KTGgZduJuA3EXTUjL+zseWL9tNJpZjznHNwPfFlST6QciPvpTSuicILZUU
1H3hq5vcBDlkrnYAyQgpKkGMV1dVYsJPKoirfbk2C+NGdqblcT8WMqPyz+0qCrrE
H+VvJvR9pmyd+Vr2sUEUsH+bPgT/Ayt9OIKKPPfptH4MPMSaaeI=
=mbEN
-END PGP SIGNATURE-



Bug#1069102: Acknowledgement (linux-image-6.1.0-20-amd64 and cifs mount problem on some folders which get hidden on shares)

2024-04-22 Thread Manfred Larcher

Hi,
any news on this?
Regards
Manfred

Am 16.04.24 um 14:21 schrieb Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

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

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

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

Your message has been sent to the package maintainer(s):
  Debian Kernel Team 

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

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





Bug#1060448: patches for both debcheckout and chdist

2024-04-22 Thread Georgios Zarkadas
The attached patches, for the git repository at salsa.debian.org,
remove the depreciation warnings.

I have installed them in my system (version of devscripts: 2.23.7)
and they appear to work fine till now (note: I have tested only git,
bzr and svn repositories; could not find other types).

Cheers,
Georgios
diff --git a/scripts/chdist.pl b/scripts/chdist.pl
index b473b954..52832ed5 100755
--- a/scripts/chdist.pl
+++ b/scripts/chdist.pl
@@ -707,72 +707,53 @@ sub parseFile {
 my $recursed = 0;
 MAIN:
 my $command = shift @ARGV;
-given ($command) {
-when ('create') {
-dist_create(@ARGV);
-}
-when ('apt') {
-aptcmd('apt', @ARGV);
-}
-when ('apt-get') {
-aptcmd('apt-get', @ARGV);
-}
-when ('apt-cache') {
-aptcmd('apt-cache', @ARGV);
-}
-when ('apt-file') {
-apt_file(@ARGV);
-}
-when ('apt-rdepends') {
-aptcmd('apt-rdepends', @ARGV);
-}
-when ('aptitude') {
-aptcmd('aptitude', @ARGV);
-}
-when ('bin2src') {
-bin2src(@ARGV);
-}
-when ('src2bin') {
-src2bin(@ARGV);
-}
-when ('compare-packages') {
-dist_compare(@ARGV, 0, 'Sources');
-}
-when ('compare-bin-packages') {
-dist_compare(@ARGV, 0, 'Packages');
-}
-when ('compare-versions') {
-dist_compare(@ARGV, 1, 'Sources');
-}
-when ('compare-bin-versions') {
-dist_compare(@ARGV, 1, 'Packages');
-}
-when ('grep-dctrl-packages') {
-grep_file(@ARGV, 'Packages');
-}
-when ('grep-dctrl-sources') {
-grep_file(@ARGV, 'Sources');
-}
-when ('compare-src-bin-packages') {
-compare_src_bin(@ARGV, 0);
-}
-when ('compare-src-bin-versions') {
-compare_src_bin(@ARGV, 1);
-}
-when ('list') {
-list;
-}
-default {
-my $dist = $command;
-my $dir  = "$datadir/$dist";
-if (-d $dir && !$recursed) {
-splice @ARGV, 1, 0, $dist;
-$recursed = 1;
-goto MAIN;
-} elsif ($dist && !$recursed) {
-dist_check($dist);
-} else {
-usage(1);
-}
+if ($command eq 'create') {
+dist_create(@ARGV);
+} elsif ($command eq 'apt') {
+aptcmd('apt', @ARGV);
+} elsif ($command eq 'apt-get') {
+aptcmd('apt-get', @ARGV);
+} elsif ($command eq 'apt-cache') {
+aptcmd('apt-cache', @ARGV);
+} elsif ($command eq 'apt-file') {
+apt_file(@ARGV);
+} elsif ($command eq 'apt-rdepends') {
+aptcmd('apt-rdepends', @ARGV);
+} elsif ($command eq 'aptitude') {
+aptcmd('aptitude', @ARGV);
+} elsif ($command eq 'bin2src') {
+bin2src(@ARGV);
+} elsif ($command eq 'src2bin') {
+src2bin(@ARGV);
+} elsif ($command eq 'compare-packages') {
+dist_compare(@ARGV, 0, 'Sources');
+} elsif ($command eq 'compare-bin-packages') {
+dist_compare(@ARGV, 0, 'Packages');
+} elsif ($command eq 'compare-versions') {
+dist_compare(@ARGV, 1, 'Sources');
+} elsif ($command eq 'compare-bin-versions') {
+dist_compare(@ARGV, 1, 'Packages');
+} elsif ($command eq 'grep-dctrl-packages') {
+grep_file(@ARGV, 'Packages');
+} elsif ($command eq 'grep-dctrl-sources') {
+grep_file(@ARGV, 'Sources');
+} elsif ($command eq 'compare-src-bin-packages') {
+compare_src_bin(@ARGV, 0);
+} elsif ($command eq 'compare-src-bin-versions') {
+compare_src_bin(@ARGV, 1);
+} elsif ($command eq 'list') {
+list;
+} else {
+my $dist = $command;
+my $dir  = "$datadir/$dist";
+if (-d $dir && !$recursed) {
+splice @ARGV, 1, 0, $dist;
+$recursed = 1;
+goto MAIN;
+} elsif ($dist && !$recursed) {
+dist_check($dist);
+} else {
+usage(1);
 }
 }
+
diff --git a/scripts/debcheckout.pl b/scripts/debcheckout.pl
index 33520e78..85a63f3f 100755
--- a/scripts/debcheckout.pl
+++ b/scripts/debcheckout.pl
@@ -416,18 +416,14 @@ sub set_destdir($$@) {
 my ($repo_type, $destdir, @cmd) = @_;
 $destdir =~ s|^-d\s*||;
 
-given ($repo_type) {
-when ("cvs") {
-my $module = pop @cmd;
-push @cmd, ("-d", $destdir, $module);
-}
-when (/^(bzr|darcs|git|hg|svn)$/) {
-push @cmd, $destdir;
-}
-default {
-die
+if ($repo_type eq "cvs") {
+my $module = pop @cmd;
+push @cmd, ("-d", $destdir, $module);
+} elsif ($repo_type =~ /^(bzr|darcs|git|hg|svn)$/) {
+push @cmd, $destdir;
+} else {
+die
 "sorry, don't know how to set the destination directory for $repo_type repositories (patches welcome!)\n";
-}
 }
 return @cmd;
 }
@@ -461,20 +457,14 @@ sub set_auth() {
 # other providers
 $url =~ s!(?:git|https?)://github\.com/!git\@github.com:!;
 
-given ($repo_type) {
-when ("bzr") {
-$url
-  =~ s[^\w+://(?:(bazaar|code)\.)?(launchpad\.net/.*)][bzr+ssh://${user}bazaar.$2];
-}
-when ("git") 

Bug#1069663: dub: please make the build reproducible

2024-04-22 Thread Chris Lamb
Source: dub
Version: 1.36.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
dub could not be built reproducibly.

This is because the build system embeds timestamps in its man pages:

├── ./usr/share/man/man1/dub-add-local.1.gz
│ ├── dub-add-local.1
│ │ @@ -1,8 +1,8 @@
│ │ -.TH DUB-ADD-LOCAL 1 "2025-05-24" "The D Language Foundation" "The D 
Language Foundation"
│ │ +.TH DUB-ADD-LOCAL 1 "2024-04-21" "The D Language Foundation" "The D 
Language Foundation"

(etc.)

A patch is attached that simply exports dub's custom DIFFABLE
environment variable. This was seemingly introduced to make these
manpages, well, 'diffable' — that is to say, so that they generated in
a deterministic manner.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2024-04-22 10:34:28.039060412 +0100
--- b/debian/rules  2024-04-22 10:48:00.675980092 +0100
@@ -6,7 +6,7 @@
 DEB_VERSION := $(shell dpkg-parsechangelog | awk '/^Version: / { print $$2 }')
 
 export GITVER=$(DEB_VERSION)
-
+export DIFFABLE=1
 export DFLAGS=-frelease -fall-instantiations
 
 %:


Bug#1069662: RFS: libt3window/0.4.0-1.1 [NMU] [RC] -- Library for creating window-based terminal programs

2024-04-22 Thread Bo YU
Package: sponsorship-requests
Severity: important
Tags: patch
X-Debbugs-Cc: 1066...@bugs.debian.org


Dear mentors,

I am looking for a sponsor for my package "libt3window":

 * Package name : libt3window
   Version  : 0.4.0-1.1
   Upstream contact : Gertjan Halkes 
 * URL  : https://os.ghalkes.nl/t3/libt3window.html
 * License  : GPL-3
 * Vcs  : [fill in URL of packaging vcs]
   Section  : libs

The source builds the following binary packages:

  libt3window-dev - Development files for libt3window
  libt3window0 - Library for creating window-based terminal programs

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

  https://mentors.debian.net/package/libt3window/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libt/libt3window/libt3window_0.4.0-1.1.dsc

Changes since the last upload:

 libt3window (0.4.0-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add 00-fix-implicit-function-declaration.patch to fix impfuncdef
 issue. (Closes: #1066491)


-- 
Regards,
--
  Bo YU

diff -Nru libt3window-0.4.0/debian/changelog libt3window-0.4.0/debian/changelog
--- libt3window-0.4.0/debian/changelog  2019-12-01 00:53:56.0 +0800
+++ libt3window-0.4.0/debian/changelog  2024-04-22 16:01:09.0 +0800
@@ -1,3 +1,11 @@
+libt3window (0.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add 00-fix-implicit-function-declaration.patch to fix impfuncdef
+issue. (Closes: #1066491)
+
+ -- Bo YU   Mon, 22 Apr 2024 16:01:09 +0800
+
 libt3window (0.4.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
libt3window-0.4.0/debian/patches/00-fix-implicit-function-declaration.patch 
libt3window-0.4.0/debian/patches/00-fix-implicit-function-declaration.patch
--- libt3window-0.4.0/debian/patches/00-fix-implicit-function-declaration.patch 
1970-01-01 07:30:00.0 +0730
+++ libt3window-0.4.0/debian/patches/00-fix-implicit-function-declaration.patch 
2024-04-22 15:33:59.0 +0800
@@ -0,0 +1,18 @@
+Description: fix implicit-function-declaration issue
+ No upstream issue report online, will forward this to the author of upstream.
+ New upstream release 0.4.1 has not fixed the issue yet.
+Author: Bo YU 
+Bug: https://bugs.debian.org/1066491
+Last-Update: 2024-04-22
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/config.pkg
 b/config.pkg
+@@ -121,6 +121,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ int main(int argc, char *argv[]) {
+   int args[9], error, fd;
diff -Nru libt3window-0.4.0/debian/patches/series 
libt3window-0.4.0/debian/patches/series
--- libt3window-0.4.0/debian/patches/series 1970-01-01 07:30:00.0 
+0730
+++ libt3window-0.4.0/debian/patches/series 2024-04-21 09:27:28.0 
+0800
@@ -0,0 +1 @@
+00-fix-implicit-function-declaration.patch


signature.asc
Description: PGP signature


Bug#1069661: samba: apparmor integration broken since change to local systemd units in 2:4.19.4+dfsg-1

2024-04-22 Thread Michael Tokarev

Control: tag -1 + pending

22.04.2024 12:18, Alex Murray wrote:

Package: samba
Version: 2:4.19.5+dfsg-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

*** /tmp/tmpz7e0qwfp/bug_body

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

When samba was updated to ship local systemd service unit files in 
2:4.19.4+dfsg-1
the ExecStartPre directive was not included. As such the integration with 
apparmor
via the update-apparmor-samba-profile script was lost. The previously used patch
can be dropped as the file that is patched is now not used and instead the 
locally
maintained systemd unit is updated to include this directive instead.


Indeed, I broke this when moving to local services.
Thank you for the patch.  It will be part of the next upload,
I just pushed it to git.

/mjt



Bug#1069643: dh_installman: doesn't honor nodoc build profile

2024-04-22 Thread Niels Thykier

Fab Stz:

[...]


If dh_installman doesn't support nodoc as written in its manpage, then maybe
the manpage should be changed.

For instance this may have to be removed since I was mistaken by it.

"In compat 11 and later, it also supports the default searchdir plus --
sourcedir like dh_install(1) and has the advantage that it respects the nodoc
build profile (unlike dh_install(1))."

Regards
Fab




I am happy to consider patches for improving the documentation. But, I 
think your confusion is at a much more fundamental level. As I 
understand your email, you seem to be confusing `dh_installman` reacting 
to `nodoc` vs. `dh` skipping a hook target with `nodoc` which are two 
very different aspects.


The statement about `dh_installman` respecting `nodoc` above is still 
correct because it is whether `dh_installman` will react to `nodoc` and 
ignore missing documentation (manpages) in the `debian/.manpages` 
files.


Nothing you showed me in the mount-zip package is about whether 
`dh_installman` reacts to `nodoc`. That was 100% whether `dh` reacts to 
`nodoc` by skipping commands and hook targets. So if any docs should be 
changed, I would expect the change to be in `dh(1)` rather than 
`dh_installman(1)`.


Best regards,
Niels



Bug#1069661: samba: apparmor integration broken since change to local systemd units in 2:4.19.4+dfsg-1

2024-04-22 Thread Alex Murray
Package: samba
Version: 2:4.19.5+dfsg-4
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

*** /tmp/tmpz7e0qwfp/bug_body

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

When samba was updated to ship local systemd service unit files in 
2:4.19.4+dfsg-1
the ExecStartPre directive was not included. As such the integration with 
apparmor
via the update-apparmor-samba-profile script was lost. The previously used patch
can be dropped as the file that is patched is now not used and instead the 
locally
maintained systemd unit is updated to include this directive instead.

debian/changelog from Ubuntu as is follows:

  * Fix apparmor integration with smbd.service (LP: #2063079)
- d/patches: remove unnecessary
  smbd.service-Run-update-apparmor-samba-profile-befor.patch patch
  since we don't use the packaging/systemd/smd.service.in template
- d/samba.smbd.service: update to invoke update-apparmor-samba-profile
  help via ExecStartPre directly


Thanks for considering the patch.


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

Kernel: Linux 6.8.0-28-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru samba-4.19.5+dfsg/debian/patches/series 
samba-4.19.5+dfsg/debian/patches/series
--- samba-4.19.5+dfsg/debian/patches/series 2024-03-05 04:34:57.0 
+1030
+++ samba-4.19.5+dfsg/debian/patches/series 2024-04-22 16:08:04.0 
+0930
@@ -5,7 +5,6 @@
 usershare.patch
 heimdal-rfc3454.txt
 add-so-version-to-private-libraries
-smbd.service-Run-update-apparmor-samba-profile-befor.patch
 fix-nfs-service-name-to-nfs-kernel-server.patch
 ctdb-config-enable-syslog-by-default.patch
 Force-LDB-as-standalone.patch
diff -Nru 
samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch
 
samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch
--- 
samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch
 2023-09-12 02:58:56.0 +0930
+++ 
samba-4.19.5+dfsg/debian/patches/smbd.service-Run-update-apparmor-samba-profile-befor.patch
 1970-01-01 09:30:00.0 +0930
@@ -1,25 +0,0 @@
-From 0ecd28ff3fd7f3d5c20705a2b8233fc8648cbf9c Mon Sep 17 00:00:00 2001
-From: Mathieu Parent 
-Date: Thu, 21 Feb 2019 21:04:30 +0100
-Subject: [PATCH] smbd.service: Run update-apparmor-samba-profile before start
-
-Bug-Debian: https://bugs.debian.org/896080

- packaging/systemd/smb.service.in | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/packaging/systemd/smb.service.in 
b/packaging/systemd/smb.service.in
-index 18912ef0e98..6bb24861682 100644
 a/packaging/systemd/smb.service.in
-+++ b/packaging/systemd/smb.service.in
-@@ -10,6 +10,7 @@ NotifyAccess=all
- PIDFile=@PIDDIR@/smbd.pid
- LimitNOFILE=16384
- EnvironmentFile=-@SYSCONFDIR@/sysconfig/samba
-+ExecStartPre=/usr/share/samba/update-apparmor-samba-profile
- ExecStart=@SBINDIR@/smbd --foreground --no-process-group $SMBDOPTIONS
- ExecReload=/bin/kill -HUP $MAINPID
- LimitCORE=infinity
--- 
-2.20.1
-
diff -Nru samba-4.19.5+dfsg/debian/samba.smbd.service 
samba-4.19.5+dfsg/debian/samba.smbd.service
--- samba-4.19.5+dfsg/debian/samba.smbd.service 2024-01-31 03:07:18.0 
+1030
+++ samba-4.19.5+dfsg/debian/samba.smbd.service 2024-04-22 16:08:18.0 
+0930
@@ -9,6 +9,7 @@
 PIDFile=/run/samba/smbd.pid
 LimitNOFILE=16384
 EnvironmentFile=-/etc/default/samba
+ExecStartPre=/usr/share/samba/update-apparmor-samba-profile
 ExecStart=/usr/sbin/smbd --foreground --no-process-group $SMBDOPTIONS
 ExecReload=/bin/kill -HUP $MAINPID
 LimitCORE=infinity


Bug#1068234: efibootguard upstream

2024-04-22 Thread Gylstorff Quirin



This is a upstream bug.

Thanks for reporting

Quirin

forwarded 1068234 efibootguard-...@googlegroups.com

--
Quirin Gylstorff

Siemens AG
Technology



Bug#1069593: libsequoia-octopus-librnp: dpkg-divert in preinst doesn't happen on upgrade

2024-04-22 Thread Holger Levsen
hi dkg,

thanks for these bugreports! I've commited fixes and am doing test
builds now and will upload shortly.

On Sun, Apr 21, 2024 at 04:29:10AM -0400, Daniel Kahn Gillmor wrote:
> Why does the package exclude the diversion when preinst runs on upgrade?

I guess because I used a bad example...
 
> i see the same issue in the use of dpkg-divert in gpg-from-sq and
> gpgv-from-sq also, btw.  Compare that to the use of dpkg-divert in
> /var/lib/dpkg/info/perl-doc.preinst, for example, which triggers on both
> "install" and on "upgrade".

thanks. will upload a new version of chameleon once we confirmed
with this package that the fix works.

> I worked around this on my system by removing libsequoia-octopus-librnp,
> upgrading thunderbird, and then reinstalling libsequoia-octopus-librnp,
> but it seems like the goal should be to not have to make the user do
> that.
 
yes, absolutly.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"I became an antifascist out of a sense of common decency.” – Marlene Dietrich


signature.asc
Description: PGP signature


Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2

2024-04-22 Thread Diederik de Haas
Control: tag -1 -moreinfo +upstream
Control: forwarded -1 
https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWTTGfKJSRxY=ht...@mail.gmail.com/

On Monday, 22 April 2024 10:32:00 CEST Jeremy Lainé wrote:
> Over the weekend I reported the issue to the linux-bluetooth mailing
> list, which led to bisecting the issue down to a single commit:
> 
> https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWT
> TGfKJSRxY=ht...@mail.gmail.com/

Nice work :)

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


Bug#1069372: efibootguard: FTBFS on arm64: kernel-stub/fdt.c:169:49: error: passing argument 2 of ‘CopyMem’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]

2024-04-22 Thread Gylstorff Quirin

This is a upstream bug.
Thanks for reporting,
Quirin

forwarded 1069372 efibootguard-...@googlegroups.com

On 4/20/24 2:01 PM, Lucas Nussbaum wrote:

Source: efibootguard
Version: 0.16-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64

Hi,

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


Relevant part (hopefully):

make[2]: Entering directory '/<>'
make --no-print-directory all-recursive
Making all in .
set -e; echo '  CHK  version.h'; mkdir -p ./;   ./gen_version_h ./ < Makefile.in 
> version.h.tmp; if [ -r version.h ] && cmp -s version.h version.h.tmp; then rm -f 
version.h.tmp; else echo '  UPD  version.h'; mv -f version.h.tmp version.h; fi
   CHK  version.h
/usr/bin/mkdir -p completion/bash; PYTHONPATH=./completion/shtab:./completion 
/usr/bin/python3 -m shtab -u --shell=bash bg_setenv.cli.bg_setenv 
>completion/bash/bg_setenv.bash
   UPD  version.h
/usr/bin/mkdir -p completion/bash; PYTHONPATH=./completion/shtab:./completion 
/usr/bin/python3 -m shtab -u --shell=bash bg_printenv.cli.bg_printenv 
>completion/bash/bg_printenv.bash
/usr/bin/mkdir -p drivers/watchdog/; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -fno-stack-protector  -c drivers/watchdog/init_array_start.S 
-o drivers/watchdog/init_array_start.o
/usr/bin/mkdir -p drivers/watchdog/; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -fno-stack-protector  -c drivers/watchdog/init_array_end.S -o 
drivers/watchdog/init_array_end.o
/usr/bin/mkdir -p env/; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -fno-stack-protector  -c env/syspart.c -o env/syspart.o
/usr/bin/mkdir -p env/; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -fno-stack-protector  -c env/fatvars.c -o env/fatvars.o
/usr/bin/mkdir -p ./; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -fno-stack-protector  -c utils.c -o utils.o
/usr/bin/mkdir -p ./; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -fno-stack-protector  -c loader_interface.c -o 
loader_interface.o
/usr/bin/mkdir -p ./; gcc -I. -include config.h -I./include -I/usr/include 
-I/usr/include/efi -I/usr/include/efi/aarch64 -I/usr/include/aarch64-linux-gnu  -Wall 
-Wextra -std=gnu99 -ggdb -O0 -fpic -fshort-wchar -ffreestanding -fno-strict-aliasing 
-Wsign-compare -DGNU_EFI_USE_MS_ABI -Werror -mgeneral-regs-only -g -O2 
-Werror=implicit-function-declaration 

Bug#1069657: libgeo-gpx-perl: Waypoint name encoding utf-8 does not work

2024-04-22 Thread Sebastiaan Couwenberg

Control: tags -1 upstream
Control: forwarded -1 https://github.com/patjoly/geo-gpx/issues/6

I've forwarded this issue upstream. Please followup there.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#1069643: dh_installman: doesn't honor nodoc build profile

2024-04-22 Thread Fab Stz
> I do not see anything in that commit that suggests that `dh_installman`
> does not honor `nodoc`. What I am getting is that you wish that `dh`
> would skip hook targets for any program that might react to `nodoc`
> similar to `nostrip`.
> 
> Assuming we agree on this being the ask, my answer that there is a
> difference here in that `dh_installman` (etc.) operates during a `nodoc`
> build. That is, I cannot omit the calls to `dh_installman` or
> `dh_installdoc` as they still have things to do (such as re-encode any
> manpage installed to UTF-8 or install the copyright file into the
> package). Therefore, I do not plan to extend the `dh` feature to `nodoc`
> as it cannot tell whether said hook target might still be useful under
> `nodoc` or not.
> 
> As an example based off mount-zip, it would not be unreasonable for you
> to unconditionally remove the manpage rather than installing the
> pre-built one in `execute_before_dh_installman` and then conditionally
> regenerate it as an alternative to conditionally removing it and
> conditionally regenerating it. We do not have a common baseline for this
> and therefore `dh` cannot "optimize" for either way.
> 
> Best regards,
> Niels
> 
> PS: Note that the semantics of `nodoc` are very poorly defined compared
> to `nostrip` or `nocheck`, which does not help either. Unlike the
> others, `nodoc` is just "skip problematic documentation" rather than
> "skip all documentation" (case in point being we still one copyright
> files, NEWS files, and changelogs)

If dh_installman doesn't support nodoc as written in its manpage, then maybe 
the manpage should be changed.

For instance this may have to be removed since I was mistaken by it.

"In compat 11 and later, it also supports the default searchdir plus --
sourcedir like dh_install(1) and has the advantage that it respects the nodoc
   build profile (unlike dh_install(1))."

Regards
Fab



Bug#1069660: directvnc: Allow password file to be supplied vs just commandline

2024-04-22 Thread Tim Connors
Package: directvnc
Version: 0.7.8-1
Severity: normal

man 1 directvnc:

   -p, --password
password string to be passed to the server for authentication. Use 
this with care!

OK, so what's care?  Well, the password is available for all system
users and crackers to view with just `ps faux | grep directvnc`.  But
what if there was a way to supply the password through a file, like on
all other vnc servers?  Looking at the documentation, I can't see any
such way to provide the password through a file.



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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 directvnc depends on:
ii  libc6 2.36-9+deb12u4
ii  libdirectfb-1.7-7 1.7.7-11
pn  libdirectfb-1.7-7t64  
ii  libjpeg62-turbo   1:2.1.5-2
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages directvnc recommends:
ii  x11proto-core-dev 2022.1-1
ii  x11proto-dev [x11proto-core-dev]  2022.1-1

directvnc suggests no packages.



Bug#1069659: ITP: rust-lifeguard -- An object pool manager in Rust

2024-04-22 Thread Loren M. Lang
Package: wnpp
Severity: wishlist
Owner: "Loren M. Lang" 
X-Debbugs-Cc: debian-de...@lists.debian.org, lor...@north-winds.org

* Package name: rust-lifeguard
  Version : 0.6.1
  Upstream Contact: Zack Slayton 
* URL : https://crates.io/crates/lifeguard
* License : MIT
  Programming Lang: Rust
  Description : An object pool manager in Rust

Allows values to be stored in a pool and retrieved when needed to access
or mutate their contents. Values can be unwrapped and detached from the
pool when needed and later returned to the pool or new values added in
efficiently.

This is needed for rust-adblock

-- 
Loren M. Lang
lor...@north-winds.org
http://www.north-winds.org/


Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED  E103 222D F356 A57A 98FA


signature.asc
Description: PGP signature


Bug#1069658: python3-lib389: dsconf security subcommand does not work due to misnamed function parameters

2024-04-22 Thread Jörg Behrmann
Package: python3-lib389
Version: 2.3.1+dfsg1-1
Severity: important
Tags: patch

Dear maintaner,

when following the 389ds documentation [1] to enable TLS for 389ds I noticed 
that the step

dsconf  security rsa set \
--tls-allow-rsa-certificates on \
--nss-token "internal (software)" \
--nss-cert-name Server-Cert

failed with "Error: name 'log' is not defined".

This is the same bug as [2]. Applying the upstream patch [3] fixes the problem.

[1] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#proc_enabling-tls-encrypted-connections-to-directory-server-using-the-command-line_assembly_enabling-tls-encrypted-connections-to-directory-server
[2] https://pagure.io/freeipa/issue/9283
[3] 
https://github.com/389ds/389-ds-base/commit/12c14ed15dba332378613ac3ad0bb046811c4d75

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/6 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)

Versions of packages python3-lib389 depends on:
pn  libnss3-tools 
ii  openssl   3.0.11-1~deb12u2
ii  python3   3.11.2-1+b1
ii  python3-argcomplete   2.0.0-1
pn  python3-argparse-manpage  
ii  python3-dateutil  2.8.2-2
ii  python3-distro1.8.0-1
pn  python3-ldap  
ii  python3-packaging 23.0-1
ii  python3-pkg-resources 66.1.1-1
pn  python3-pyasn1
pn  python3-pyasn1-modules
ii  python3-pytest7.2.1-2

python3-lib389 recommends no packages.

python3-lib389 suggests no packages.



Bug#1069657: libgeo-gpx-perl: Waypoint name encoding utf-8 does not work

2024-04-22 Thread Florian Lohoff
Package: libgeo-gpx-perl
Version: 1.10-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Hi,
i was trying to create gpx waypoints with an utf-8 name which does not
work:

perl -Mutf8 -MGeo::Gpx -e '$g=Geo::Gpx->new(); $g->waypoints_add({ lat => 0, 
lon => 0, name => "üöä" }); $g->save(filename => "foo.gpx");'

$ cat foo.gpx

http://www.w3.org/2001/XMLSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; version="1.0" 
creator="Geo::Gpx" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 
http://www.topografix.com/GPX/1/0/gpx.xsd; 
xmlns="http://www.topografix.com/GPX/1/0;>







The code seems to unconditionally use HTML::Entities->encode_entities


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.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 libgeo-gpx-perl depends on:
ii  libdatetime-format-iso8601-perl0.16-2
ii  libdatetime-perl   2:1.59-1
ii  libgeo-coordinates-transform-perl  0.10-3
ii  libhtml-parser-perl3.81-1
ii  libxml-descent-perl1.04-6
ii  perl   5.36.0-7+deb12u1

libgeo-gpx-perl recommends no packages.

Versions of packages libgeo-gpx-perl suggests:
ii  xclip  0.13-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdb9o7oebX2papQ/KkN1BIMsJ8i8FAmYmI5wACgkQkN1BIMsJ
8i+B1Q//boYR0RVAAHpTrNEpZG0UZoMAewqZexOybRaXg48H9tlmdZr1ucbFqM2P
KYZI2X20gM3Qi9FyrDn55kpJo/DYqLd8no57boQMzoV3+Y29CwuAqtXi6vf4GNmf
VnEzEGVnRTDKuzEqgWHrtSw99I5AioYqjmtwTmDHuzJ8S67CL1Ful6dsSNBDwiCg
+CNTf9MDCoPne8yAsnzFUui9XT6S21VHoj+PDVKBaeXqcuSK09AKjvKDXHpHeeiC
9L4/ngqIPtFMjLXbUz7CZsVo1IMXSyHH9fvhWU1j6uVRIyAa0q/4uqmkpM73Y3dn
sVtCXbolBiSlwtZe3WHUMQTve69JJIcQleXX9EvfD/37uXFy8wJ8Hx5X2whk8NQu
zMbAGmV7sAvzoMpo+O/IfaUD3b7HG/nycvmyWjgeITk4eKsMTB1MWLdMBGTaXqli
jo4NcU1a0KlITN8JYSqHVi+GYA94GtXHZcnkSu7DGaUw9QGl1l6DD1692w/uavXR
LiDUsqzXG4a4GcPb7x7PQrCE9u/tKcHGEeb/be4uLieGIu792P2Z9r0Od97EORoh
KKONjGyOYSuHYH7/KQLS36hF1E1Tv9EL/WBkzhvvbUojyror5NuP3PYRK87lFXUh
WaW+f/dtq882jGfADGBZn8Hp1aVDjZuQ14DGBQUHG/XYIu2jHNk=
=qc55
-END PGP SIGNATURE-


Bug#1069600: dm-writeboost: isolation-machine autopkgtest fails: sudo: not found

2024-04-22 Thread Andreas Beckmann

On 21/04/2024 13.16, Paul Gevers wrote:
Your package has an autopkgtest, great. I recently added support for 
isolation-machine tests on ci.debian.net for amd64 and added your 
package to the list to use that. However, it fails. Can you please 


Nice. Is there a chance to get isolation-machine supported on salsa.d.o, 
too? That would allow for testing this before uploading ... (and I don't 
have time to create a isolation-machine supporting setup locally ...).


For this concrete case it may be as simple as adding dependency on sudo. 
In case it is trivial for you to rerun the failing test with extra 
dependencies, could you try that? I'd like to avoid doing debugging NMUs 
with untested bugfixes ;-)


Andreas



Bug#1069656: rust-clap-complete: please update to v4.5.1

2024-04-22 Thread Jonas Smedegaard
Source: rust-clap-complete
Version: 4.4.9-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v4.5.1.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmILQACgkQLHwxRsGg
ASGj0g/9GALUL0/huqpv/P7YJ44W+zZDCWOpANp5io4887AUzWTnta0b+AEqPlo4
HbP3sNDoQcAEUWZVb/OUnXzFC7JnR6Z6AfmZzqEjPmPC5v80h4PHenK0h0aOdat9
ORLDtm2fKUgWz7MIrOusS1JVBM5KiBGGvO50LecIOzOP1ckkrjC2/skoPgb3HUiv
DeDDXqZ7fzqWqNxLuTvk7zRw07sCW7pNZg5ShihImguq/tcg+kWBTrrihqGItyAS
sZ4lrXmBUEL5nd6CIgCrSJmDWMRoWN/eDv+RCV5VQhUMQAQd+nIbiTypc5pz3NJv
1Cut5TW6F9a5pXOOP4+k4AfQESzUtKf5EIEdEUjM+aAqJv/225DmtowOJDSixCsb
swZK8h6XVZo/gn9ZiggcpfntuB247ZKgEvd53YN+TLdkXsRbl9adpfl/PGs2FAr3
vWpLHd/LmkGw75S46irkn92SoSvo8KumoG7CS+kWOwDPiWLaXSkGsIdpi1wDHd+0
mcljV2OCTo+xEAkce78R5q1odeL/AXxmsJ9MD32CXIM13mZmlOo5las1m5QnFnjZ
L9wHqRlDQTo26y8UW5z2DPTO15bvy/BJlyeM/awZn7Xg+jKoWU/+LL5s+6d1HhZI
Be2M8pEqCgn7IQjkri0l21qmbtnHMZSg1fInqg3Zz4e1m9aru78=
=UYkQ
-END PGP SIGNATURE-



Bug#1069643: dh_installman: doesn't honor nodoc build profile

2024-04-22 Thread Niels Thykier

Control: tags -1 moreinfo

On Mon, 22 Apr 2024 09:37:55 +0200 Fab Stz  wrote:

Package: debhelper
Version: 13.15.3
Severity: normal

Dear Maintainer,

According to dh_installman, it should honor the nodoc build profile.
However, it doesn't. As well as execute_before_dh_install.


[...]


Hi,

Could you please provide the URL the packaging in question where it does 
not work along with a bit more details of what you expected vs. what you 
see? Notably, `dh_installman` will allow documentation to be missing 
during `nodoc` but it will still operate on the documentation there is 
(that has been the way of handling `nodoc` from the start in `debhelper`).


Additionally, I am not sure what the `execute_before_dh_install` remark 
is about. The `execute_before_dh_install` hook targeted is not affected 
by `nodoc`. First off because it is `dh_install` and not one of the 
`dh_install{docs,man}` and secondly, most of the documentation commands 
still do something even under `nodoc` (unlike `dh_strip` with 
`nostrip`), so the commands are still run. Thirdly, even if it was to be 
affected, it would react to `DEB_BUILD_OPTIONS` and not the profile 
(which are not the same thing and that has been confusing people a lot 
at least with nocheck)


Best regards,
Niels



Bug#1069643: dh_installman: doesn't honor nodoc build profile

2024-04-22 Thread Fab Stz
Control: tags -1 - moreinfo

Le lundi 22 avril 2024 10:12:45 CEST, vous avez écrit :
> Control: tags -1 moreinfo
> 
> On Mon, 22 Apr 2024 09:37:55 +0200 Fab Stz  wrote:
> > Package: debhelper
> > Version: 13.15.3
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > According to dh_installman, it should honor the nodoc build profile.
> > However, it doesn't. As well as execute_before_dh_install.
> > 
> > 
> > [...]
> 
> Hi,
> 
> Could you please provide the URL the packaging in question where it does
> not work along with a bit more details of what you expected vs. what you
> see? Notably, `dh_installman` will allow documentation to be missing
> during `nodoc` but it will still operate on the documentation there is
> (that has been the way of handling `nodoc` from the start in `debhelper`).
> 
> Additionally, I am not sure what the `execute_before_dh_install` remark
> is about. The `execute_before_dh_install` hook targeted is not affected
> by `nodoc`. First off because it is `dh_install` and not one of the
> `dh_install{docs,man}` and secondly, most of the documentation commands
> still do something even under `nodoc` (unlike `dh_strip` with
> `nostrip`), so the commands are still run. Thirdly, even if it was to be
> affected, it would react to `DEB_BUILD_OPTIONS` and not the profile
> (which are not the same thing and that has been confusing people a lot
> at least with nocheck)
> 
> Best regards,
> Niels

Hello Niels,

Oh sorry, I lost my initial mail and had to rewrite it and wasn't careful 
enough. I meant execute_before_dh_installman and not 
execute_before_dh_install.

Concerning your remark about DEB_BUILD_OPTIONS, it is populated automatically 
with the value of the DEB_BUILD_PROFILES as displayed in the output of dpkg-
buildpackage. At least for nocheck & nodoc.

You can try with https://salsa.debian.org/bastif/mount-zip
Latest commit includes execute_before_dh_installman

For now, as a workaround in that target, I added a test on whether build 
profile has "nodoc" set. But if you remove that "ifneq...", and build with 
"nodoc" it will still invoke both dh_installmal & 
execute_before_dh_installman. However, if one doesn't have pandoc installed 
(eg because the "nodoc" build profile doesn't require it as dependency), that 
target will fail because it is invoked, while I expected it to be skipped.

If you wish to check with that package, I suggest you also build with 
"nocheck", because there is a test that takes a lot of time.

Regards
Fab



Bug#1069301: Bug reported upstream

2024-04-22 Thread Jeremy Lainé
Over the weekend I reported the issue to the linux-bluetooth mailing
list, which led to bisecting the issue down to a single commit:

https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWTTGfKJSRxY=ht...@mail.gmail.com/

Jeremy



Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20

2024-04-22 Thread Damian
Same problem here, but with a different call trace. The RIP logline had 
one of `security_file_permission` and `security_netlink_send`, I don't 
remember which one.




Bug#1037903: xrt: ftbfs with GCC-13

2024-04-22 Thread Gianfranco Costamagna

On Sat, 16 Sep 2023 20:13:12 +0200 Jonathan Bergh  
wrote:

Control: tags -1 + patch

Fixes 1037903 due to upgrade to gcc-13


Hello, I had to add another one for arm64 build failure

--- 
xrt-202210.2.13.466+dfsg.orig/src/runtime_src/core/edge/user/aie/common_layer/adf_api_config.h
+++ 
xrt-202210.2.13.466+dfsg/src/runtime_src/core/edge/user/aie/common_layer/adf_api_config.h
@@ -16,6 +16,7 @@

 #pragma once

+#include 
 #include 
 #include 
Index: xrt-202210.2.13.466+dfsg/src/runtime_src/core/edge/user/zynq_dev.h
===
--- xrt-202210.2.13.466+dfsg.orig/src/runtime_src/core/edge/user/zynq_dev.h
+++ xrt-202210.2.13.466+dfsg/src/runtime_src/core/edge/user/zynq_dev.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 class zynq_device {

 public:


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1069655: libkf6userfeedback-data: missing Breaks+Replaces: libkuserfeedbackcoreqt6-1 (<< 6)

2024-04-22 Thread Andreas Beckmann
Package: libkf6userfeedback-data
Version: 6.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libkf6userfeedback-data_6.0.0-1_all.deb ...
  Unpacking libkf6userfeedback-data (6.0.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libkf6userfeedback-data_6.0.0-1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/qlogging-categories6/org_kde_UserFeedback.categories', which is 
also in package libkuserfeedbackcoreqt6-1:amd64 1.3.0-3+b2
  Errors were encountered while processing:
   /var/cache/apt/archives/libkf6userfeedback-data_6.0.0-1_all.deb


cheers,

Andreas


libkuserfeedbackcoreqt6-1=1.3.0-3+b2_libkf6userfeedback-data=6.0.0-1.log.gz
Description: application/gzip


Bug#1069654: RM: salt -- RoQA; no maintainers left

2024-04-22 Thread Bastian Blank
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: s...@packages.debian.org, bdr...@debian.org, on...@debian.org, 
wa...@debian.org
Control: affects -1 + src:salt
User: ftp.debian@packages.debian.org
Usertags: remove

Please remove package salt.  It was not released in stable.  No response
shows up to requests by the security team on how to handle the package
in stable.  The maintainer mailing list shows only spam.  It is RC buggy
since years and does not even build any longer.

Bastian



Bug#884713: approx: systemd's approx.socket should be configured to not have any trigger limit

2024-04-22 Thread Arnaud Rebillout
On Mon, 18 Dec 2017 16:40:40 +0100 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
 wrote:
> But IMO the default configuration should work even when you make 
heavy use
> of the package repositories... so I would like to see this in your 
default

> approx.socket. Or at least you should raise the limit to something larger
> like a few thousands requests.

To add some more context: initially systemd defaulted to « 2500 
activations per 5s », but then in v255 (commit from May 5, 2016), it 
changed to more conservative defaults of « 200 activations per 2s » when 
Accept=yes. Cf. 
https://github.com/systemd/systemd/commit/1f15ce28461ec54f85908efc063f99dc5a65b4ca.


--
Arnaud Rebillout / OffSec / Kali Linux Developer


Bug#1069653: rust-toml: please update to v0.8.12

2024-04-22 Thread Jonas Smedegaard
Source: rust-toml
Version: 0.8.8-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.8.12.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGgYACgkQLHwxRsGg
ASFl7xAAjF/YyAht/G3qlnV4Jqgtu8SRn76GQWXFRJfYxwf+8K26arDmrfcp1egD
lRaXfLobOxfB7Kyf8tveLekdMtnjHBCql0mYzPMnF7joLTGNFrriTFS7PhGsPddX
Z4HIW/qS5PW26vsscr0evuN/KgNacwyWosenVE5RzhHE7mY/M8d5T514M+4OEaBv
cB6FcflsRsXNwjVcqiJ56bU+PmyMa+KDtzIxogo1re2Wn+E7l/oM8p+FipxpjKIj
M3hGu2zSHXnfYGdrNWqTrw8J6tWjeRNRGvITN1M/pzlWwbb+VncTNefVYkulNemS
NxOvRhWzq25kdkn6OdpdZXr5E/RPLzAFFZs8wXZ5kaKVOCkxAh4UXNQhI4v1eC1V
ETliSxj0iI+f/S1ENJQ2YhtDd/eJmKpYJN8agQxwD/h2aGJ3S9wL+cqiPr8oIP5+
eNH5wjZHTyzZzhGdh01IJsze7YV+ZHapf1fGDRucgYVIFB0sCZYUCt4350HXK2i4
x4aTyg5vv4LQqxseuUL85/OQf/61OtjgTwruP25KKGWlYJz8Vc1fsyWxLKbFtjv/
00OihvpP1TIKXsMVMVucXi7kHElsj6Dm0cDJlCXvDlr7sqowSyq3/601UP8OZAJD
xczHFkuSp3EDY7Egh7bi+L+DzibeMqyDUrWhFGSqAf3kjxqyJRI=
=YG5X
-END PGP SIGNATURE-



Bug#1069652: rust-tokio: please update to v1.37.0

2024-04-22 Thread Jonas Smedegaard
Source: rust-tokio
Version: 1.35.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.37.0.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGdEACgkQLHwxRsGg
ASFyzA//Z8kE1i1zUS4YB8wzNEelzblpLTGGh8dVg6Og8yI8MS1qIYVNKAvBod9w
KWG2XXMTQsVcV6c8elJmy2INgF2TnkPPqQtDSF8Jm2FIbpFYLFDtUOWcsUCqPbf+
LHwjC9EF8xUrhjasEvab2oAKwO7U/39xUE40MlizPxTbZbd5XkgtiuH/gSuiTOla
pPKtMeKeIdqg4eaIvWqa1r6nitXG838xDYHfgUjPDW3Wq+GnS4/OSgry6/iGvYEV
E7aXePcJ2tg4cp0khXJ5ZquaWKq1asP8NpEHFxgo0YdSG9AtBgYQjdRtnDCuT1ac
ekSTSBapKRyaM2FHpX+M4l1O5uEpRDq5WwfSza19g80zr3ZarZlF6WxAu3gkI8A6
E1BZYBCJJ2KUpBgSrf+XY7JbRu3IOiJ7AM5HhXe6CeD97eRmYASGUqffeCZCaRbs
zite1Z5VGCIFkOltiiwMC49CsHxqqJuygvdz4agHapT4hhMQKZ8oAn9tT3uaGEdJ
UX6BbEHkkuLH/YoL36K6vQ9mBZN+buHf9Q7kYbcv/dNWJR2zSNnUrv200+NvMl9u
++UHa/RfT3CjX4/Q3gc4LantO2MqRlTgmRNk5tbMx3lkJ12Qp5fpdtX0deiwk3rJ
SzywD0LsN6jdsTMQGmxAbU2Gty25cCTR6MC8tbahj8fCaKxtxJA=
=oqu5
-END PGP SIGNATURE-



Bug#1064293: less: CVE-2022-48624

2024-04-22 Thread Salvatore Bonaccorso
Hi,

On Sat, Apr 20, 2024 at 07:54:13AM -0400, P. J. McDermott wrote:
> On 2024-04-19 at 15:55, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > FWIW, I'm actually preparing a security update for the two CVEs and
> > for bookworm I was first planning to do a 590-2.1 reaching unstable,
> > and so then 590-2.1~deb12u1 for bookworm.
> > 
> > But if you want to override it with a NMU and proposing to salvage the
> > package this is equally fine.
> 
> Your DELAYED/2 NMU is probably the fastest and best way to get these
> CVEs fixed in unstable and bookworm, so that's fine, thanks.  Any plans
> for 551-2 in bullseye?  The two patches in your NMU apply cleanly there.

Yes, both bookworm-security and bullseye-security updates are already
prepared and uploaded to security-master. I will wait for some
exposure of less in unstable with the two fixes before releasing the
DSA.

I have not pushed the changes yet to the repository (will be done
after the DSA release).

I cannot comment on the salvaging of the package directly, as Milan has
responded to the bug and even acked the NMU. So I assume he is active
and you need to discuss with him on co-maintainership for less. But as
I read the discussion is already happening. So stopping here to
comment.

Regards,
Salvatore



Bug#1069651: rust-regex: please update to v1.10.4

2024-04-22 Thread Jonas Smedegaard
Source: rust-regex
Version: 1.10.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.10.4.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGXUACgkQLHwxRsGg
ASFi8BAAgsopsPdXA7gvaEs0pOFhBvk4H4pBeKYSaV6qIEUcUrQYfwW0cTAveAnX
x+/Skk4sXgYe9OY6gw5hB3jJW17jaoOrTodzyOvgpVwYzE8zdqVcbHN4PhwwkCGS
W8KTC+2uTcYn851TjABwJj11lQop2qjvgqsSuzQLPL0+9BotNK0Z7P1HR+oSx9o+
+OcBkzPKrAbV52egVrjvj2dgPIjpjG5ZRmHPBNtMiQAKYYp3beEKAS5uPgnWI6ov
sZ/zrtyJkAIrJoOfsVgZTbOH3QxY5V4lvg1dZYWZSZdDRZJIMQP+9Yd8WvI2EukR
PzZ1S/qCXnqDIeDha6T8WGyxMB5JTT8D2I/IoCkQF24Em4NTAze0OEmZs8dw4ddf
2pYPIT8s6O4/PqHzE4CpH1ryypfeUhQ9LNufU4MK1ayfWCXwaZOiQGAmT66Y6BP2
lckLjpT+wDgSVlZkI+X2Jh0yiF/ttFIiUteZPgXoWn41SsWCasdEAF2j2W32NsmZ
TohZFZtYePI4pULWRVDdza9J5Y+9tpeQMkkWKD1zwD2/bDdFCZ9kAO4rDEt086zC
WkUBDV0toxBlqGZHQrX28OVKSwgkMl311eoW5pynNizOuC1Hv8/0iRLtSGG1EMtI
0I5dNg0Ctb2BwckVpQ6xGA5hxzz4mqzsXA6yC7MVGTIT0smE0SM=
=LyGF
-END PGP SIGNATURE-



Bug#1069650: rust-rayon: please update to v1.10.0

2024-04-22 Thread Jonas Smedegaard
Source: rust-rayon
Version: 1.8.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.10.0.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGT4ACgkQLHwxRsGg
ASFs5xAAnc9pWcfZPqEUdBXJJfSBCc74I0oAOFYT5vgUemuaXCE3MZVrB7VkRkva
GVx5eFy+znos0Cpc3cbvg0FkeO3Kilfx568feYf3vv/2uNf4y0h5IGNqEr6RiRPC
SZFImd9jgsm7DwZCt0b/HxyUq1Uz5c90yCtJ3+cUmBYqYvS3GHEBO3asq9BCZRTj
8bHwpw+sMZCDFjPFiLKs/NdNsQj0fqtLWb3njuyHI6jiMSpExmCef4JEgnWN3ydd
UBpHRWlQrO+u/s/G9obFWsJUELKlA/SL2JV1k2g+cUtP2d28D9bRvbuS9N6WgLoe
e7n5rfddTuVdguWPsrZNVC4/W9xlFOTwbvj9rz/rY61E3YZpz5QmM+MdyNqBZy6t
eJP51Kv39ze/0KYd9lNC3eMrJNv0b/YjrGpFmsCW3LpJbFE2PIfwQ2lDhxCxb296
46T7ZBbubZSxP6G1K03TL/tjXLPtoeq30+ZFwQnIGSKEmt/BxM1teWDA+wJyfbJp
37ieM7DgJxlGshanrqqybNwQNIYeUytG4EHaSeegdyvL2FiF+VlxUwpAmWFMGgyY
No0IWL+8LxzHWVrxDcxwHofTUnogZefa2pJUSkKcOObb/5ZRF26M22ldHb5RJe7y
1XymYw59/JHrxlKvaV8msdgnDtmpd8AzKfEoW6PjmjCawO4Z4Kc=
=wpqx
-END PGP SIGNATURE-



Bug#1069649: rust-nu-ansi-term: please upgrade to v0.50

2024-04-22 Thread Jonas Smedegaard
Source: rust-nu-ansi-term
Version: 0.49.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, branch v0.50.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGQIACgkQLHwxRsGg
ASEAPQ//fYEsmxceCZkNeaOL6Xj5j/ZGIPjHehx37ySEvqxKSZPAxGms64sV8gdy
DcSdDStiO6+UyfuAe/DYmceOiJe/iJoz3SOkAapF8gKJ24DjdQGBX0BeiP6eWtPK
dw48QvzCBvrDTQD8rT9Sm+iJLIRMU0egJxIFxomHJcC2O9tCgC8hpJFvuvzuMorW
/V2De7t68bq9cS9nYM24VjN3qPbsutZPIIDoVWTohyYZCJQ7JfGSLAA5fQK7d3HX
s8fvHsyKI/MS2RB81L+LrXwCwnFceG7SpQPQfeq6TGPKYipW/xixD87dCpv9t9xa
hFlv4Qku44lBIkBLIWT6q2FA0XOeL0tfNfmXXSk7byeLgQzvgyLa4rXyFWvua2lM
Omo36Hn35PnOu9vpbgkLl2ayFY9t5CVR+uFr7DpAuNti/BP5QX2App/jieB6IQks
uGRqOjmo1UKKS2EFmxUWIaIy/SYER6qJWOyUAQd4Lm6GBjb0qwdlkp5Zd+xq3xvL
rZYpX2Hfr63OX9mo4So+YVpnB168a30spTNwlI7OUiF/uaWhTImY0klUGugs9jV0
cPCeFxr8mmH2nFvSDpIpQp81AgpzOY36nqP+q/kXXu3bBQHv0m+tZVL39iVt5fIl
J9dLPkV+JBPC5AKO+DVppqMEctB+AnVdjXnP9l89FmmJ6nETjfQ=
=37/p
-END PGP SIGNATURE-



Bug#1069648: rust-ctrlc: please update to v3.4.4

2024-04-22 Thread Jonas Smedegaard
Source: rust-ctrlc
Version: 3.4.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v3.4.4.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGLMACgkQLHwxRsGg
ASGOEQ/+L0OBiZJrBVXCtOGq+WEEBR7XFihd0+Bu8X4KS8fH9sI4hyN0rf1ETqon
Hl10NsiT02KqkusS0LJaYY7Wii+6BF2gVbRAdHh7XO9Lw63/vH33tg/w9Hjng1kE
O2CxWcMQ9SYrLumi5uSbPJgs0iD7i/3DejnRQvvOgrANV1Qfb27PYuDHT3w0AlqG
r3v9+AvmOsBpabGuoIy/vcVtCLjXrzwXES5KK3vw+0Nlxqq0qnUmZvyBzk8QDB7u
jAVqhDM4KUIQ0oumpqhsKaochBegIJhE0ltCW55ulKKrl5Fhmj0rtJ48PcM5Ji8b
tXqnFeWV04H2YbRqK3ojxf172DV8sa3rP1xWKrZhcXiWKDSwLs5DsevMecErY/LO
wwuZYYpA/K7d18QkwbXBBo8fLVOvvE5ioohrTXi6bH8R8VyKRZ0U5WzuTSaP290M
EcvLJm/YCgVTfyxYwW8zZ6UU9tGmWsj5LbeKZjzo4L+gK/FttzSg8Xifnkmy/Y5n
u7TPM4kR9w6V7YykIvWk6FJ2zpluoMOB9HQPdSszIzXXTEF9BNB3YugruM7CeagQ
pEjqAt/2k7LY7m9uVMx88YssK8un1b+upEOAtKG2F05sqxYpR8BNQoQ4ifY5TDSt
EJmOTKWWKe2NaKP2H1WCjmG1EIpxKTXSBzmQZvX9trwdzRQ5M3A=
=ZZzd
-END PGP SIGNATURE-



Bug#1069646: python-glance-store - Build-depends on deprecated package: python3-boto

2024-04-22 Thread Bastian Blank
Package: python-glance-store
Version: 4.7.0-2
Severity: serious

python-glance-store build-depends on deprecated package python3-boto.
See #1058652

Also it seems to not build at all:

| dpkg-buildpackage: info: source package python-glance-store
| dpkg-buildpackage: info: source version 4.7.0-2
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Thomas Goirand 
|  dpkg-source --before-build .
| dpkg-source: info: using options from source/debian/source/options: 
--extend-diff-ignore=^[^/]*[.]egg-info/
|  /bin/true debian/rules clean
|  debian/rules build-indep
| make: pyversions: No such file or directory
| py3versions: no X-Python3-Version in control file, using supported versions
| dh build-indep --buildsystem=python_distutils --with python3,sphinxdoc
| dh_auto_configure: warning: Please use the third-party "pybuild" build system 
instead of python-distutils
| dh_auto_configure: warning: This feature will be removed in compat 12.
| make[1]: pyversions: No such file or directory
| py3versions: no X-Python3-Version in control file, using supported versions
| echo "Do nothing..."
| Do nothing...
| make[1]: pyversions: No such file or directory
| py3versions: no X-Python3-Version in control file, using supported versions
| echo "Do nothing..."
| Do nothing...
|create-stamp debian/debhelper-build-stamp
|  /bin/true debian/rules binary-indep
|  dpkg-genbuildinfo --build=all -O../python-glance-store_4.7.0-2_all.buildinfo
| dpkg-genbuildinfo: error: binary build with no binary artifacts found; 
.buildinfo is meaningless
| dpkg-buildpackage: error: dpkg-genbuildinfo --build=all 
-O../python-glance-store_4.7.0-2_all.buildinfo subprocess returned exit status 
255

Bastian

-- 
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown



Bug#1069647: rust-color-eyre: please update to at least v0.6.3

2024-04-22 Thread Jonas Smedegaard
Source: rust-color-eyre
Version: 0.6.2-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.6.3.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmGIYACgkQLHwxRsGg
ASEkFw//drJxzpBaTazAR3wCkfKS4Grno2gjJ5apQV8u0gNeva+dFtYQs2zO59aG
XpMm2/wuxRNuzvz9NCB/s91Lz7zSjUeOs3PveDXnE4aF++WdSR/TX+Vit6vi2MFU
tRw1woMK2e80nHvDup5ARkv60CSoaz4CZos0oceuGJbFmP//kPrS/WZz7vTvJWDl
b7FwDnJRazxk8BpGNE3rs+2S7vzjYay9lSRjvWoOOB+L49cv0g+/7YcHW1fUMfyX
2eqElSKe75FOT/8QO/5qefh/BK8xrp3D5FEQqfjwrmnFQgUwMO6Z2mcAmlOAS3Uc
wjo0xL+7U3NckK1XAOVC9bLxkzBR4Z7JZpynpIHUeKcJax/SfmBA1X/JzgLhtLfh
LFRi7uR4mFQjHhl85Ic97QQOdgH8tk98DVv68TvaqqhwdIWRDnP0+3CmmZQevv45
QpCWjXSjQ+WHfj54lfShkFa479/GyWNpPIbi50y1Wo1pgz0BHa1XuWmGSCxEwyGN
RTZI4XqTYgGQ7j6vQwtNXwUWY+dn5BuLHYhGyZzy8+UW8pQgDQ0IYdZ1b7rf7f9k
7VDLQPeEya8y8gvHYtViLy0pdHtD9RtF3lp65Ia6F+idNFMaKqbCm85p5BErgPDk
qaDPK7Thuwt7ADwURFzHQ8f4MqUXqR/AHSA4B55PAL0uJjRQ3CY=
=qgcA
-END PGP SIGNATURE-



Bug#1069644: rust-async-trait: please update to v0.1.77

2024-04-22 Thread Jonas Smedegaard
Source: rust-async-trait
Version: 0.1.77-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v0.1.77.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmF70ACgkQLHwxRsGg
ASFFGRAAk6XQF16oCYZSKXya7phUvoFGv0aPwRhPOcFNkEG4dmvnRTkjg5cgNktn
LOvuctrM8Z2zEJxMOCo0ejhBnzst3Ee8Ni+ijppfK72cYn5SUlP3qWeNT8GBtOV7
KNyxmmXZRDJb79bRAhCyM2KwWZBvmY/ajQ3wgU9SnkbbD74W8uJ4Oe0/ysR3l1Lq
V1IF0EF+GpyxUhXDrq9B6xjrVs5pi1f8UxbL2JkcC+nWYPWSjC2YfsLkH9oFu2Ne
L54IQOKj3Hj2h6UDqEGhgzLqFdpLjZgXIf8jfJh4OSMBEVx8d9mpaDMmVt8S8cUU
kiuC0Yecqo154mdWWoLiniQS7mr5lC0uzQ7PlYylgY/ZZ/aN7cD/MBdViwhIpT3O
+J73Vi097Pgu991FucVLDGP7yG8I/iHUcH0sM7K0oNpsiBqj/nLqM3Bb1frjA/gj
3I9+KVpB0IX9M3cMIPgci8paY1Aqk5A1+E+GggYUMMW71NvOj0y1Y4rrFg4B8N0V
qIYDAdg9fcRFGdZGqsXqRXoR1yS5onZNOq600iulUbt6GULTW1mFsKQFXc862Lub
sQxj3KALqCUrp1BGlQWn0zD8z4Duc7yEQumk7ADOkvyWUSDxXgOIfmC2GAoXd8G7
qkwkElViMnmKncfNbwouaDKrrzcgPw3pwleGma1cie8ljQoXoKI=
=VsDb
-END PGP SIGNATURE-



Bug#1069645: rust-clap: please update to v4.5.4

2024-04-22 Thread Jonas Smedegaard
Source: rust-clap
Version: 4.4.18-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v4.5.4.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmYmF+8ACgkQLHwxRsGg
ASHhYw/9Fx38qDCQz7ORubVYLDNaEGFx0++2srAJjUBfLpn5mvJF4wkDzBw9htJb
WZPG9/g1BwvXwJn5eq7knJlgFOToRhbarTeybD0HTyfuS9/1l6/iwcwSULCi5KX8
Vd8a8z1l5KCpjxTMO4Y5HGa5TqwED9vvjmy7QbuG9h/dETHw/9f9bxJuOFr13a4/
M9E32iMn+2cSnDtjwNRDoZfMoysUMetWxJMesFb5HNoUrcJr0V3ORdvFHhouV9UJ
VHk1oqb6198E9tJAh+umJV3g4fIHSL1Trh9un0yHPfQMKwA+fFnc+/DqDlFDiiFc
pylVDYKpkoDaf9HKAG0zYsU+OP1LmDilaacXwgjAAIuZubKM4Ofi68l8cW/+AbAg
B2Hv5I/+OL4pnpDx6c9zcU5DAMQMM3P/WgW44TUGpbk8kRfxH7h5yOlPN6VLyoZw
7anHbcL8e17VF9xX7LYnAufM4B9Fq9j5eukLL5Evda/QKG7LeHn1Q6qyU4GAs1cL
CcqYkS5GCyQ5noD2seNCSqF9bMbP1AAf9kAqm1ShbPBdrwoG14urMsG0dzmIETuT
WFKgtnFsJw+Qpbh4aKQ+o35hoXqGSVcZuFuOVeFmUrUMEZf2GYTTeOx3HiAeNpjS
4R54alqMWaSle8iZhvYxsgRIMraS4cvhX4D36nH5dBz/3exrMmQ=
=u0Gt
-END PGP SIGNATURE-



Bug#1069643: dh_installman: doesn't honor nodoc build profile

2024-04-22 Thread Fab Stz
Package: debhelper
Version: 13.15.3
Severity: normal

Dear Maintainer,

According to dh_installman, it should honor the nodoc build profile.
However, it doesn't. As well as execute_before_dh_install.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 
'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 
'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 
'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 
'unstable'), (93, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-20-amd64 (SMP w/4 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=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.1-1
ii  dpkg 1.21.22
ii  dpkg-dev 1.21.22
ii  dwz  0.15-1
ii  file 1:5.44-3
ii  libdebhelper-perl13.11.4
ii  libdpkg-perl 1.21.22
ii  man-db   2.11.2-2
ii  perl 5.36.0-7+deb12u1
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information



Bug#1068818: sngrep: CVE-2024-3119 CVE-2024-3120

2024-04-22 Thread Victor Seva
Hi,

On 21/4/24 21:58, Moritz Muehlenhoff wrote:
> Hi Victor,
> diff looks fine, but I don't believe this really needs a DSA; it's rather 
> obscure attack vector.
> I think addressing this via the next Bookworm point release is perfectly 
> fine, what do you think?

Fine for me. No objections from my side.

  
> Procedure is outlined at
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

Ack.Thanks

-- 
-
|   ,''`. Victor Seva |
|  : :' :  linuxman...@torreviejawireless.org |
|  `. `'  PGP: 8F19 CADC D42A 42D4 5563  730C 51A0 9B18 CF5A 5068 |
|`-  Debian Developer |
  -


OpenPGP_signature.asc
Description: PGP signature


OpenPGP_0x7D7B65C42A0EC8B2.asc
Description: application/pgp-keys


Bug#1069641: right versions

2024-04-22 Thread Alexandre Rossi
Hi,

With the right versions, sorry for the noise.

nmu uwsgi-plugin-php_2.0.22+4+0.0.15+b2 . ANY . unstable . -m "rebuild against 
new uwsgi.h"
nmu uwsgi-plugin-luajit_2.0.22+4+0.0.8+b2 . ANY . unstable . -m "rebuild 
against new uwsgi.h"
nmu uwsgi-plugin-mongo_2.0.24+3+0.0.9+b3 . ANY . unstable . -m "rebuild against 
new uwsgi.h"

Thanks.



Bug#1069191: glibc: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence

2024-04-22 Thread Charlemagne Lasse
Hi,

Can this be backported to older Debian versions via the security repo?
This bug can be used to execute code when using the PHP engine:

* https://www.offensivecon.org/speakers/2024/charles-fol.html
* https://www.openwall.com/lists/oss-security/2024/04/18/4



Bug#1069499: mtbl: FTBFS on armhf: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2

2024-04-22 Thread Robert Edmonds
Lucas Nussbaum wrote:
> Source: mtbl
> Version: 1.3.0-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on armhf.
> 
> 
> Relevant part (hopefully):

> > test-sorted-merge: t/test-sorted-merge.c:96: quiet_tmpnam: Assertion 
> > `not_found == 1' failed.

Hi, Lucas:

I see the function that failed here has been entirely rewritten since this
release, so I've uploaded the latest upstream version 1.6.1 and that built
successfully on all architectures. So I'll mark this bug fixed in 1.6.1-1.

Thanks!

-- 
Robert Edmonds
edmo...@debian.org



Bug#1069641: nmu: uwsgi-plugin-php_2.0.22+1+0.0.15+b1 uwsgi-plugin-luajit_2.0.22+1+0.0.8+b1 uwsgi-plugin-mongo_2.0.22+1+0.0.9+b1

2024-04-22 Thread Alexandre Rossi
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: uwsgi-plugin-...@packages.debian.org, d...@jones.dk
Control: affects -1 + src:uwsgi-plugin-php
Control: affects -1 + src:uwsgi-plugin-luajit
Control: affects -1 + src:uwsgi-plugin-mongo

Hi,

uwsgi.h changed again, and uwsgi ABI id is derived from that file, so
a rebuild is required for plugins to depend on the correct uwsgi-abi binary
package.

nmu uwsgi-plugin-php_2.0.22+1+0.0.15+b1 . ANY . unstable . -m "rebuild against 
new uwsgi.h"
nmu uwsgi-plugin-luajit_2.0.22+1+0.0.8+b1 . ANY . unstable . -m "rebuild 
against new uwsgi.h"
nmu uwsgi-plugin-mongo_2.0.22+1+0.0.9+b1 . ANY . unstable . -m "rebuild against 
new uwsgi.h"

Thanks!



Bug#1069302: libxerces-c-samples: k.zmi...@gmail.com

2024-04-22 Thread Konrad Zminda
Package: libxerces-c-samples
Followup-For: Bug #1069302
X-Debbugs-Cc: k.zmi...@gmail.com

Steps to reproduce the issue : 

get up-to-date debian bookworm,

apt-get install apache2 libxerces-c-samples [ see full output of output from 
dpkg --list > packages.txt ]

put attached schema.xsd in /var/www/html/schema.xsd ; note that file has a lot 
of padding; without it the issue cannot be triggered,

put attached file.xml anywhere in the file system

run /usr/bin/StdInParse -n -v=always -s -f < file.xml you’ll most likely get

Fatal Error at (file , line 0, char 0): internal error in NetAccessor

Fatal Error at (file stdin, line 2, char 121): fatal error during schema scan


the same works fine under debian-bullseye


I'm attaching files schema.xsd, file.xml, packages.txt  so that you can 
reproduce the issue 

http://www.w3.org/2001/XMLSchema-instance; 
xsi:noNamespaceSchemaLocation="http://localhost/schema.xsd;>
 John Doe
 30

http://www.w3.org/2001/XMLSchema;>
 
  
   


   
  
 









































































































































































































































































































































































































































































































































































Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion 
Architecture Description
+++-===-===--
ii  adduser 3.134   all 
 add and remove users and groups
ii  apache2 2.4.57-2
amd64Apache HTTP Server
ii  apache2-bin 2.4.57-2
amd64Apache HTTP Server (modules and other binary files)
ii  apache2-data2.4.57-2all 
 Apache HTTP Server (common files)
ii  apache2-utils   2.4.57-2
amd64Apache HTTP Server (utility programs for web servers)
ii  apparmor3.0.8-3 
amd64user-space parser utility for AppArmor
ii  apt 2.6.1   
amd64commandline package manager
ii  apt-listchanges 3.24all 
 package change history notification tool
ii  apt-utils   2.6.1   
amd64package management related utility programs
ii  base-files  12.4+deb12u5
amd64Debian base system miscellaneous files
ii  base-passwd 3.6.1   
amd64Debian base system master password and group files
ii  bash5.2.15-2+b2 
amd64GNU Bourne Again SHell
ii  bash-completion 1:2.11-6all 
 programmable completion for the bash shell
ii  bind9-dnsutils  1:9.18.24-1 
amd64Clients provided with BIND 9
ii  bind9-host  1:9.18.24-1 
amd64DNS Lookup Utility
ii  bind9-libs:amd641:9.18.24-1 
amd64Shared Libraries used by BIND 9
ii  binutils2.40-2  
amd64GNU assembler, linker and binary utilities
ii  binutils-common:amd64   2.40-2  
amd64Common files for the GNU assembler, linker and binary utilities
ii  binutils-x86-64-linux-gnu   2.40-2  
amd64GNU binary utilities, for x86-64-linux-gnu target
ii  bsdextrautils   2.38.1-5+deb12u1
amd64extra utilities from 4.4BSD-Lite
ii  bsdutils1:2.38.1-5+deb12u1  
amd64basic utilities from 4.4BSD-Lite
ii  build-essential 12.9
amd64Informational list of build-essential packages
ii  busybox 1:1.35.0-4+b3   
amd64Tiny utilities for small and embedded systems
ii  bzip2   

Bug#1069417: upgrade procedure instructs users to run “apt update” but neglects upgrading

2024-04-22 Thread Holger Wansing
Control: tags -1 + patch


Manny  wrote:
> The Bookworm release notes instruct users to “upgrade” to the latest point 
> release of Bullseye prior to upgrading to Bookworm:
> 
>   
> https://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#upgrade-to-latest-point-release
> 
> When following that link, the article says to do an “apt update” then 
> neglects to tell users to perform the upgrade.

Moreover, we have "This should only be necessary in specific situations." in 
this chapter appendix A [1], while we recommend to upgrade to the latest point
release of stable in 4.2.2 [2].

We should remove that phrase completely.

A patch for above two issues is attached (against the bookworm branch; any
such changing needs to be ported to master/trixie as well).


Holger


[1] 
https://www.debian.org/releases/stable/amd64/release-notes/ap-old-stuff.en.html#old-upgrade
[2] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-to-latest-point-release

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/old-stuff.dbk b/en/old-stuff.dbk
index b1c734e7..287c80c1 100644
--- a/en/old-stuff.dbk
+++ b/en/old-stuff.dbk
@@ -2,22 +2,21 @@
 https://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
%languagedata;
%shareddata;
 ]>
 
 
 Managing your  system before the upgrade
 
 This appendix contains information on how to make sure you can install or
-upgrade  packages before you upgrade to .  This should only be
-necessary in specific situations.
+upgrade  packages before you upgrade to .
 
 
 Upgrading your  system
 
 Basically this is no different from any other upgrade of  you've been
 doing.  The only difference is that you first need to make sure your package
 list still contains references to  as explained in .
 
 
@@ -73,20 +72,31 @@ not.  It is possible to downgrade packages, but that is not covered here.
 If you've made any changes, save the file and execute
 
 
 # apt update
 
 
 to refresh the package list.
 
 
 
+
+Performing the upgrade to latest  release
+
+To upgrade all packages to the state of the latest point release for
+, do
+
+
+# apt full-upgrade
+
+
+
 
 Removing obsolete configuration files
 
 Before upgrading your system to , it is recommended to remove old
 configuration files (such as *.dpkg-{new,old} files under
 /etc) from the system.
 
 
 
 


Bug#1053334: galera-4: FTBFS because of expired certificates

2024-04-22 Thread Otto Kekäläinen
I was able to reproduce this for Bookworm both locally and in CI at
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/5620032

After importing latest upstream build/test passes:
https://salsa.debian.org/otto/galera/-/jobs/5624466

Stable upload request filed at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069639



Bug#1069637: hd-idle: version 1.21+ds-1 hangs the upgrade process

2024-04-22 Thread Alex Mestiashvili

On 4/22/24 02:54, Arthur Marsh wrote:

Package: hd-idle
Version: 1.21+ds-1
Severity: normal

Dear Maintainer,

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

* What led up to the situation?

Setting up hd-idle (1.21+ds-1) ...
Installing new version of config file /etc/default/hd-idle ...
Installing new version of config file /etc/logrotate.d/hd-idle ...
Stopping the hd-idle daemon: hd-idle.
Starting the hd-idle daemon: hd-idlesymlinkPolicy=0, defaultIdle=600, 
defaultCommand=scsi, defaultPowerCondition=0, debug=false, logFile=, devices=

process just hung at this point.

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

Had to kill hd-idle process then downgrade hd-idle.


Could you please share parts of your hd-idle configuration?
I couldn't reproduce the problem, so I suspect it might be related to 
some incompatibility in the config options.


Thanks,
Alex



Bug#1069640: lintian still links to lintian.debian.org but it is gone

2024-04-22 Thread Adam Baxter
Package: lintian
Version: 2.117.0
Severity: normal
X-Debbugs-Cc: deb...@voltagex.org

Dear Maintainer,
This is related to #1053710 (but apparently Affects: isn't the right tag here? 
There should be a Related: tag IMO)

   * What led up to the situation?

Lintian produces messages like "E: mypackage: no-copyright-file" where 
no-copyright-file is a link to 
https://lintian.debian.org/tags/no-copyright-file.
lintian.debian.org is gone as of 2023 so these URLs should be changed.

   * What outcome did you expect instead?
Being able to click the hyperlink (TIL OSC8) and find out what the warning / 
note means


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

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

Versions of packages lintian depends on:
ii  binutils2.42-4
ii  bzip2   1.0.8-5.1
ii  diffstat1.66-1
ii  dpkg1.22.4
ii  dpkg-dev1.22.4
ii  file1:5.45-2+b1
ii  gettext 0.21-14+b1
ii  gpg 2.2.40-1.1+b1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b3
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b2
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b2
ii  libclone-perl   0.46-1+b1
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.83-2+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.4
ii  libemail-address-xs-perl1.05-1+b2
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b2
ii  libperlio-utf8-strict-perl  0.010-1+b1
ii  libproc-processtable-perl   0.636-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b1
ii  libsereal-encoder-perl  5.004+ds-1+b1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1+b1
ii  libterm-readkey-perl2.38-2+b2
ii  libtext-levenshteinxs-perl  0.03-5+b2
ii  libtext-markdown-discount-perl  0.16-1+b1
ii  libtext-xslate-perl 3.5.9-1+b3
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b1
ii  liburi-perl 5.28-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.77-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b2
ii  libyaml-libyaml-perl0.89+ds-1
ii  lzop1.04-2
ii  man-db  2.12.0-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-3
ii  plzip [lzip-decompressor]   1.11-1
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.6.1+really5.4.5-1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information



Bug#1069639: bookworm-pu: package galera-4 26.4.18-0+deb12u1

2024-04-22 Thread Otto Kekäläinen
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: mari...@packages.debian.org
Control: affects -1 + src:galera-4

I propose that the latest minor maintenance version of Galera be included in the
stable release update of Debian.

Packaging source is ready at
https://salsa.debian.org/mariadb-team/galera-4/-/tree/debian/bookworm and
pending upload.

## Changelog

galera-4 (26.4.18-0+deb12u1) bookworm; urgency=medium

  * Switch to upstream aware DEP-14 branch structure in gbp.conf
  * New upstream release 26.4.18. Includes multiple bug fixes, see

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.18.txt
  * For previous release details see

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.17.txt

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.16.txt

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.15.txt

https://github.com/codership/documentation/blob/master/release-notes/release-notes-galera-26.4.14.txt
  * New upstream signing key 3D53839A70BC938B08CDD47F45460A518DA84635,
verified from 26.4.17 release notes
  * New upstream release includes multiple Debian build and post-build test
failure fixes:
- Generate keys and certificates for SSL tests (Closes: #1053334)
- Attempt to bind to UDP and skips tests if not available
  (Related: #1007954)
- Fix 'uuid == WSREP_UUID_UNDEFINED' (Related: #970044)
- Fix issues reported -Werror when compiling (Related: #970043)
- Fix UBSAN issues (Closes: #1053183, Related: #970042)

## Debdiff

A source debdiff is attached, which was created with commands:
git diff --stat debian/26.4.13-1..debian/bookworm | xz >
debian-26.4.18-0+deb12u1.debdiff.stat.xz
git diff debian/26.4.13-1..debian/bookworm | xz >
debian-26.4.18-0+deb12u1.debdiff.xz

## Quality control

- Bookworm specific CI passed at
https://salsa.debian.org/mariadb-team/galera-4/-/pipelines


debian-26.4.18-0+deb12u1.debdiff.stat.xz
Description: application/xz


debian-26.4.18-0+deb12u1.debdiff.xz
Description: application/xz


<    1   2