Bug#1070667: libssl3: Cannot remove system package:

[Sebastian Andrzej Siewior]

+ Steve Langasek, Benjamin Drung

On 2024-05-07 00:02:11 [+0300], Odysseas Romanos wrote:
> Package: libssl3
> Version: 3.1.5-1
> Severity: important
> X-Debbugs-Cc: oromanos2...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>I was trying to update the system via Discover
>The outcome of the failed update was this message 
>   WARNING: You are trying to remove the following essential packages: 
> libssl3 (due to coreutils) libapt-pkg6.0 (due to apt) libgnutls30 (due to 
> apt) libext2fs2 (due to e2fsprogs) 
>the outcome i expected was an up;dated system

Is this bookworm -> trixie or old trixie -> new trixie?

Not sure if this is related to #1065135 but it is transition related.

Sebastian

Bug#1070681: kalendar: QML module 'org.kde.kitemmodels' not a dependency, but Kalendar fails to launch without it

[Vedanth Padmaraman]

Package: kalendar
Version: 22.12.3-2+b2
Severity: important
X-Debbugs-Cc: vedanthpadmaraman0...@gmail.com

Dear Maintainer,

It seems that Kalendar will not start without finding QML module 
'org.kde.kitemmodels' (from
package qml-module-org-kde-kitemmodels); however, it is not installed as a 
dependency for
Kalendar. I can confirm that on installing `qml-module-org-kde-kitemmodels`,
the issue goes away and Kalendar launches.

* What I did:
  - Installed kalendar without installing Recommended packages:
`apt install --no-install-recommends kalendar`
  - Launched Kalendar

* What happened:
  The app exits immediately. When running from a console, the following error 
message
  is seen:

  $ kalendar
  QML debugging is enabled. Only use this in a safe environment.
  QQmlApplicationEngine failed to load component
  qrc:/main.qml:493:19: Type MainDrawer unavailable
  qrc:/MainDrawer.qml:15:1: module "org.kde.kitemmodels" is not installed

* How I fixed it:
  Installed package `qml-module-org-kde-kitemmodels` through APT:
  `apt install qml-module-org-kde-kitemmodels`

I suppose `qml-module-org-kde-kitemmodels` should be added as a dependency for 
Kalendar... If that
is the case, should I go ahead and submit a patch for the same?

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

Kernel: Linux 6.7.9-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages kalendar depends on:
ii  akonadi-server  4:22.12.3-1+b2
ii  kdepim-runtime  4:22.12.3-2+b1
ii  kio 5.107.0-1+b2
ii  libc6   2.37-17
ii  libgcc-s1   14-20240330-1
ii  libgpgme11t64   1.18.0-4.1+b1
ii  libkf5akonadicalendar5abi1 [libkf5akonadicalendar5-22.  4:22.12.3-1+b2
12]
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.12] 4:22.12.3-1+b2
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]   4:22.12.3-1+b2
ii  libkf5akonadimime5 [libkf5akonadimime5-22.12]   4:22.12.3-1+b2
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.12  4:22.12.3-1+b2
]
ii  libkf5calendarcore5abi2 5:5.107.0-1+b2
ii  libkf5calendarsupport5abi1 [libkf5calendarsupport5-22.  4:22.12.3-1+b1
12]
ii  libkf5codecs5   5.107.0-1+b2
ii  libkf5configcore5   5.107.0-1+b2
ii  libkf5configgui55.107.0-1+b2
ii  libkf5configwidgets55.107.0-2+b2
ii  libkf5contacts5 5:5.107.0-2
ii  libkf5coreaddons5   5.107.0-1+b2
ii  libkf5dbusaddons5   5.107.0-1+b2
ii  libkf5eventviews5abi1 [libkf5eventviews5-22.12] 4:22.12.3-1+b1
ii  libkf5i18n5 5.107.0-1+b2
ii  libkf5itemmodels5   5.107.0-1+b2
ii  libkf5kiocore5  5.107.0-1+b2
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-22.12] 4:22.12.3-1+b4
ii  libkf5mime5abi1 [libkf5mime5-22.12] 22.12.3-1+b2
ii  libkf5widgetsaddons55.107.0-1+b2
ii  libkf5windowsystem5 5.107.0-1+b2
ii  libkf5xmlgui5   5.107.0-1+b2
ii  libqt5core5t64  5.15.10+dfsg-7.2+b1
ii  libqt5dbus5t64  5.15.10+dfsg-7.2+b1
ii  libqt5gui5t64   5.15.10+dfsg-7.2+b1
ii  libqt5qml5  5.15.10+dfsg-2+b2
ii  libqt5quick55.15.10+dfsg-2+b2
ii  libqt5quickcontrols2-5  5.15.10+dfsg-2+b2
ii  libqt5widgets5t64   5.15.10+dfsg-7.2+b1
ii  libstdc++6  14-20240330-1
ii  qml-module-org-kde-kirigami-addons-labs-mobileform  0.9.0-1+b2
ii  qml-module-org-kde-kirigami25.107.0-1+b2
ii  qml-module-qt-labs-qmlmodels5.15.10+dfsg-2+b2
ii  qml-module-qtlocation   5.15.10+dfsg-3+b2
ii  qml-module-qtpositioning5.15.10+dfsg-3+b2

Versions of packages kalendar recommends:
pn  kalendarac  

kalendar suggests no packages.

-- no debconf information

Bug#989463: please align shim-signed dkms behaviour with Ubuntu

[Wladimir Mutel]

Dear Maintainers,

Recently I upgraded Ubuntu 22.04 to Debian 12 Bookworm.
I used out-of-tree driver 88XXau for my USB WiFi adapter,
so with DKMS build I hit the behavior described in this bug,
that is, upgraded DKMS created its own key pair in /var/lib/dkms
and ignored already-enrolled MOK stored in /var/lib/shim-signed/mok/ .

So I got "Key was rejected by service" when I tried to modprobe the rebuilt 
module.

To resolve this problem, I just symlinked them into /var/lib/dkms :

ln -sf /var/lib/shim-signed/mok/MOK.priv /var/lib/dkms/mok.key
ln -sf /var/lib/shim-signed/mok/MOK.der /var/lib/dkms/mok.pub

After that, I uninstalled/unbuilt this module and reinstalled it
using appropriate dkms command-line options.
And to my great joy, the rebuilt module was successfully modprobed into the 
kernel,
even without requiring a reboot.

So it would be really useful for DKMS, when it is being upgraded over some 
previous version,
to inherit MOK created by shim-signed and to avoid creation of it own MOK.

Bug#1070680: freeipa-client: unable to convert the attribute 'cacertificate;binary' value

[Martin Pitt]

Package: python3-ipaclient
Severity: important
Version: 4.11.1-2
Tags: upstream, fixed-upstream
Forwarded: 
https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org/thread/PLR7R2FIZXNOQFMT3XWMBK3UYI7FWVMY/

Hello,

A few days ago, python-cryptography 42.0 entered Debian testing. This
unfortunately breaks FreeIPA. When joining an existing IPA server (running on
CentOS 8, but doesn't matter much), joining the domain fails with

| unable to convert the attribute 'cacertificate;binary' value b'0\x82[...]' to 
type 
| Cannot obtain CA certificate
| 'ldap://f0.cockpit.lan' doesn't have a certificate.

/var/log/ipaclient-install.log has a very long traceback, excerpts:

| 2024-05-07T04:16:52Z DEBUG Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 1031, in 
decode
| return x509.load_der_x509_certificate(val)
|^^^
|   File "/usr/lib/python3/dist-packages/ipalib/x509.py", line 445, in 
load_der_x509_certificate
| return IPACertificate(
|^^^
| TypeError: Can't instantiate abstract class IPACertificate with abstract 
methods not_valid_after_utc, not_valid_before_utc
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 374, in 
_sync_attr
| value = self._conn.decode(value, name)
| ^^
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 1037, in 
decode
| raise ValueError(msg)
| ValueError: unable to convert the attribute 'cacertificate;binary' value 
b'[...]' to type 
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/ipaclient/install/client.py", line 
1739, in get_certs_from_ldap
| certs = certstore.get_ca_certs(conn, base_dn, realm, ca_enabled)
| 
|   File "/usr/lib/python3/dist-packages/ipalib/install/certstore.py", line 
310, in get_ca_certs
| for cert in entry.get('cACertificate;binary', []):
| ^
|   File "", line 774, in get
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 510, in 
__getitem__
| return self._get_nice(name)
|
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 485, in 
_get_nice
| self._sync_attr(name)
|   File "/usr/lib/python3/dist-packages/ipapython/ipaldap.py", line 376, in 
_sync_attr
| raise ValueError("{error} in LDAP entry '{dn}'".format(
| ValueError: unable to convert the attribute 'cacertificate;binary' value [...]

This was already reported upstream (see "Forwarded:" above), and fixed in
upstream git 4 months ago:

   
https://pagure.io/freeipa/c/a45a7a20d96af51d463a285cb9318582720be708?branch=master

Unfortunately there hasn't been a new release since then. But I applied the
patch straight to /usr/lib/python3/dist-packages/ , it applies with some fuzz,
and joining the domain works fine afterwards.

Thanks,

Martin

Bug#1070679: kbd: loadkeys: Unable to open file: de: No such file or directory

[Arnaud Rebillout]

Package: kbd
Version: 2.6.4-2
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

First: note that I'm not familiar with keyboard settings (I've always
used a US keyboard, so defaults work for me), so it might be a silly bug
report.

The bug was initially reported against the Kali bugtracker at [1]. But
it can be easily reproduced with Debian: just boot the Debian installer,
switch to a console, and try to use the command 'loadkeys'.

The issue is that 'loadkeys' (provided by the kbd package) doesn't work
out of the box.

$ loadkeys de
loadkeys: Unable to open file: de: No such file or directory

This happens because the package console-data is not installed. And the
fix is to install console-data, after that loadkeys works.

My question is therefore about kbd packaging, in particular the field
Recommends:

   Recommends: console-setup | console-data

Why a logical OR, why not recommend both packages? Then loadkeys would
be functional out of the box.

At the moment, users who want to use loadkeys have absolutely no chance
to guess what's wrong. The user message could be improved to say what
file is missing (assuming the program looks for a particular file), or
could even suggest to install console-data (that would be a
Debian-specific patch). Just some ideas.

Thanks for reading! Best,

Arnaud



[1]: https://bugs.kali.org/view.php?id=8741#c19246

Bug#1068755: docker.io: FTBFS: failing tests

[Tianon Gravi]

On Mon, 6 May 2024 at 17:00, Cyril Brulebois  wrote:
> I'm adding Tianon to the loop explicitly since I'm definitely no Docker
> (or Go) expert, in case some time can be spared to look into this
> problem. Otherwise I'll try and come up with something.

I think the backport by Reinhard[1][2] is probably correct/simplest,
although definitely a case of "how did this test ever work??" 

[1]: https://bugs.debian.org/1068755#13
[2]: https://bugs.debian.org/1068755#20

(it might be worth annotating that upstream patch with slightly more
DEP3 so it's clear we can just drop it in v23+, though   it got
backported from v24 in [3])

[3]: https://github.com/moby/moby/pull/45062

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1070678: nproc show different cores count with /proc/cpuinfo

[YunQiang Su]

Package: coreutils
Version: 9.4-3.1

CPU: AMD Ryzen 7 6800U with Radeon Graphics
Kernel version: 6.7.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.12-1
(2024-04-24) x86_64 GNU/Linux


Too save power, I use the attached script to disable CPU cores, and
run it every minute
by cron. It depends `nproc` to determine the count of cores currently.

When the system is idle,  so the CPU cores is 2, and then I start to
build kernel with -j16.
And 2 more cores are enabled soon, while `nproc` always claims that
there are only 2 cores
are enabled.


disable-cores.sh
Description: application/shellscript

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[Xiyue Deng]

Xiyue Deng  writes:

> Xiyue Deng  writes:
>
>> Xiyue Deng  writes:
>>
>>> Sean Whitton  writes:
>>>
 Hello,

 On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote:

> Sean Whitton  writes:
>
>> Hello,
>>
>> Rob, can you review the implementation in d/rules for Xiyue's patch to
>> this bug, please?  I'm not sure it's the straightforward way to do it.
>>
>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
>> for the relationships.
>
> Ah indeed, I should update the versions after the Emacs 29.3 upload,
> though I think you meant "1:29.3+1-2".  Also, as we are just moving
> files from emacs-common to emacs-pgtk, breaks/replaces is only needed
> from emacs-pgtk to emacs-common but no the other way around, so I
> dropped the breaks on emacs-pgtk from emacs-common.
>
> I have updated the patch accordingly and attached here.  PTAL.

 Thanks.

> (BTW, I'm always curious about the "+1" part of the version number.  I
> would expect something like "+dfsg" or "+ds" as we are dropping some
> of the non-DFSG conformant files, but why "+1"? :)

 It's just in case the DFSG split is done incorrectly and another attempt
 is required -- given how complex it is.
>>>
>>> Ack, totally understandable.
>>>
>>> With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it
>>> and bumped the breaks/replaces version.  PTAL.
>>
>> Rob suggested on IRC to be a bit more conservative by removing the file
>> and remove the directories upwards recursively so that we can catch
>> future addition to the directories more easily.  The patch has been
>> adjusted accordingly.  PTAL.
>
> Friendly ping.  Rob, do you have any more comments on the current
> approach?

Friendly ping 2 :)

-- 
Xiyue Deng

Bug#1054109: ocaml: lack of LoongArch support

[Jiajie Chen]

I think you can already use ocaml on LoongArch without the native 
compiler, use the bytecode compiler instead.


On 2024/5/7 10:25, lixing wrote:


在 2024/5/6 下午8:48, John Paul Adrian Glaubitz 写道:

Hi LiXing,


[0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)]
I'm afraid this patch is way too large to be included in a Debian 
package.


Please make sure these changes are being upstreamed, so that native 
LoongArch

support will be part of the next major Ocaml upstream release in Debian.

Adrian

Thanks, But I'm afraid the ocaml upstream will not accept LoongArch 
support in a short time.


What's else can we do to support ocaml in debian?

Bug#998197: kdeconnectd: should not listen on all interfaces by default

[Witold Baryluk]

Package: kdeconnect
Followup-For: Bug #998197
X-Debbugs-Cc: witold.bary...@gmail.com

severity -1 serious
tags -1 security
thanks


Elevating severity, because it looks like I didn't even installed this
package (I did inspect all apt-get install invokations since system
creation), and it kdeconnect could only be installed due to some
suggests / recommends, not due to any dependency or direct request.

And as mentioned already before. It autostarts on desktop login, even if
one does not use KDE (it autostarts in normal gnome-shell session for
example).

So this is even more dangerous.

Bug#1054109: ocaml: lack of LoongArch support

[lixing]

在 2024/5/6 下午8:48, John Paul Adrian Glaubitz 写道:

Hi LiXing,


[0001-Add-LoongArch-support-for-ocaml.patch (text/plain, attachment)]

I'm afraid this patch is way too large to be included in a Debian package.

Please make sure these changes are being upstreamed, so that native LoongArch
support will be part of the next major Ocaml upstream release in Debian.

Adrian

Thanks, But I'm afraid the ocaml upstream will not accept LoongArch 
support in a short time.


What's else can we do to support ocaml in debian?

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

[Vincent Lefevre]

On 2024-05-07 03:57:44 +0200, Vincent Lefevre wrote:
> sshd_backend = systemd

BTW, that would fix the issue only for sshd. But what about the other
jails the user could have enabled in /etc/fail2ban/jail.local? The
user configuration may rely on systemd being the default backend, at
least the configured backend for these jails.

For instance, concerning postfix, both paths-arch.conf and
paths-opensuse.conf have "postfix_backend = systemd", but not
paths-debian.conf. Other jails may be concerned.

paths-arch.conf has

# These services will log to the journal via syslog, so use the journal by
# default.
syslog_backend = systemd
sshd_backend = systemd
dropbear_backend = systemd
proftpd_backend = systemd
pureftpd_backend = systemd
wuftpd_backend = systemd
postfix_backend = systemd
dovecot_backend = systemd

and paths-opensuse.conf has

# These services will log to the journal via syslog, so use the journal by
# default.
syslog_backend = systemd
sshd_backend = systemd
dropbear_backend = systemd
proftpd_backend = systemd
pureftpd_backend = systemd
wuftpd_backend = systemd
postfix_backend = systemd
dovecot_backend = systemd
mysql_backend = systemd

But the user may also have his own services with associated jails...

Either there should be a better fix or the change should be announced
in NEWS.Debian, with a clear explanation on what to do.

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

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

[Vincent Lefevre]

On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote:
> May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban 
>[557228]: ERROR   Failed during configuration: Have not found 
> any log file for sshd jail

I suppose that this is because sshd no longer uses the systemd
backend. This is wrong. If I understand correctly, the point of

https://github.com/fail2ban/fail2ban/issues/3292#issuecomment-2078361360

is to no longer use the systemd backend for all jails, but for
sshd only. So "backend = systemd" has been removed from DEFAULT,
but the above comment also points to

https://github.com/fail2ban/fail2ban/commit/85a4881a9a818b6a746109f74980919296eedad0

which adds for DEFAULT in paths-debian.conf:


banaction = nftables
banaction_allports = nftables[type=allports]

sshd_backend = systemd


But paths-debian.conf has not changed in the fail2ban 1.1.0-1 package.

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

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

[Vincent Lefevre]

Package: fail2ban
Version: 1.1.0-1
Severity: grave
Justification: renders package unusable

After the upgrade to 1.1.0-1, "systemctl status" gives

× fail2ban.service - Fail2Ban Service
 Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: 
enabled)
 Active: failed (Result: exit-code) since Tue 2024-05-07 03:01:28 CEST; 
25min ago
   Duration: 58ms
   Docs: man:fail2ban(1)
   Main PID: 557228 (code=exited, status=255/EXCEPTION)
CPU: 55ms

May 07 03:01:28 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service.
May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban   
 [557228]: ERROR   Failed during configuration: Have not found any 
log file for sshd jail
May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,230 fail2ban   
 [557228]: ERROR   Async configuration of server failed
May 07 03:01:28 qaa systemd[1]: fail2ban.service: Main process exited, 
code=exited, status=255/EXCEPTION
May 07 03:01:28 qaa systemd[1]: fail2ban.service: Failed with result 
'exit-code'.

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

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

Versions of packages fail2ban depends on:
ii  python3  3.11.8-1
ii  python3-systemd  235-1+b3

Versions of packages fail2ban recommends:
ii  iptables   1.8.10-3
ii  nftables   1.0.9-1+b2
ii  python3-pyinotify  0.9.6-2
ii  whois  5.5.22

Versions of packages fail2ban suggests:
ii  mailutils [mailx]  1:3.17-1.1+b2
pn  monit  
ii  sqlite33.45.3-1
pn  system-log-daemon  

-- no debconf information

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

Bug#1070672: azure-cli: should not request surveys from the user

[brian m. carlson]

tags 1070672 + patch
kthxbye

On 2024-05-06 at 21:59:34, brian m. carlson wrote:
> azure-cli prompts the user for surveys in at least some circumstances
> when running `az login`.  This is done using a bright blue, three-line
> banner that is large and distracting, and totally unnecessary.
> 
> The Unix philosophy is that software should be silent unless it has
> something relevant to say to the user.  Survey requests benefit
> Microsoft, but are not actually relevant to the user, and if the user
> wanted to provide feedback, it would be just as easy to find the
> appropriate website to do so.  In addition, terminal users do not expect
> software in Debian to print lots of noisy messages to the terminal, and
> in general, when software does so, it's considered a bug.
> 
> Please disable the survey requests in Debian to keep azure-cli quiet.

I've included a Git format patch as an attachment.  This is not against
the Debian repository since salsa.debian.org was down at the time I was
looking at this, but it's against a `git init` of the latest package.

It should be pretty straightforward and easy to read.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
From  Mon Sep 17 00:00:00 2001
From: "brian m. carlson" 
Date: Tue, 7 May 2024 00:58:28 +
Subject: [PATCH] Don't prompt user for surveys

The survey message that is used is three lines and has a bright blue
background and is very distracting compared to other text on the screen.
In addition, the Unix philosophy states that software should avoid
unnecessary output, and upstream's desire for users to complete a survey
is not functionally necessary or useful for end users.  Remove this
prompt since it is noisy and annoying to terminal users.

Users wanting to access the survey can still run `az survey` if they
want.
---
 src/azure-cli/azure/cli/__main__.py | 6 --
 1 file changed, 6 deletions(-)

diff --git a/src/azure-cli/azure/cli/__main__.py b/src/azure-cli/azure/cli/__main__.py
index 513e914..1b983d1 100644
--- a/src/azure-cli/azure/cli/__main__.py
+++ b/src/azure-cli/azure/cli/__main__.py
@@ -13,7 +13,6 @@ import uuid
 
 from azure.cli.core import telemetry
 from azure.cli.core import get_default_cli
-from azure.cli.core.intercept_survey import prompt_survey_message
 from knack.completion import ARGCOMPLETE_ENV_NAME
 from knack.log import get_logger
 
@@ -119,11 +118,6 @@ finally:
 logger.warning("Auto upgrade failed. %s", str(ex))
 telemetry.set_exception(ex, fault_type='auto-upgrade-failed')
 
-try:
-prompt_survey_message(az_cli)
-except Exception as ex:  # pylint: disable=broad-except
-logger.debug("Intercept survey prompt failed. %s", str(ex))
-
 telemetry.set_init_time_elapsed("{:.6f}".format(init_finish_time - start_time))
 telemetry.set_invoke_time_elapsed("{:.6f}".format(invoke_finish_time - init_finish_time))
 telemetry.conclude()


signature.asc
Description: PGP signature

Bug#1069743: Removal of features from default keepassxc package

[Hernán Cabañas]

Dear Mantainer,


I would like to endorse the first message and add another possible issue 
that appears when using the default keepassxc package: There is also 
missing functionality with browser integration with the minimal version 
of keepassxc. Existing installations would lose this widely used feature 
without a clear path to restoring it.



A mantainer/developer upstream proposed in a GitHub discussion 
(https://github.com/keepassxreboot/keepassxc/discussions/10686#discussioncomment-9335365) 
the creation of a keepassxc-minimal package instead of the current 
solution. This would offer an alternative to security-minded users 
without removing functionalities for current installations.



Thank you for your time.

Kind Regards,

~hcg

Bug#1040375: /usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so: Segmentation fault when used with anything

[Bernhard Übelacker]

On Sat, 10 Feb 2024 11:01:54 +0100 Petter Reinholdtsen  wrote:

[Petter Reinholdtsen]
> I do not use ssr much myself, and have not had time to test.

I applied the upstream commit in git branch fix-1040375-glinject and
tested it on Bookworm, but alas, the .so file still segfaults with a
useless backtrace.  I might have applied the commit incorrectly, as it
did not apply without changes, but hope not.  Perhaps someone
who understand what is happening can have a look?

--
Happy hacking
Petter Reinholdtsen




Hello,
looking through some bugs about crashes I came to this one
and found found it interesting.

If a proper backtrace is still helping one can get one by using
systemd-coredump.

Another nice way to debug early startup is using rr debugger.
(Plus the ability to debug back and forth.)


As far as I see the crash happens because it wants to print this message:

57  GLINJECT_PRINT("Error: Can't open libdl.so!");

But unfortunately libstdc++ seems not yet prepared to output the error.


(rr) bt
#0  0x7fbf7ff2fd9a in std::basic_ostream 
>::sentry::sentry(std::basic_ostream >&) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7fbf7ff3074c in std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long) () 
from /lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x7fbf7ff30bdb in std::basic_ostream >& std::operator<< 
 >(std::basic_ostream >&, char const*) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7fbf805cef6f in InitGLInject () at ./glinject/Hook.cpp:57
#4  0x7fbf805cf13f in dlsym (handle=0x7fbf8060d2e0, symbol=0x7fbf80185f7a 
"pthread_create") at ./glinject/Hook.cpp:231
#5  0x7fbf80136dd7 in glvndSetupPthreads () at 
../src/util/glvnd_pthread.c:452
#6  0x7fbf801351a9 in __glDispatchOnLoadInit () at 
../src/GLdispatch/GLdispatch.c:174
#7  0x7fbf805de9ce in call_init (env=0x7ffeea4b1538, argv=0x7ffeea4b1528, argc=1, 
l=) at ./elf/dl-init.c:74
#8  call_init (l=, argc=1, argv=0x7ffeea4b1528, 
env=0x7ffeea4b1538) at ./elf/dl-init.c:26
#9  0x7fbf805deab4 in _dl_init (main_map=0x7fbf8060d2e0, argc=1, 
argv=0x7ffeea4b1528, env=0x7ffeea4b1538) at ./elf/dl-init.c:121
#10 0x7fbf805f4a70 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0001 in ?? ()
#12 0x7ffeea4b25ea in ?? ()
#13 0x in ?? ()
(rr)

(For some reason with libstdc++6-dbgsym the backtrace gets less good.)



I guess upstream discussed this issue here:

  https://github.com/MaartenBaert/ssr/issues/947


And a package built from `fix-1040375-glinject` did no
longer show this crash to me.


Attached file shows my actions inside a minimal bookworm VM.

Kind regards,
Bernhard
# 2024-05-07 Bookworm/stable amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump mc gdb rr mesa-utils git simplescreenrecorder-lib 
simplescreenrecorder-lib-dbgsym libglvnd0-dbgsym libstdc++6-dbgsym appstream
apt build-dep simplescreenrecorder-lib






mkdir /home/benutzer/source/simplescreenrecorder/orig -p
cd/home/benutzer/source/simplescreenrecorder/orig
apt source simplescreenrecorder







benutzer@debian:~$ 
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so 
/usr/bin/true
Speicherzugriffsfehler (Speicherabzug geschrieben)
benutzer@debian:~$ 


benutzer@debian:~$ coredumpctl list
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
TIME PID  UID  GID SIG COREFILE EXESIZE
Tue 2024-05-07 00:10:28 CEST 994 1000 1000 SIGSEGV present  /usr/bin/true 89.0K
benutzer@debian:~$ 



benutzer@debian:~$ coredumpctl gdb --debugger-argument=-q 994
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 994 (true)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2024-05-07 00:10:28 CEST (1min 26s ago)
  Command Line: /usr/bin/true
Executable: /usr/bin/true
 Control Group: /user.slice/user-1000.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1000.slice
   Session: 3
 Owner UID: 1000 (benutzer)
   Boot ID: 4df23299079540e38e42560b3966b576
Machine ID: 55a5ad9df1d547f38d7696343d9fde7d
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.true.1000.4df23299079540e38e42560b3966b576.994.171503342800.zst
 (present)
  Size on Disk: 89.0K
   Message: Process 994 (true) of user 1000 dumped core.

Stack trace of thread 994:
#0  0x7f988d92fd9a _ZNSo6sentryC1ERSo (libstdc++.so.6 + 
0x12fd9a)
#1  0x7f988d93074c 
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l 
(libstdc++.so.6 + 0x13074c)
 

Bug#1068755: docker.io: FTBFS: failing tests

[Cyril Brulebois]

Hi Santiago,

And thanks for the report.

Santiago Vila  (2024-04-10):
> Package: src:docker.io
> Version: 20.10.25+dfsg1-2
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> During a rebuild of all packages in unstable, your package failed to build:
> 
> === FAIL: distribution/xfer 
> TestMaxDownloadAttempts/max-attempts=5,_fail_at_6th_attempt (0.88s)
> time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (2/5): 
> simulating download attempt 2/2"
> time="2024-04-10T10:28:41Z" level=info msg="Download failed, retrying (1/5): 
> simulating download attempt 1/6"
> download_test.go:425: assertion failed: expected error "simulating 
> download attempt 5/6", got "simulating download attempt 6/6"
> time="2024-04-10T10:28:42Z" level=info msg="Download failed, retrying (5/5): 
> simulating download attempt 5/5"
> 
> === FAIL: distribution/xfer TestMaxDownloadAttempts (0.00s)

That FTBFS is easily reproducible via cowbuilder (sid, amd64), and also
within an unclean, up-to-date devel schroot (still sid, amd64).

I'm adding Tianon to the loop explicitly since I'm definitely no Docker
(or Go) expert, in case some time can be spared to look into this
problem. Otherwise I'll try and come up with something.

Thanks for considering!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1057562: Forwarded upstream (Was: gcr4: FTBFS: failing tests)

[Santiago Vila]

would you also offer such a VM to gcr4 upstream?


Yes.

(Or just tell them that it fails 100% of the time on AWS
instances of type m6a.large and r6a.large, which are the
ones I tried).

(btw: I tried registering myself to gnome's gitlab right now,
but did not receive confirmation email, hope they can help).

Thanks.

Bug#1069265: tzdata: Upgrade from 2023c-2 to 2024 corrupts zoneinfo files

[Plasma (David Paul)]

On Thu, 18 Apr 2024 23:39:14 + IvanAbs  wrote:
> On 2024-04-17 several of my servers running Debian 10 received an
> update for the tzdata package via Debian unattended-upgrade. However,
> this update resulted in corruption of files within the
> /usr/share/zoneinfo directory.

I, too, encountered a variation of this issue today while trying to
update the tzdata package on my system. I was eventually able to resolve
the issue with a little manual intervention. Details follow.

> I was using tzdata 2023c-2 package, and originally installed from an
> official Debian source

In my case, the installed version of the package was tzdata 2023c-5.

> I installed tzdata 2023c-2 with dpkg -i, because our severs needs the
> last-year updated data, but there were not a release for Debian 10,
> until yesterday.

Similarly, I had installed tzdata 2023c-5 on what is effectively Debian
Bullseye install (though what is actually an unabashed FrankenDevuan
install that is mostly composed of packages from Devuan's Chimaera
release). My motivation for doing so was similar: I wanted the
then-current timezone database and the package in chimaera/bullseye had
yet to be updated. I fully acknowledge this course of action is
actively frowned upon[1].

[1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

> To resolve this issue, I had to completely remove the tzdata 2023
> version and perform a clean installation of the new tzdata 2024
> version.

Here's how I was able to resolve the issue. Using snapshot.debian.org,
I downloaded tzdata_2023d-1_all.deb which installed without issue over
2023c-5. Afterward, I was able to install tzdata 2024a-0+deb11u1
without issue.

As this issue only manifests on systems in explicitly unsupported
configurations, the severity of the bug should probably be reduced from
grave, but I will leave that decision to others.

I hope this was helpful,

-- 
Plasma

Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently

[Santiago Vila]

Hello.

My plan for base-files is to stop overriding the PATH in /etc/profile.

Ubuntu did that a long time ago and it's probably the right thing to do.

I'd like to do this for trixie, but only after the t64 transition is finished
and the usr-merge patch from Helmut Grohne is implemented.

Also, I want to be sure that nothing breaks, and if it does, I want to be
sure that I'm not forced to set the PATH again. See what happened the last
time I tried :-)

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

Thanks.

Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required

[Luca Boccassi]

On Tue, 7 May 2024 at 00:18, Cyril Brulebois  wrote:
>
> Luca Boccassi  (2024-05-06):
> > Pending at:
> > https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8
>
> I'm not sure how often we change template types, but I suppose this
> particular instance (error → boolean) makes sense and isn't problematic.
>
> Please mention “GRUB” (instead of “grub”) for consistency with upstream
> and the rest of d-i though. (I know this is very minor but better catch
> that early to avoid another l10n round later on.)

Sure, fixed, thanks

Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required

[Cyril Brulebois]

Luca Boccassi  (2024-05-06):
> Pending at:
> https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8

I'm not sure how often we change template types, but I suppose this
particular instance (error → boolean) makes sense and isn't problematic.

Please mention “GRUB” (instead of “grub”) for consistency with upstream
and the rest of d-i though. (I know this is very minor but better catch
that early to avoid another l10n round later on.)


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


signature.asc
Description: PGP signature

Bug#1037084: bookworm: When using gdm3 to start non-GNOME wayland sessions, PATH may be set differently

[Jay]

On Wed, May 1, 2024 at 6:13 PM Alban Browaeys  wrote:
> So you were right that reverting commit ccecd9c9 would fix your issue,
> but not because gdm added a bug but because it stopped hiding an
> underlying "bug" (well wrong default PATH value in systemd for Debian).
> It could be that systemd maintainers thing this is gdm job to overwrite
> their value, though it looks more correct to me to bug them first as
> they are the one setting the wrong default for Debian (or so I believe,
> I have not checked extensively if the wrong PATH default value could be
> fine at the systemd level and be changed afterwards).
Thanks again! I finally found some time to further investigate this.
I have reassigned this bug report to the systemd package,
but it looks like base-files and libpam-modules are the packages
involved.

My Debian system was installed in 2022-10. To be sure this wasn't
just a misconfigured system in 2022, I checked again with a fresh
Debian 12.5 install and found that the same defaults are present.

> The Debian specific defaults are shown in /etc/profile
Reading that made me check Ubuntu's defaults:
/etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
/etc/profile
(no mention of PATH)

It looks like Ubuntu sets PATH in /etc/environment through libpam-modules
and /usr/lib/environment.d/99-environment.conf is symlinked to it.
Debian sets PATH in /etc/profile through base-files and its
/usr/lib/environment.d/99-environment.conf
is symlinked to an empty /etc/environment also created by libpam-modules.

Ubuntu's libpam-modules runs a postinst script:
# Add PATH to /etc/environment if it's not present there or in
# /etc/security/pam_env.conf
if [ "$1" = "configure" ] && dpkg --compare-versions "$2" lt
1.3.1-5ubuntu5; then
if ! grep -qs ^PATH "$DPKG_ROOT"/etc/security/pam_env.conf; then
if ! grep -qs ^PATH= "$DPKG_ROOT"/etc/environment; then
echo
'PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"'
>> "$DPKG_ROOT"/etc/environment
fi
fi
fi

Debian's libpam-modules postinst:
if dpkg --compare-versions "$2" lt 0.99.9.0-1 && ! [ -f
"$DPKG_ROOT"/etc/environment ]
then
 touch "$DPKG_ROOT"/etc/environment
fi

I think we can narrow this down to base-files and/or libpam-modules.
I'm not sure if doing the same thing as the Ubuntu package would be
the right thing
so I'm CC'ing the maintainers for both packages and the debian-desktop
mailing list
for advice instead of reassigning the bug report again.

Bug#1070652: [DRE-maint] Bug#1070652: ruby-json: breaks how-can-i-help

[Cédric Boutillier]

Hi!

I am reassigning this bug to the `how-can-i-help` package. Indeed, the
script `/usr/bin/how-can-i-help` uses implicitly the OpenStruct class,
without requiring explicitly 'ostruct'. The class was loaded
transitively from the json gem it seems.

Adding below line 35 the following line:

require 'ostruct'

fixes the bug.


Cheers,

Cédric

Quoting Vincent Lefevre (2024-05-06 17:41:49)
> Package: ruby-json
> Version: 2.7.2+dfsg-1
> Severity: grave
> Justification: renders package unusable

> This new ruby-json version breaks how-can-i-help:

> [...]
> Unpacking ruby-json:amd64 (2.7.2+dfsg-1) over (2.6.3+dfsg-1+b2) ...
> Setting up ruby-json:amd64 (2.7.2+dfsg-1) ...
> /usr/bin/how-can-i-help:155:in `': uninitialized constant OpenStruct 
> (NameError)

> proxy_uri = $proxy_url.nil? ? OpenStruct.new : URI.parse($proxy_url)
>   ^^

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

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

> Versions of packages ruby-json depends on:
> ii  libc6  2.38-7
> ii  libruby1:3.1+nmu1
> ii  libruby3.1t64  3.1.2-8.3

> ruby-json recommends no packages.

> ruby-json suggests no packages.

> -- no debconf information--- /tmp/how-can-i-help	2024-05-07 01:08:00.390399139 +0200
+++ /usr/bin/how-can-i-help	2024-05-07 00:59:24.082457226 +0200
@@ -33,6 +33,7 @@
 require 'fileutils'
 require 'time'
 require 'etc'
+require 'ostruct'
 
 include Debian
 

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

[Udo Richter]

Hi,

Seeing exactly the same bug with an Broadcom Corp. BCM2045B (BDC-2.1)
bluetooth device, so its not just the Intel AX211.

Jeremy, thanks for tracking this down!

Udo

Bug#1070676: python3-graph-tool: delivered pkgconfig (pc) file does not match with installed files

[Gerion Entrup]

Package: python3-graph-tool
Version: 2.58+ds-1~bpo12+1
Severity: normal
X-Debbugs-Cc: gerion.ent...@flump.de

Dear Maintainer,

The python3-graph-tool package installs the file 
/usr/lib/x86_64-linux-gnu/pkgconfig/graph-tool-py3.11.pc.
This file contains an include path:
-I/usr/lib/python3.11/dist-packages/graph_tool/include

However, this path is wrong, since graph-tool is installed under:
/usr/lib/python3/dist-packages/graph_tool/include
(without the minor version specifier)

This seems to be a Debian specific problem. I installed graph-tool on a Gentoo 
system, too, without problems.
In Gentoo, however, a /usr/lib/python3 directory does not exist at all.

* What led up to the situation?

We develop a tool that depends on graph-tool, links against it and, thus, uses 
the pkgconfig file for the building process.

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

We added an exception for Debian systems in the tool's build system to include 
the python3 path as well.

* What was the outcome of this action?

The compiler finds the graph-tool headers again.

* What outcome did you expect instead?

Normally, the build system should use the pkgconfig file as is to find all 
necessary headers.

Best,
Gerion

-- 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-20-amd64 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_EN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-graph-tool depends on:
ii  libboost-context1.74.0   1.74.0+ds1-21
ii  libboost-iostreams1.74.0 1.74.0+ds1-21
ii  libboost-python1.74.0 [libboost-python1.74.0-py311]  1.74.0+ds1-21
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu72]1.74.0+ds1-21
ii  libc62.36-9+deb12u7
ii  libcairomm-1.0-1v5   1.14.4-2
ii  libexpat12.5.0-1
ii  libgcc-s112.2.0-14
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libgomp1 12.2.0-14
ii  libpython3.113.11.2-6
ii  libstdc++6   12.2.0-14
ii  python3  3.11.2-1+b1
ii  python3-numpy [python3-numpy-abi9]   1:1.24.2-1
ii  python3-scipy1.10.1-2

Versions of packages python3-graph-tool recommends:
ii  gir1.2-gtk-3.0  3.24.38-2~deb12u1
ii  python3-cairo   1.20.1-5+b1
ii  python3-gi  3.42.2-3+b1
ii  python3-gi-cairo3.42.2-3+b1
ii  python3-gv  2.42.2-7+b3
ii  python3-matplotlib  3.6.3-1+b1

Versions of packages python3-graph-tool suggests:
pn  mencoder  

-- no debconf information

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Barak A. Pearlmutter]

Well, it would certainly be simple enough: the source code should
compile fine, and the debian/* scripts would need only the very most
minor tweaks.

Bug#1053678: partman-crypto: Requires separate /boot partition, even if not required

[Luca Boccassi]

Control: tags -1 patch

On Sun, 08 Oct 2023 17:57:01 -0400 Nicholas D Steeves 
wrote:
> Jonathan Hettwer  writes:
> 
> > Package: partman-crypto
> > Version: 121
> > Severity: normal
> > Tags: d-i
> > X-Debbugs-Cc: j24...@gmail.com
> >
> > Dear Maintainer,
> >
> > The `crypto_check_mountpoints` script prevents you from setting up
an
> > encrypted root filesystem without an additional unencrypted /boot
> > filesystem.
> > While this may be a requirement for e.g. grub2, it is not
> > necessarily required when not using grub2 but using UKIs to build
EFI
> > executables that can directly mount the encrypted root filesystem.
> > While UKIs aren't currently supported, I would still expect
partman-crypto
> > to let me partition an encrypted root filesystem without separate
/boot
> > filesystem, at least after having ignored the warnings or in
combination
> > with the `nobootloader` udeb.
> 
> Quick note: systemd-boot works with kernel images + initramfs,
without
> UKI.  After the systemd-boot menu, the user is prompted for the
master
> LUKS password, as usual, and I use the derived key script to then
> unlocks a couple LUKS volumes.  No LVM, no /boot.  It seems to work
> well, but yeah, it's not possible to do this with fresh install (I
> manually migrated an old installation to new hardware).

Pending at:

https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/8

Test iso built by CI can be found here:

https://salsa.debian.org/bluca/partman-crypto/-/jobs/5694502/artifacts/browse/debian/output/

Any help testing would be welcome

-- 
Kind regards,
Luca Boccassi


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

Bug#1070675: pyusid generate an extraneous dependency on python3-six

[Alexandre Detiste]

Source: pyusid
Version: 0.0.12-1
Severity: normal

Please patch out 'six' from setup.py

Greetings

patch: https://github.com/pycroscopy/pyUSID/pull/89

Bug#1014987: netsurf: FTBFS on the Hurd - refresh patch

[jbranso]

April 16, 2024 at 2:47 PM, "João"  wrote:



> 
> X-Debbugs-CC: debian-h...@lists.debian.org
> 
> Dear Maintainer,
> 
> Refreshing the patch fixing the FTBFS on the hurd to version 3.11 of netsurf.
> 
> I don't know if the framebuffer package should be built on the hurd. With the
> 
> attached patch the package builds, but when I try to run the program with the
> 
> SDL frontend, it crashes. But perhaps it is not expected to work.
> 
> In any case that would be the case for a separate bug report.
> 
> Many thanks,
> 
> João

Hello João,

Congrats!  I have been slowly working on doing this...I built netsurf locally, 
but
I just defined PATH_MAX!  Your method is much better!

Would you also try to forward this patch to upstream netsurf?  That would be 
useful!

Thanks!

Joshua

Bug#1070674: gnome-settings-daemon: No oom-kill notifications

[segfault]

Package: gnome-settings-daemon
Version: 46.0-1+b3
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: segfa...@riseup.net

The systemd OOM notification functionality of gnome-settings-daemon is broken
on Debian. On Fedora, a notification is shown when a process is OOM-killed. On
Debian, it only works after applying the attached patch, which calls the
Subscribe() method of org.freedesktop.systemd1.Manager. It's not clear to me
why it works without the patch on Fedora.

I also created an issue and MR upstream, but upstream is waiting on a
confirmation that the systemd behavior (not sending the PropertiesChanged
signal unless Subscribe() was called) is expected.

Upstream issue: https://gitlab.gnome.org/GNOME/gnome-settings-
daemon/-/issues/790
Upstream MR: https://gitlab.gnome.org/GNOME/gnome-settings-
daemon/-/merge_requests/366


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common46.0-1
ii  gsettings-desktop-schemas   46.0-1
ii  libasound2t64   1.2.11-1+b1
ii  libc6   2.37-19
ii  libcairo2   1.18.0-3+b1
ii  libcanberra-gtk3-0t64 [libcanberra-gtk3-0]  0.30-12.2+b2
ii  libcanberra00.30-16
ii  libcolord2  1.4.7-1+b1
ii  libcups2t64 2.4.7-1.2+b1
ii  libfontconfig1  2.15.0-1.1
ii  libgck-2-2  4.2.0-5
ii  libgcr-4-4  4.2.0-5
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b3
ii  libgeoclue-2-0  2.7.1-2+b1
ii  libgeocode-glib-2-0 3.26.3-6+b2
ii  libglib2.0-0t64 2.78.4-7
ii  libgnome-desktop-3-20t6444.0-5
ii  libgtk-3-0t64   3.24.41-4
ii  libgudev-1.0-0  238-5
ii  libgweather-4-0t64  4.4.2-1
ii  libmm-glib0 1.22.0-3+b1
ii  libnm0  1.46.0-2
ii  libnotify4  0.8.3-1+b1
ii  libp11-kit0 0.25.3-5
ii  libpam-systemd [logind] 255.5-1
ii  libpango-1.0-0  1.52.1+ds-1
ii  libpangocairo-1.0-0 1.52.1+ds-1
ii  libpolkit-gobject-1-0   124-2
ii  libpulse-mainloop-glib0 16.1+dfsg1-5
ii  libpulse0   16.1+dfsg1-5
ii  libspa-0.2-bluetooth1.0.5-1+b3
ii  libsystemd0 255.5-1
ii  libupower-glib3 1.90.3-1
ii  libwacom9   2.10.0-2
ii  libwayland-client0  1.22.0-2.1+b1
ii  libx11-62:1.8.7-1+b1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2+b1
ii  libxi6  2:1.8.1-1
ii  pipewire-audio  1.0.5-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy   3.5-1+b2
ii  pipewire-audio 1.0.5-1
ii  pkexec 124-2
ii  x11-xserver-utils  7.7+10+b1

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information
diff --git a/plugins/housekeeping/gsd-systemd-notify.c 
b/plugins/housekeeping/gsd-systemd-notify.c
index 39984f5d..57421cc5 100644
--- a/plugins/housekeeping/gsd-systemd-notify.c
+++ b/plugins/housekeeping/gsd-systemd-notify.c
@@ -204,6 +204,22 @@ on_bus_gotten (GDBusConnection  *obj,
 }
 
 self->session = con;
+
+// Subscribe to systemd events by calling Subscribe on
+// org.freedesktop.systemd1.Manager
+g_dbus_connection_call (self->session,
+"org.freedesktop.systemd1",
+"/org/freedesktop/systemd1",
+"org.freedesktop.systemd1.Manager",
+"Subscribe",
+NULL,
+G_VARIANT_TYPE ("()"),
+G_DBUS_CALL_FLAGS_NONE,
+-1,
+NULL,
+

Bug#1014539: squirrel3: CVE-2022-30292

[Matthias Geiger]

On Thu, 18 Apr 2024 14:40:58 +0200 Matthias Geiger 
 wrote:


>
> //I have prepared a fix; however this needs the FTBFS in #997441
> adressed first.
>
> Will attach a debdiff once that has happened.
>

See attachement.

best,

--
Matthias Geiger 
Debian Maintainer
diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog
--- squirrel3-3.1/debian/changelog  2024-02-16 17:46:43.0 +0100
+++ squirrel3-3.1/debian/changelog  2024-05-06 23:54:53.0 +0200
@@ -1,3 +1,11 @@
+squirrel3 (3.1-8.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream commit as 03-fix-buffer-overflow.diff (Closes: 
#1014539)
+(CVE-2022-30292) 
+
+ -- Matthias Geiger   Mon, 06 May 2024 23:54:53 +0200
+
 squirrel3 (3.1-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff 
squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff
--- squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff1970-01-01 
01:00:00.0 +0100
+++ squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff2024-05-06 
23:52:27.0 +0200
@@ -0,0 +1,22 @@
+From a6413aa690e0bdfef648c68693349a7b878fe60d Mon Sep 17 00:00:00 2001
+From: Alberto Demichelis 
+Date: Mon, 2 May 2022 12:04:58 +0200
+Subject: [PATCH] fix in thread.call
+
+---
+ squirrel/sqbaselib.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/squirrel/sqbaselib.cpp b/squirrel/sqbaselib.cpp
+index 662aeac..e283900 100644
+--- a/squirrel/sqbaselib.cpp
 b/squirrel/sqbaselib.cpp
+@@ -1012,6 +1012,7 @@ static SQInteger thread_call(HSQUIRRELVM v)
+ SQObjectPtr o = stack_get(v,1);
+ if(type(o) == OT_THREAD) {
+ SQInteger nparams = sq_gettop(v);
++sq_reservestack(_thread(o), nparams + 3);
+ _thread(o)->Push(_thread(o)->_roottable);
+ for(SQInteger i = 2; i<(nparams+1); i++)
+ sq_move(_thread(o),v,i);
+
diff -Nru squirrel3-3.1/debian/patches/series 
squirrel3-3.1/debian/patches/series
--- squirrel3-3.1/debian/patches/series 2024-02-16 17:46:43.0 +0100
+++ squirrel3-3.1/debian/patches/series 2024-05-06 23:52:45.0 +0200
@@ -1,2 +1,3 @@
 01-fix-spelling-errors.patch
 02-sphinx-ext.patch
+03-fix-buffer-overflow.diff

Bug#1070673: azure-cli: contains telemetry

[brian m. carlson]

Source: azure-cli
Version: 2.50.0-2
Severity: normal

The documentation in this package indicates that telemetry collection is
on by default, and I don't see any patches that indicate that that has
been removed.

Debian should not ship software that sends telemetry by default because
it violates the privacy of users, and it is typically only in the
interest of the maintainer, not the users.  It's not reasonable to
expect users to configure every package they might install separately
not to send telemetry, since that's impractical and it's nearly
impossible to configure every piece of software to do so, especially in
environments like containers where users' settings are often not
persisted.

Please remove the telemetry functionality from the package or ensure
that it is rendered completely nonfunctional, and add a note to the
README.Debian indicating this change so that users can feel more
confident in using the package.


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

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

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#1070672: azure-cli: should not request surveys from the user

[brian m. carlson]

Package: azure-cli
Version: 2.50.0-2
Severity: normal

azure-cli prompts the user for surveys in at least some circumstances
when running `az login`.  This is done using a bright blue, three-line
banner that is large and distracting, and totally unnecessary.

The Unix philosophy is that software should be silent unless it has
something relevant to say to the user.  Survey requests benefit
Microsoft, but are not actually relevant to the user, and if the user
wanted to provide feedback, it would be just as easy to find the
appropriate website to do so.  In addition, terminal users do not expect
software in Debian to print lots of noisy messages to the terminal, and
in general, when software does so, it's considered a bug.

Please disable the survey requests in Debian to keep azure-cli quiet.


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

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

Versions of packages azure-cli depends on:
ii  python33.11.8-1
ii  python3-azure-cli  2.50.0-2

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#1070671: Please include static library builds in libharfbuzz-dev

[Daniel Richard G.]

Package: libharfbuzz-dev
Version: 8.3.0-2+b1

It is customary for -dev packages to provide static archive libraries in
addition to the bare .so files for shared-library linking. The current
version of libharfbuzz-dev only provides the latter, and thus does not
allow applications to statically link the libraries.

I understand that GObject introspection requires a shared-library build,
but this functionality is often not needed. In particular, the Chromium
browser consumes harfbuzz and harfbuzz-subset, and does perfectly well
without introspection support. I recently ran into a situation on the
Ubuntu side of things where the lack of a static-linking option caused
some difficulty in supporting Chromium on 22.04/jammy:

https://bugs.launchpad.net/bugs/2064821

My solution was to produce a modified harfbuzz package that provides
(only) static libraries:


https://launchpad.net/~xtradeb/+archive/ubuntu/deps/+sourcepub/16120809/+listing-archive-extra

Needless to say, it would be preferable if the official packages
supported static linking from the get-go.

Bug#1070670: bullseye-pu: package shim/15.8-1~deb11u1

[Steve McIntyre]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-...@lists.debian.org

This is a new upstream version of shim, built for bullseye. This is
needed for better handling of SBAT-based revocations, plus a range of
security updates from upstream.

[ This is very similar to the bookworm update in #1070660 ]

See attached debdiff for the changes. They're not minimal, but in the
case of shim we need to be as close to upstream as possible for the
sake of getting stuff reviewed and signed. The only local patches to
the upstream source now are:

 * to force SBAT updates to revoke older insecure grub binaries
 * to allow for building on arm64 with older toolchain (retained from
   previous bullseye builds)

There are some minor changes to packaging to help with review.

I've tested locally using CI and also by hand on various machines and
all looks good here.

Obviously, once this is accepted and autobuilt I'll need to submit
things for review and signing elsewhere. Then we'll be want
shim-signed updting too.

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

shim (15.8-1~deb11u1) bullseye; urgency=medium

  * New upstream release fixing more bugs
  * Remove previous patches, no longer needed:
+ Make-sbat_var.S-parse-right-with-buggy-gcc-binutils.patch (now
  upstream)
+ Enable-NX.patch (we don't want NX just yet until the whole boot
  stack is NX-capable)
+ block-grub-sbat3-debian.patch (not needed now upstream grub SBAT
  is 4)
  * Cherry-pick 2 new patches from upstream for grub revocations:
+ 0001-sbat-Add-grub.peimage-2-to-latest-CVE-2024-2312.patch
+ 0002-sbat-Also-bump-latest-for-grub-4-and-to-todays-date.patch
  * Log if the build is nx-compatible or not
  * Force shim to use the latest revocations by default to block some
older grub / peimage issues. This is:
"shim,4\ngrub,4\ngrub.peimage,2\n"
  * Install a copy of the Debian CA certificate into /usr/share/shim.
Closes: #1069054
  * Clean up better after build. Closes: #1046268


shim_15.8-1~deb11u1.debdiff.gz
Description: application/gzip

Bug#1070669: Please include a static library build in libdav1d-dev

[Daniel Richard G.]

Package: libdav1d-dev
Version: 1.4.1-1

It is customary for -dev packages to provide a static archive library in
addition to the bare .so file for shared-library linking. The current
version of libdav1d-dev only provides the latter, and thus does not
allow applications to statically link the library.

Bug#1066211:

[Arvin Sedererdj]

Control: tags -1 + patch
Description: explicitly declare returntype of main bootstrap sourcefile
 dpkg version 1.22.6 makes -Werror=implicit-function-declaration
 mandatory which breaks ATS2 build. this adds ats_int_type as return 
 type of functions that breaks the build. (keep in mind ats_int_type
 is just int, as defined in src/CBOOT/ccomp/runtime/ats_types.h)
 .
 ats2-lang (0.4.2-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * source only upload to enable migration (Closes: #1066211)
Author: Arvin Torshizi 
Bug-Debian: https://bugs.debian.org/1066211

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Bug-Debian: https://bugs.debian.org/1066211
Forwarded: (not-needed)
Reviewed-By: 
Last-Update: 2024-05-06

--- ats2-lang-0.4.2.orig/src/CBOOT/prelude/ats_main_prelude_dats.c
+++ ats2-lang-0.4.2/src/CBOOT/prelude/ats_main_prelude_dats.c
@@ -69,30 +69,30 @@ mainats_prelude () {
 // ATSlocal_void (tmp0) ;
 
 __ats_lab_mainats_prelude:
-ATS_2d0_2e2_2e12_2prelude_2DATS_2basics_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2bool_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2char_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2float_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2integer_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2sizetype_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2pointer_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2reference_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2string_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2lazy_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2lazy_vt_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2printf_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2filebas_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2list_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2list_vt_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2list0_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2option_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2option_vt_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2option0_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2array_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2array0_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2matrix_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2matrix0_2edats__dynload () ;
-ATS_2d0_2e2_2e12_2prelude_2DATS_2ptrarr_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2basics_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2bool_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2char_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2float_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2integer_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2sizetype_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2pointer_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2reference_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2string_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2lazy_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2lazy_vt_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2printf_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2filebas_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2list_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2list_vt_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2list0_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2option_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2option_vt_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2option0_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2array_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2array0_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2matrix_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2matrix0_2edats__dynload () ;
+ats_int_type ATS_2d0_2e2_2e12_2prelude_2DATS_2ptrarr_2edats__dynload () ;
 return /* (tmp0) */ ;
 } /* end of [mainats_prelude] */
 

Bug#1062831: closed by Debian FTP Masters (reply to Dennis Braun ) (Bug#1062831: fixed in guitarix 0.46.0+dfsg-1)

[Francesco Poli]

On Fri, 29 Mar 2024 19:45:05 + Debian Bug Tracking System wrote:

[...]
>* New upstream version 0.46.0+dfsg
>  + Fix segfaults, when creating a preset bank (Closes: #1062831)
[...]

Thanks a lot, I can confirm that this bug is fixed.   :-)

Bye and keep up the good work!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpcsAoMh7AVF.pgp
Description: PGP signature

Bug#1070441: FTBFS due to /usr/include/aarch64-linux-gnu/bits/math-vector.h

[Aurelien Jarno]

control: severity 1070441 important
control: block 1070668 by 1070441
control: severity 1070443 important
control: block 1070668 by 1070443
control: severity 1070444 important
control: block 1070668 by 1070444
control: severity 1070446 important
control: block 1070668 by 1070446


Dear maintainers,

glibc 2.38 introduced changes to the bits/math-vector.h file on arm64 in
order to support math vector functions. This unfortunately caused the
FTBFS of your packages.

The change has been temporarily reverted in version 2.38-8 until a fix
is found, and I have opened #1070668 on the glibc side to track the
issue, with a Cc: to the arm64 porters.

I am therefore downgrading the bugs to severity important. However this
should not prevent working on a solution to the problem with the arm64
porters, and depending on the case either at the package level, or at
the upstream glibc/gcc/llvm level.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1052376: lxpanel: no longer obeys its geometry settings

[Francesco Poli]

On Tue, 23 Apr 2024 17:12:54 +0300 jim_p  wrote:
[...]
> 
> Since there is no interest from the maintainers in fixing a 6+ month old grave
> bug, I want to ask. Has anyone moved away from lxpanel or even lxde?
[...]

Hello!

I am the original submitter of this bug report.

I have recently moved away from lxpanel: I have switched to xfce4-panel.

I had to adjust my setup a little, but, overall, I am quite happy with
what I could achieve.

My current setup (within a desktop based on Fluxbox) is described in my
documentation [page].

[page]: 


I hope this helps.
Bye!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpQ5Z0KZS1Kv.pgp
Description: PGP signature

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Bastien Roucariès]

Le lundi 29 avril 2024, 18:40:39 UTC Barak A. Pearlmutter a écrit :
> Bastien,
> 
> Okay, got it. Thanks for letting me know.
> 
> I can cherry-pick that fossil commit, but you know the right magic for
> a versioned apache2 breakage and how to deal with proposed-updates.
> So I think it would make sense for you to do all of this in a
> coordinated fashion?
> If that's okay with you, please feel free to just do a regular upload
> if you want, or an NMU, as you please.
> I will push your changes into the debian fossil branch, unless you'd
> like write access to my fossil packaging repo
>  https://people.debian.org/~bap/fossil.fsl
> which I'd be happy to set up.
> 
> Cheers,
> 
> --Barak.
> 
Thanks for you work, do you think a full backport of fossil is worthwhile for 
stable ?

Bastien


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

Bug#1070668: glibc: packages FTBFS caused by vector math library header on arm64

[Aurelien Jarno]

Source: glibc
Version: 2.38-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debian-...@lists.debian.org
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30909

glibc 2.38 added vector math library (libmvec) support for arm64, with
ASIMD and SVE version. This includes an architecture specific header,
/usr/include/aarch64-linux-gnu/bits/math-vector.h, to declare the
vectorized functions. For that the ASIMD types __Float32x4_t and
__Float64x2_t are also defined for GCC >= 9 or CLANG >= 8, and SVE
types __SVFloat32_t, __SVFloat64_t and __SVBool_t for GCC >= 10 and
CLANG >= 11.

Unfortunately this causes issues to the following packages:
- #1070441 cmbc: arm64 FTBFS with glibc 2.38
- #1070443 aspectc++: arm64 FTBFS with glibc 2.38
- #1070444 cxref: arm64 FTBFS with glibc 2.38
- #1070446 rocm-hipamd: arm64 FTBFS with glibc 2.38

The issue has already been reported upstream [1].

For now this file has been restored to the generic version in glibc
2.38-8, removing support for the corresponding vector functions [2].

Porters, could you please have a look at the issue, and work on fixes
at the package level and at the upstream glibc/gcc/llvm level?

Thanks
Aurelien

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30909
[2] 
https://salsa.debian.org/glibc-team/glibc/-/commit/9e2889537336bdad878eef88bcfb13e457e8ea77
 

Bug#1070667: libssl3: Cannot remove system package:

[Odysseas Romanos]

Package: libssl3
Version: 3.1.5-1
Severity: important
X-Debbugs-Cc: oromanos2...@gmail.com

Dear Maintainer,

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

   I was trying to update the system via Discover
   The outcome of the failed update was this message 
WARNING: You are trying to remove the following essential packages: 
libssl3 (due to coreutils) libapt-pkg6.0 (due to apt) libgnutls30 (due to apt) 
libext2fs2 (due to e2fsprogs) 
   the outcome i expected was an up;dated system




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

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

Versions of packages libssl3 depends on:
ii  libc6  2.37-18

libssl3 recommends no packages.

libssl3 suggests no packages.

-- no debconf information

Bug#1070666: util-linux: last(1) is broken on i386 since 2.40-8

[Eugene Berdnikov]

Package: util-linux
Version: 2.40-8
Severity: normal

 Hello.

 Upgrade of util-linux from 2.39.3-6 to 2.40-8 on i386 systems breaks
 last(1), while the same upgrade on amd64 systems does not break it.
 Examples on my hosts running in 32-bit mode:

--
root@citrine # /usr/bin/last -3
last: unrecognized ut_type: 22985
last: preallocation size exceeded

--
root@typhoon # /usr/bin/last -3
last: unrecognized ut_type: 3640
last: unrecognized ut_type: 52
6.5.0-1- 3 Thu Jan  1 03:00gone - no logout
last: unrecognized ut_type: -14908
amd64evel  Sat Jul  6 11:21 - down  
(586103921+18:44)
last: preallocation size exceeded

--
root@passat # /usr/bin/last -3
last: unrecognized ut_type: -13985
last: unrecognized ut_type: 53
6.5.0-1- 2 Thu Jan  1 03:00gone - no logout
last: unrecognized ut_type: 15714
last: unrecognized ut_type: -4407
amd64evel  Sat Jul  6 11:21gone - no logout
last: unrecognized ut_type: -31324
last: unrecognized ut_type: 29555
6.5.0-1- b9Thu Jan  1 03:00gone - no logout
last: unrecognized ut_type: 2583
last: unrecognized ut_type: 29556
last: unrecognized ut_type: -18676
last: unrecognized ut_type: 19843
last: unrecognized ut_type: 14690
192.168. ts/9root  Thu Jan  1 03:00gone - no logout
last: preallocation size exceeded

--

 Running binary extracted from util-linux 2.39.3-6 package (as /tmp/last)
 always produce right results:
--
root@citrine # /tmp/last -3
root pts/9192.168.27.27Mon May  6 22:40   still logged in
root pts/9192.168.27.7 Mon May  6 10:19 - 13:20  (03:01)
root pts/10   192.168.27.17Fri May  3 16:12 - 19:10  (02:57)

wtmp begins Sun Apr 14 11:18:49 2024
--

 Package info:
 
||/ Name   Version  Architecture Description
+++-==---=
ii  util-linux 2.40-8   i386 miscellaneous system utilities
ii  libc-bin   2.37-18  i386 GNU C Library: Binaries
ii  libc-l10n  2.37-18  all  GNU C Library: localization files
ii  libc6:i386 2.37-18  i386 GNU C Library: Shared libraries

-- 
 Eugene Berdnikov

Bug#1069108: Another ruby 3.2 change

[javibarroso]

Hello,

I had to add:

require "ostruct"

so the next line works:
proxy_uri = $proxy_url.nil? ? OpenStruct.new : URI.parse($proxy_url)

Bug#956454: gmsh: Seems to depend on "mouse selection"

[Fabrice Silva]

Package: gmsh
Version: 4.12.2+ds1-1
Followup-For: Bug #956454

Dear Maintainer,
it seems that the spurious crash only occurs when "mouse selection" is
enabled (using the esc keybinding).
This may relate to the call to openglWindow::_select In the traceback
provided previously

#21 0x774bd136 in openglWindow::_select


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

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

Versions of packages gmsh depends on:
ii  libc6   2.37-18
ii  libgmsh4.12t64  4.12.2+ds1-1

Versions of packages gmsh recommends:
pn  gmsh-doc  

gmsh suggests no packages.

-- no debconf information

Bug#1070495: Should qbe be Architecture: amd64 arm64 riscv64 ?

[Helmut Grohne]

Hi,

On Mon, May 06, 2024 at 02:51:56PM +0300, Adrian Bunk wrote:
> Source: qbe
> Version: 1.2-1
> Severity: important
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=qbe=1.2-1
> 
> ...
>dh_auto_test -a
>   make -j8 check
> make[1]: Entering directory '/<>'
> tools/test.sh all
> abi1.ssa...  /tmp/qbe..s: Assembler 
> messages:
> /tmp/qbe..s:3: Error: unrecognized opcode: `pushq'
> /tmp/qbe..s:4: Error: unrecognized opcode: `movq'
> /tmp/qbe..s:5: Error: unrecognized opcode: `movq'
> /tmp/qbe..s:6: Error: unrecognized opcode: `addq'
> /tmp/qbe..s:8: Error: unrecognized opcode: `movb'
> /tmp/qbe..s:9: Error: unrecognized opcode: `movq'
> ...
> 50 of 50 tests failed!
> make[1]: *** [Makefile:72: check] Error 50
> 
> 
> 
> This is due to explicit support required for every architecture,
> and defaulting to amd64 otherwise:
> https://sources.debian.org/src/qbe/1.2-1/Makefile/#L44-L54
> 
> (The package also builds on m68k/sh4 in ports since these are
>  building with nocheck.)
> 
> An explicit
>   Architecture: amd64 arm64 riscv64
> might be a better option for such a package that needs
> a backend written for every architecture it supports?

You are conflating host architecture and target architecture here. The
compiler only targets three architectures at this time, but there is
little limitation in host architectures.

The test suite fails, because it performs the testing for a target
derived from the current host architecture (same conflation).

Unlike gcc and like llvm/clang, qbe is a multi-target compiler with
runtime selection of target architecture. Hence, the test suite should
be repeated for each supported target and for doing so it likely needs
to Build-Depends: qemu-user .

Helmut

Bug#1054080: stlcmd: stl_boolean segfaults on some inputs

[Bernhard Übelacker]

Hello,
I am not maintainer of stlcmd, just tried to collect some more information.

This crash seems to be a stack overflow because of a recursive function call.

There is a comment near that recursive call, which could be interesting here.
And this issue seems not to be a packaging issue in Debian, therefore it
might be better to report this issue upstream in [2].

Kind regards,
Bernhard

[1] 
https://github.com/AllwineDesigns/stl_cmd/blob/7c2582864df1c10d11f5acb4901fb04c55ea7492/src/csgjs/Trees.cpp#L44-L55
[2] https://github.com/AllwineDesigns/stl_cmd/issues


Core was generated by `stl_boolean -a one.stl -b intersection.stl -d 
one-additions.stl'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , 
bytes=bytes@entry=512) at malloc.c:3637
3637malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , 
bytes=bytes@entry=512) at malloc.c:3637
#1  0x7fe2a95c9de4 in __GI___libc_malloc (bytes=512) at malloc.c:3058
#2  0x7fe2a991c0b5 in operator new(unsigned long) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x56309140a744 in __gnu_cxx::new_allocator::allocate 
(this=, __n=) at 
/usr/include/c++/7/ext/new_allocator.h:111
#4  std::allocator_traits >::allocate 
(__a=..., __n=) at /usr/include/c++/7/bits/alloc_traits.h:436
#5  std::_Vector_base 
>::_M_allocate (this=0x210, this@entry=0x7fff7ccf8470, __n=) at 
/usr/include/c++/7/bits/stl_vector.h:172
#6  std::vector 
>::_M_realloc_insert (this=this@entry=0x7fff7ccf8470, 
__position=, __args#0=@0x7fff7ccf82a0: 
0x563093c75b00) at /usr/include/c++/7/bits/vector.tcc:406
#7  0x56309140a84b in std::vector >::emplace_back 
(this=this@entry=0x7fff7ccf8470, __args#0=@0x7fff7ccf82a0: 0x563093c75b00) at 
/usr/include/c++/7/bits/vector.tcc:105
#8  0x563091409a9a in std::vector >::push_back (__x=@0x7fff7ccf82a0: 
0x563093c75b00, this=0x7fff7ccf8470) at /usr/include/c++/7/bits/stl_vector.h:954
#9  csgjs::PolygonTreeNode::splitPolygonByPlane 
(this=this@entry=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of 
length 0, capacity 0, coplanarBackNodes=std::vector of length 32, capacity 32 = 
{...},  frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector 
of length 32, capacity 32 = {...}) at src/csgjs/Trees.cpp:298
#10 0x563091409d7c in csgjs::PolygonTreeNode::splitLeafByPlane 
(this=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of length 0, 
capacity 0,  coplanarBackNodes=std::vector of length 32, capacity 32 = {...}, 
frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector of length 
32, capacity 32 = {...}) at src/csgjs/Trees.cpp:239
#11 0x563091409f67 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390cc0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:40
#12 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390a50, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#13 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x5630963907e0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#14 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390570, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#15 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390300, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
...
#65433 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99510, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65434 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c994b0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65435 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99880, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65436 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99820, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65437 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c997c0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65438 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99720, polyTreeNodes=std::vector of length 113, 
capacity 128 = {...}) at src/csgjs/Trees.cpp:54
#65439 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c68e20, polyTreeNodes=std::vector of length 497, 
capacity 512 = {...}) at src/csgjs/Trees.cpp:54
#65440 0x563091409ff8 in 

Bug#758985: libsqlite3-0: Please support 'icu' and 'unicode61' tokenizers

[Mike Gabriel]

Control: severity -1 important
Control: tags -1 patch

Dear Laszlo,

On  Mo 06 Mai 2024 21:03:07 CEST, Debian Bug Tracking System wrote:


Source: libsqlite3-0
Severity: normal
Tags: l10n

Debian SQlite appears to be compiled without support for the 'icu' and
'unicode61' tokenizers:

   sqlite> CREATE VIRTUAL TABLE test1 USING fts4(tokenize=simple);
   sqlite> CREATE VIRTUAL TABLE test2 USING fts4(tokenize=porter);
   sqlite> CREATE VIRTUAL TABLE test3 USING fts4(tokenize=icu);
   Error: unknown tokenizer: icu
   sqlite> CREATE VIRTUAL TABLE test4 USING fts4(tokenize=unicode61);
   Error: unknown tokenizer: unicode61

'simple' and 'porter' tokenizers only really work for English, so this
is quite bad for localization.  'icu' is enabled through
SQLITE_ENABLE_ICU, and 'unicode61' should be available since SQlite
3.7.13 ...


Find attached a .debdiff patch that fixes bug #758985 by building  
sqlite3 with SQLITE_ENABLE_ICU.


I just uploaded an addressbook storage backend [1] for Lomiri's [2]  
address book app [3] to Debian's NEW queue which needs this fix (so I  
am creating some dramatizing tension by bumping this bug's severity to  
'important' ;-) ).


Please consider enabling the ICU extension and making sqlite3 i18n  
capable for languages using regional fonts etc. If this change is not  
acceptable, please also let me know.


Maybe it could be an approach to upload an ICU-enabled version of  
sqlite3 to experimental and ask people to test their  
services/applications with the new-featured sqlite3. I can help with  
communications if needed. Please let me know.


Thanks! Looking forward to seeing this addressed in short-term...
Mike


[1] https://ftp-master.debian.org/new/qtcontacts-sqlite_0.3.5-1.html
[2] https://lomiri.com
[3] https://gitlab.com/ubports/development/core/address-book-app
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net

diff -Nru sqlite3-3.45.3/debian/changelog sqlite3-3.45.3/debian/changelog
--- sqlite3-3.45.3/debian/changelog 2024-04-16 16:12:58.0 +
+++ sqlite3-3.45.3/debian/changelog 2024-05-06 16:42:20.0 +
@@ -1,3 +1,14 @@
+sqlite3 (3.45.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules:
++ Build with SQLITE_ENABLE_ICU=1.
++ Add  -licuuc -licui18n to LDFLAGS.
+  * debian/libsqlite3-0.symbol:
++ Update file (due to building with SQLITE_ENABLE_ICU=1).  
+
+ -- Mike Gabriel   Mon, 06 May 2024 18:42:20 +0200
+
 sqlite3 (3.45.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru sqlite3-3.45.3/debian/control sqlite3-3.45.3/debian/control
--- sqlite3-3.45.3/debian/control   2023-06-24 14:16:47.0 +
+++ sqlite3-3.45.3/debian/control   2024-05-06 15:39:48.0 +
@@ -2,7 +2,7 @@
 Section: devel
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
-Build-Depends: debhelper-compat (= 13), autoconf (>= 2.59), libtool (>= 
1.5.2), automake, chrpath, lynx, libreadline-dev, tcl8.6-dev
+Build-Depends: debhelper-compat (= 13), autoconf (>= 2.59), libtool (>= 
1.5.2), automake, chrpath, lynx, libreadline-dev, tcl8.6-dev, libicu-dev
 Build-Conflicts: tcl8.4, tcl8.4-dev, tcl8.5, tcl8.5-dev
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
diff -Nru sqlite3-3.45.3/debian/libsqlite3-0.symbols 
sqlite3-3.45.3/debian/libsqlite3-0.symbols
--- sqlite3-3.45.3/debian/libsqlite3-0.symbols  2024-04-16 16:12:58.0 
+
+++ sqlite3-3.45.3/debian/libsqlite3-0.symbols  2024-05-06 16:41:57.0 
+
@@ -364,6 +364,7 @@
  sqlite3Fts3HashFindElem@Base 3.37.0
  sqlite3Fts3HashInit@Base 3.37.0
  sqlite3Fts3HashInsert@Base 3.37.0
+ sqlite3Fts3IcuTokenizerModule@Base 3.45.3-1.1
  sqlite3Fts3Incrmerge@Base 3.37.0
  sqlite3Fts3Init@Base 3.37.0
  sqlite3Fts3InitAux@Base 3.37.0
@@ -439,6 +440,7 @@
  sqlite3HeapNearlyFull@Base 3.37.0
  sqlite3HexToBlob@Base 3.37.0
  sqlite3HexToInt@Base 3.37.0
+ sqlite3IcuInit@Base 3.45.3-1.1
  sqlite3IdListAppend@Base 3.37.0
  sqlite3IdListDelete@Base 3.37.0
  sqlite3IdListDup@Base 3.37.0
diff -Nru sqlite3-3.45.3/debian/rules sqlite3-3.45.3/debian/rules
--- sqlite3-3.45.3/debian/rules 2024-03-13 20:16:30.0 +
+++ sqlite3-3.45.3/debian/rules 2024-05-06 16:42:20.0 +
@@ -25,6 +25,10 @@
 export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
 export LDFLAGS += -Wl,--as-needed
+
+# Because we build with SQLITE_ENABLE_ICU
+LDFLAGS += -licuuc -licui18n
+
 ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
   confflags += --build $(DEB_HOST_GNU_TYPE) 
--with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl8.6
   export CROSS_BUILDING=no
@@ -50,6 +54,7 @@
-DSQLITE_ENABLE_UPDATE_DELETE_LIMIT=1 \
-DSQLITE_ENABLE_LOAD_EXTENSION \
-DSQLITE_ENABLE_JSON1 \
+   -DSQLITE_ENABLE_ICU \
-DSQLITE_LIKE_DOESNT_MATCH_BLOBS \
 

Bug#1070665: python-aiohttp: CVE-2024-27306

[Salvatore Bonaccorso]

Source: python-aiohttp
Version: 3.9.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/aio-libs/aiohttp/pull/8319
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-aiohttp.

CVE-2024-27306[0]:
| aiohttp is an asynchronous HTTP client/server framework for asyncio
| and Python. A XSS vulnerability exists on index pages for static
| file handling. This vulnerability is fixed in 3.9.4. We have always
| recommended using a reverse proxy server (e.g. nginx) for serving
| static files. Users following the recommendation are unaffected.
| Other users can disable `show_index` if unable to upgrade.


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-27306
https://www.cve.org/CVERecord?id=CVE-2024-27306
[1] https://github.com/aio-libs/aiohttp/pull/8319
[2] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-7gpw-8wmc-pm8g
[3] 
https://github.com/aio-libs/aiohttp/commit/28335525d1eac015a7e7584137678cbb6ff19397

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070664: emacs: Emacs 28.2: ELPA key expired

[inasprecali]

Package: emacs
Version: 1:28.2+1-15
Severity: important
X-Debbugs-Cc: inasprec...@disroot.org

Dear Maintainer,

The key for signing the GNU Emacs packages in the official GNU ELPA
archive has changed.  The key included in this GNU Emacs version has
expired.  This disables the download of the archive list as well as
any package from elpa.

In order to allow GNU ELPA packages to be downloaded again, the key
needs to be updated manually.  A possible solution is to run the
following ELisp snippet from within Emacs:

(let ((package-check-signature nil))
  (package-refresh-contents)
  (package-install 'gnu-elpa-keyring-update))

After restarting GNU Emacs, downloading and installing packages from
GNU ELPA works again.

If possible, they key included with the Emacs package itself should be
updated in order to avoid having to resort to similar workarounds.

Thank you for your attention.

-- 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-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 emacs depends on:
ii  emacs-gtk  1:28.2+1-15

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1057562: Forwarded upstream (Was: gcr4: FTBFS: failing tests)

[Andreas Tille]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gcr/-/issues/119
thanks

Hi,

this issue was reported upstream.  I would have pointed the issue to the
Debian BTS but for whatever reason my login is not accepted.  Santiago,
since you can provide VMs where the problem is reproducible which seems
to be a problem for the reporter of the issue, would you also offer such
a VM to gcr4 upstream?

If yes, it would be cool to add this info to their bug tracker.  In case
this might be a problem for you and nobody else has a valid login I try
to get a login tomorrow and will proxy this information.

Kind regards
   Andreas.

-- 
https://fam-tille.de

Bug#786808: ITA

[Serafeim Zanikolas]

I intend to adopt adequate and rewrite it in go. I've reached out to
former contributors and current stakeholders on their opinion about
that, and have not received any nacks yet (although I've only received a
couple of responses).


signature.asc
Description: PGP signature

Bug#1067106: bullseye-pu: package nvidia-settings/470.239.06-1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2024-05-06 at 20:29 +0200, Andreas Beckmann wrote:
> while accepting the nvidia stack yesterday (many thanks for that!)
> you missed to tag etc. this bug, while the package was accepted
> (perhaps attributed to a different bug?).

Yep, the metadata in the comment file had a typo in the bug number.
Fixed now, thanks.

Regards,

Adam

Bug#1070405: darktable: Please drop unused Build-Depends: libsoup2.4-dev

[Jeremy Bícha]

On Mon, May 6, 2024 at 2:46 PM David Bremner  wrote:
>
> Jeremy Bícha  writes:
>
> > Source: darktable
> > Version: 4.6.1-2
> >
> > Please drop Build-Depends: libsoup2.4-dev . It isn't used at all and
> > we would eventually like to remove libsoup2.4 from Debian.
> >
> > Thank you,
> > Jeremy Bícha
>
> How can I verify that it is not used?

rgrep -i soup

Also: https://github.com/darktable-org/darktable/commit/228fcf0041773

Thank you,
Jeremy Bícha

Bug#1070405: darktable: Please drop unused Build-Depends: libsoup2.4-dev

[David Bremner]

Jeremy Bícha  writes:

> Source: darktable
> Version: 4.6.1-2
>
> Please drop Build-Depends: libsoup2.4-dev . It isn't used at all and
> we would eventually like to remove libsoup2.4 from Debian.
>
> Thank you,
> Jeremy Bícha

How can I verify that it is not used?

d

Bug#1070663: Unable to lock an existing session

[martin f krafft]

Package: xautolock
Version: 1:2.2-8
Severity: critical

This may be related to #1022781 or not.

I have xautolock running:

% ps -fC xautolock
UID  PIDPPID  C STIME TTY  TIME CMD
madduck 27332421  0 May05 ?00:00:53 xautolock -time 3 -locker 
xsecurelock && autorandr -- …

and yet:

% xautolock -locknow
% echo $?
0

It exits 0, but nothing happens. If I use strace on the main 
process, there is also zero activity reported.

Moreover, despite being set to lock after 3 minutes, the main 
xautolock process does not lock the display.

This has happened multiple times, and each time, only a restart of 
the main xautolock process makes things work again. So if I don't 
restart the process regularly (daily? hourly?), then occasionally, 
the system will not lock as expected, and that is a huge security 
problem, hence the critical severity.

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

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

Versions of packages xautolock depends on:
ii  libc6 2.37-17
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxss1   1:1.2.3-1

Versions of packages xautolock recommends:
ii  suckless-tools  47-1

xautolock suggests no packages.

-- debconf-show failed


-- 
 .''`.   martin f. krafft 
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1070662: genx: please drop extraneous dependency on python3-mock

[Alexandre Detiste]

Source: genx
Version: 3.6.22-2
Severity: normal

Dear Maintainers,

This package is using the newer unittest.mock
from the standard library.

Greetings

tchet@quieter:/tmp/genx$ grep mock -r
debian/control: python3-mock,
tests/test_instrument.py:from unittest.mock import patch

Bug#1070661: python-os-testr: please re-remove python3-mock (again)

[Alexandre Detiste]

Source: python-os-testr
Version: 3.0.0-2
Severity: normal

Now it's really gone.

tchet@quieter:/tmp/python-os-testr$ grep mock -r
debian/changelog:  * Re-add python3-mock as build-depends (Closes: #973176).
debian/control: python3-mock,
os_testr/tests/test_subunit_trace.py:from unittest.mock import patch
tchet@quieter:/tmp/python-os-testr$ r

Bug#1067106: bullseye-pu: package nvidia-settings/470.239.06-1

[Andreas Beckmann]

Hi Adam,

while accepting the nvidia stack yesterday (many thanks for that!) you 
missed to tag etc. this bug, while the package was accepted (perhaps 
attributed to a different bug?).


Andreas

Bug#1070459: psortb: FTBFS: binding.c:52:13: error: implicit declaration of function ‘free’

[Andreas Tille]

Hi,

I've fixed the original error in Git but Salsa CI shows another one[1]
which is more tricky since it involves a header file for a perl module
and I have no idea how to fix this.  Any help from the team is welcome.

Kind regards
   Andreas.

[1] https://salsa.debian.org/med-team/psortb/-/jobs/5693162

-- 
https://fam-tille.de

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

[Daniel Gröber]

On Mon, May 06, 2024 at 02:10:53PM -0300, Lucas Castro wrote:
> >https://salsa.debian.org/debian/lsm
> 
> I'm already using gbp, on my own repository server
> 
> https://git.gnuabordo.com.br/foolsm.git/, I haven't created the salsa
> account yet.

Ah. You should have put that in the Vcs-{Git,Browse} headers for everyone
to find then :)

FYI: Vcs-Git also supports specifying a branch which may be useful in your
case if the repo's default HEAD isn't the debianization.

> > d/rules:
> > > DEBUG=true
> > I'm not sure how to feel about this. Do you have a reason for turning it
> > on? Seems the last upload had it commented out. From a quick codereivew it
> > does look to just add more logging, so it's probably fine?
> Ops, built upon wrong git branch. = ) I'm going upload a new package.

> > Looking at the generated maintainerscripts in the foolsm deb I don't see
> > anything related to dpkg-maintscript-helper, are you sure that's hooked up
> > right? Good job finding that obscurica BTW I didn't know about that myself
> > :)
> 
> Nope, the maintscript is right, should be ran just for lsm update, or
> somehow the lsm is installed but foolsm is available.

Brainfart I was just looking at the wrong package.

> The script will check if /etc/lsm/lsm.conf already exist, then it'll move
> the conf file.

Great. Just what I wanted.

> > I also noticed the upstream tarballs have started including a debian/
> > directory for a non-native packaging. Do you know what's up with that? I
> > could see why they would include it if they packaged it as a "native"
> > package but for non-native it just makes no sense. Could you talk to
> > upstream to figure out what's up with that? Feel free to CC me.
>
> My guess is they would try update the package because I had missed.

Perhaps. Would still be nice if they could remove it again. Please shoot
them a mail. It's always a good idea to keep in contact with upstream
anyway, even when it's just a "look we packaged your latest release, here's
some notes" thing.

Getting their stuff into a wideley deployed distro like Debian is positive
feedback for people doing the unthankful job of publishing free
software. We provide as much of that kind of feedback to our upstreams as
possible.

> > Just FYI: I'd appreciate git commits/patches on top of my repo above
> > instead of an updated dsc dump.
> 
> As I mentioned, I don't have a salsa account, I really would like to keep my
> own repository by now, maybe soon I'll create an account.

No, there's no need really. I can pull from your repo and push to salsa, no
problem. See for the sponsorship workflow (with git) to work well for any
random DD it's best if they already have access to the repo listed in
Vcs-Git (as is the case on salsa) since they are expected to push debian/*
tags and (possibly) d/changelog updates or minor fixes there.

You can keep your repo and just tell sponsors to pull from it by adding an
additional line to the usual sponsorship message. DDs can then decide
whether to use it or not. That's how I would do it anyway.

I'll base the debian/lsm repo on your repo's state then. I do have some
review notes though:

The branch naming is non-standard see [DEP-14]. Convention is debian/latest
(used to be debian/master) or debian/unstable (used to be debian/sid) for
the development branch. I haven't looked at that document in a while either
I guess since I still use debian/sid everywhere but they changed the
recommendation from debian/$codename to debian/$suite in 2020.

[DEP-14]: https://dep-team.pages.debian.net/deps/dep14/

Further you have a number of debian/* tags in your repo that don't exist in
the debian archive. That's not going to do. If you keep your own archive of
packages you should make use of the DEP-14 $vendor feature and have
branches/tags named, say gnuabordo/*.

Since you'd have to adjust d/gbp.conf for your repo's use with something
like

 [DEFAULT]
 debian-branch = gnuabordo/latest
 debian-tag = gnuabordo/%(version)s

and keep that on a separate branch from actual Debian packaging. Thats
obviously more work, so another way to go would be to just not tag your
internal uploads. That what I tend to do when I have something I want to
deply right away and don't feel like waiting on NEW review.

Might just be easier to apply to become DM for lsm and just not have so
much of a need for a local repo ;)

--Daniel


signature.asc
Description: PGP signature

Bug#1070646: rust-gst-plugin-gtk4: Please package GStreamer plugin .so as well for use by non-Rust applications

[Matthias Geiger]

On 06.05.24 16:54, Tim Müller wrote:

Source: rust-gst-plugin-gtk4
Version: 0.12.5-1
Severity: wishlist
X-Debbugs-Cc:werdah...@riseup.net,a...@sigxcpu.org

It would be great if there was also a stand-alone package with
the .so for the GStreamer Rust plugin(s) for use by normal/other
GStreamer applications.

Filing bug as discussed on IRC in #debian-rust with werdahias.

Many thanks for your work.

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

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


Pushed my wip so far to 
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/659.


Will try to get it into an acceptable state today but this is 
low-priority for me atm. Feel free to ping here in a month.


--
Matthias Geiger 
Debian Maintainer

Bug#1070660: bookworm-pu: package shim/15.8-1~deb12u1

[Steve McIntyre]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-...@lists.debian.org

This is a new upstream version of shim, built for bookworm. This is
needed for better handling of SBAT-based revocations, plus a range of
security updates from upstream.

See attached debdiff for the changes. They're not minimal, but in the
case of shim we need to be as close to upstream as possible for the
sake of getting stuff reviewed and signed. The only local patches to
the upstream source now are to force SBAT updates to revoke older
insecure grub binaries. There are some minor changes to packaging to
help with review, and to add some autopkgtest stuff.

I've tested locally using CI and also by hand on various machines and
all looks good here.

Obviously, once this is accepted and autobuilt I'll need to submit
things for review and signing elsewhere. Then we'll be want
shim-signed updting too.

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

shim (15.8-1~deb12u1) bookworm; urgency=medium

  [ Steve McIntyre ]
  * Cope with changes in pesign packaging.
  * New upstream release fixing more bugs
  * Remove all our previous patches, no longer needed:
+ Make-sbat_var.S-parse-right-with-buggy-gcc-binutils.patch (now
  upstream)
+ Enable-NX.patch (we don't want NX just yet until the whole boot
  stack is NX-capable)
+ block-grub-sbat3-debian.patch (not needed now upstream grub SBAT
  is 4)
  * Cherry-pick 2 new patches from upstream for grub revocations:
+ 0001-sbat-Add-grub.peimage-2-to-latest-CVE-2024-2312.patch
+ 0002-sbat-Also-bump-latest-for-grub-4-and-to-todays-date.patch
  * Log if the build is nx-compatible or not
  * Force shim to use the latest revocations by default to block some
older grub / peimage issues. This is:
"shim,4\ngrub,4\ngrub.peimage,2\n"
  * Install a copy of the Debian CA certificate into /usr/share/shim.
Closes: #1069054
  * Clean up better after build. Closes: #1046268

  [ Bastien Roucariès ]
  * Port autopkgtest from ubuntu
  * Import MR-12: "shim-unsigned:amd64 cannot be installed alongside
shim-unsigned:i386", thanks to adrian15 adrian15 (Closes: #936009).
  * Fix debian/watch and check signature


shim_15.8-1~deb12u1.debdiff.gz
Description: application/gzip

Bug#1070644: gnome-remote-desktop: System .service file enabled but not the user one?

[Jeremy Bícha]

Control: forwarded -1
https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/merge_requests/260

It looks like upstream is proposing to split gnome-remote-desktop's
new systemd systemd service into two system services to fix this
issue. It's unclear whether they will land this in 46.x

Thank you,
Jeremy Bícha

Bug#1064486: rnp: FTBFS: Errors while running CTest

[Andreas Metzler]

Control: tags -1 fixed-upstream

On 2024-05-05 Andreas Metzler  wrote:
> On 2024-05-04 Santiago Vila  wrote:
> > found 1064486 0.16.3-1
> > tags 1064486 + ftbfs bookworm trixie sid
> > thanks

> > El 20/4/24 a las 14:12, Andreas Metzler escribió:
> > > FWIW I also get testsuite errors on current sid on amd64
> > > The following tests FAILED:
> > >   83 - rnp_tests.test_ffi_decrypt_wrong_mpi_bits (Failed)
> > >   90 - rnp_tests.test_ffi_security_profile (Failed)
> > >  174 - rnp_tests.test_key_add_userid (Failed)
> > >  254 - cli_tests-EncryptElgamal (Failed)

> > Hello. This is also happening in bookworm, I assume that for the same 
> > underlying reason,
> > so I'm adding the bookworm version.
> [...]

> Hmm. Perhaps a timebomb, i.e. one of the keys used in the testsuite
> expired.


Hello,

Indeed it is a timebomb. Since 0.17.1 works I had a look at
git log src/tests/key-add-userid.cpp
and found

commit 07745e2e5fa6078b95fb5c24575929eb2a19ca03
Author: Nickolay Olshevsky 
Date:   Fri Jan 19 16:05:32 2024 +0200

Update tests to match SHA1 cutoff date for key signatures.
[...]
 selfsig0.primary = false;
+auto curtime = global_ctx.time();
+global_ctx.set_time(curtime > SHA1_KEY_FROM ? SHA1_KEY_FROM - 100 : 0);


SHA1_KEY_FROM is #defined in src/tests/support.h to 1705629600, which
was Fri Jan 19 03:00:00 CET 2024.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1070659: transition: re2

[Stefano Rivera]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: r...@packages.debian.org
Control: affects -1 + src:re2
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 with 1070649 1053409

It has taken a while to prepare the next re2 transition, because it
included a new dependency on abseil. This broke most of the
reverse-dependencies. It also means that transitions will get more
frequent, as every abseil transition will change re2's ABI.

I think the state of the reverse-dependencies is reasonable, now. I just
did a rebuild of them all, and got these failures:

yaramod FTBFS (#1037908):
https://debusine.debian.net/artifact/66513/yaramod_3.6.0-1.1_amd64-2024-05-06T14:59:09Z.build

clickhouse FTBFS (#1070658):
https://debusine.debian.net/artifact/66521/clickhouse_18.16.1+ds-7.4_amd64-2024-05-06T14:59:16Z.build

libvmod-re2 FTBFS Looks like a libre2-11 regression, but simple: #1070649:
https://debusine.debian.net/artifact/66531/libvmod-re2_2.0.0-2_amd64-2024-05-06T15:18:37Z.build

qtwebengine-opensource-src FTBFS libre2-11 regression, patch pending:
#1053409:
https://debusine.debian.net/artifact/66545/qtwebengine-opensource-src_5.15.15+dfsg-3_amd64-2024-05-06T15:31:32Z.build

Ben file:

title = "re2";
is_affected = .depends ~ "libre2-10" | .depends ~ "libre2-11";
is_good = .depends ~ "libre2-11";
is_bad = .depends ~ "libre2-10";

Stefano

Bug#1070658: FTBFS: error: expected ‘)’ before ‘maxLength’

[Stefano Rivera]

Source: clickhouse
Version: 18.16.1+ds-7.4
Severity: serious
Tags: ftbfs
Justification: ftbfs

clickhouse FTBFS in unstable:

[ 87%] Building CXX object 
dbms/CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o
cd /<>/obj-x86_64-linux-gnu/dbms && /usr/bin/c++ 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB 
-DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -Ddbms_EXPORTS 
-I/<>/contrib/cityhash102/include 
-I/<>/libs/libpocoext/include 
-I/<>/libs/libmysqlxx/include 
-I/<>/contrib/libbtrie/include -isystem 
/<>/contrib/libdivide -isystem /<>/dbms/src -isystem 
/<>/obj-x86_64-linux-gnu/dbms/src -isystem 
/<>/contrib/libpcg-random/include -isystem 
/<>/libs/libcommon/include -isystem 
/<>/obj-x86_64-linux-gnu/libs/libcommon/include -isystem 
/usr/include/metrohash -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2  -pipe  
-fno-omit-frame-pointer  -Wall  -Wnon-virtual-dtor -Wextra -O2 -g -DNDEBUG -O3  
-std=c++17 -flto=auto -fno-fat-lto-objects -fPIC   
-fno-tree-loop-distribute-patterns -MD -MT 
dbms/CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o -MF 
CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o.d -o 
CMakeFiles/dbms.dir/src/Storages/MergeTree/LevelMergeSelector.cpp.o -c 
/<>/dbms/src/Storages/MergeTree/LevelMergeSelector.cpp
In file included from 
/<>/dbms/src/Interpreters/InterserverIOHandler.h:8,
 from 
/<>/dbms/src/Storages/MergeTree/DataPartsExchange.h:3,
 from 
/<>/dbms/src/Storages/MergeTree/DataPartsExchange.cpp:1:
/usr/include/Poco/BinaryWriter.h:137:14: error: expected ‘)’ before ‘maxLength’
  137 | void writeCString(const char* cString, std::streamsize 
maxLength = DEFAULT_MAX_CSTR_LENGTH);
  |  ^~~~
/usr/include/Poco/BinaryWriter.h:137:14: note: to match this ‘(’
  137 | void writeCString(const char* cString, std::streamsize 
maxLength = DEFAULT_MAX_CSTR_LENGTH);
  |  ^~~~

Full build log:
https://debusine.debian.net/artifact/66597/clickhouse_18.16.1+ds-7.4_amd64-2024-05-06T16:48:46Z.build

Stefano

Bug#1070490: libc6: Unpacking libc6:amd64 2.28-10+deb10u3 over 2.28-10+deb10u2 breaks system

[Adrian Bunk]

On Mon, May 06, 2024 at 05:37:37PM +0100, Adam D. Barratt wrote:
> On Mon, 2024-05-06 at 13:02 +0200, Jan Krčmář wrote:
> > Package: libc6
> > Version: 2.28-10+deb10u3
> > 
> > Upgrading the system (Debian 10/Buster) causes corrupted system,
> > ending with kernel panic and unbootable system.
> > 
> [...]
> > The following packages will be upgraded:
> > apt apt-transport-https apt-utils base-files ca-certificates 
> 
> The fact that APT is being upgraded here seems strange - APT hasn't
> changed in buster for 3 years. What's your base system?

There's also
> > Unpacking base-files (10.3+deb10u13) over (10.3+deb10u5) ...

That's outdated since September 2020.

> > Unpacking libc6:amd64 (2.28-10+deb10u3) over (2.28-10+deb10u2) ...
> > Replaced by files in installed package libcrypt1:amd64 (1:4.4.18-4)
> > ...
> 
> This, on the other hand, looks like you've done something odd to your
> system. libcrypt1 doesn't exist until bullseye, so at some point you
> have partially upgraded your base system. In conjunction with your pre-
> upgrade system apparently having an APT version that's /older/ than the
> one in buster, this feels odd.

There is related nastiness with partial upgrades from buster to 
bullseye, see the last two items at [1].

I am not sure whether it is the root cause here, but it's at least 
plausible that not being able to have the Breaks in libcrypt1 causes 
problems for such partially upgraded systems.

> Regards,
> 
> Adam

cu
Adrian

[1] 
https://tracker.debian.org/news/1239066/accepted-libxcrypt-14418-3-source-into-unstable/

Bug#1066449: mpi4py: FTBFS: Segmentation fault in tests

[Drew Parsons]

Source: mpi4py
Followup-For: Bug #1066449
Control: tags -1 ftbfs

The bug report stopped scanning at the first "error", which is not an
error (it's a check).  The last error is the relevant one

testIReadIWrite (test_io.TestIOSelf.testIReadIWrite) ... ok
testIReadIWriteAll (test_io.TestIOSelf.testIReadIWriteAll) ... 
[ip-10-84-234-105:152676] *** Process received signal ***
[ip-10-84-234-105:152676] Signal: Segmentation fault (11)
[ip-10-84-234-105:152676] Signal code: Address not mapped (1)
[ip-10-84-234-105:152676] Failing at address: (nil)
[ip-10-84-234-105:152676] [ 0] 
/lib/x86_64-linux-gnu/libc.so.6(+0x3c510)[0x7f7a3a86f510]
[ip-10-84-234-105:152676] *** End of error message ***
Segmentation fault


Possibly a transitory inconsistency caught in the middle of an openmpi update.

Bug#1070490: libc6: Unpacking libc6:amd64 2.28-10+deb10u3 over 2.28-10+deb10u2 breaks system

[Adam D. Barratt]

On Mon, 2024-05-06 at 13:02 +0200, Jan Krčmář wrote:
> Package: libc6
> Version: 2.28-10+deb10u3
> 
> Upgrading the system (Debian 10/Buster) causes corrupted system,
> ending with kernel panic and unbootable system.
> 
[...]
> The following packages will be upgraded:
> apt apt-transport-https apt-utils base-files ca-certificates 

The fact that APT is being upgraded here seems strange - APT hasn't
changed in buster for 3 years. What's your base system?

> 
[...]
> Unpacking libc6:amd64 (2.28-10+deb10u3) over (2.28-10+deb10u2) ...
> Replaced by files in installed package libcrypt1:amd64 (1:4.4.18-4)
> ...

This, on the other hand, looks like you've done something odd to your
system. libcrypt1 doesn't exist until bullseye, so at some point you
have partially upgraded your base system. In conjunction with your pre-
upgrade system apparently having an APT version that's /older/ than the
one in buster, this feels odd.

Regards,

Adam

Bug#1068122: /usr/bin/firefox: clings to USB stick, Debian 12.5 up-to-date, Xfce

[Max Nikulin]

On Thu, 18 Apr 2024 20:31:45 +0300 Antti-Pekka Känsälä wrote:


so I don't expect anything further.


Please, consider closing this bug by sending response to
1068122-d...@bugs.debian.org

Accordingly to https://www.debian.org/Bugs/Developer


Normally, the only people that should close a bug report are the
submitter of the bug and the maintainer(s) of the package against which
the bug is filed.

Bug#1070657: RFS: c-evo-dh/1.12-1 -- Empire Building Game, C-evo Distant Horizon

[Peter Blackman]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "c-evo-dh":

 * Package name : c-evo-dh
   Version  : 1.12-1
   Upstream contact : Peter 
 * URL  : https://sourceforge.net/projects/c-evo-eh/
 * License  : CC-BY-3.0, CC-BY-SA-3.0-US, GPL-2+, CC0-1.0
 * Vcs  : https://salsa.debian.org/PeterB/c-evo-dh
   Section  : games

The source builds the following binary packages:

  c-evo-dh-gtk2  - Empire Building Game (GTK2), C-evo: Distant Horizon
  c-evo-dh-stdai - Empire Building Game (AI module), C-evo: Distant Horizon
  c-evo-dh-data  - Empire Building Game (data files), C-evo: Distant 
Horizon


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

  https://mentors.debian.net/package/c-evo-dh/

Alternatively, you can download the package with 'dget' using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/c/c-evo-dh/c-evo-dh_1.12-1.dsc


Changes since the last upload:

 c-evo-dh (1.12-1) unstable; urgency=medium
 .
   * New Upstream Release
   * Update d/copyright
   * Use mpg123 for sound (Closes: #1067844)
   * Standards now 4.7.0 (No changes)
   * Override 32bit shared library warnings
   * Use git tags instead of tarball in d/watch

Regards,
 Peter Blackman

Bug#1070656: RM: tirex [armel armhf i386] -- ROM; libapache-mod-tile dependency only available on 64-bit architectures

[Bas Couwenberg]

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

Please remove tirex from the 32-bit architectures where its libapache2-mod-tile 
(runtime) dependency is no longer available (#1066977).

Kind Regards,

Bas

Bug#1070654: xfsprogs: Build with PAC/BTI support on arm64

[Emanuele Rocca]

Source: xfsprogs
Version: 6.6.0-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: pac-bti

Hi,

Pointer Authentication (PAC) and Branch Target Identification (BTI) are
two security features available on arm64. [1]

Please consider building xfsprogs with PAC/BTI support turned on, see
attached patch.

Thanks,
  Emanuele

[1] https://wiki.debian.org/ToolChain/PACBTI

diff -Nru xfsprogs-6.5.0/debian/rules xfsprogs-6.5.0/debian/rules
--- xfsprogs-6.5.0/debian/rules 2023-08-15 21:15:28.0 +0200
+++ xfsprogs-6.5.0/debian/rules 2024-02-12 15:51:07.0 +0100
@@ -27,6 +27,10 @@
 pkgdi  = DIST_ROOT=`pwd`/$(dirdi); export DIST_ROOT;
 stdenv = @GZIP=-q; export GZIP;
 
+ifeq ($(DEB_TARGET_ARCH),arm64)
+   CFLAGS = -mbranch-protection=standard
+endif
+
 configure_options = \
--build=$(DEB_BUILD_GNU_TYPE) \
--with-multiarch=$(DEB_HOST_MULTIARCH) \
@@ -37,7 +41,7 @@
--enable-lto
 
 options = export DEBUG=-DNDEBUG DISTRIBUTION=debian \
- INSTALL_USER=root INSTALL_GROUP=root LDFLAGS='$(LDFLAGS)' \
+ INSTALL_USER=root INSTALL_GROUP=root CFLAGS='$(CFLAGS)' 
LDFLAGS='$(LDFLAGS)' \
  LOCAL_CONFIGURE_OPTIONS="$(configure_options) --enable-editline=yes 
--enable-blkid=yes" ;
 diopts  = $(options) \
  export OPTIMIZER=-Os LOCAL_CONFIGURE_OPTIONS="$(configure_options) 
--enable-gettext=no" ;

Bug#1018874: etckeeper noisy when using bzr/brz

[Mitchell Dzurick]

Hi, any activity on this bug? I also made a MR for your consideration at
https://salsa.debian.org/debian/etckeeper/-/merge_requests/3

Thanks,
-Mitch

Bug#1070653: cdparanoia: Please build with hardening flags

[Emanuele Rocca]

Source: cdparanoia
Version: 3.10.2+debian-14
Tags: patch
User: debian-...@lists.debian.org
Usertags: pac-bti

Dear Maintainer,

Whilst trying to figure out why a rebuild of cdparanoia on arm64 does
not fully enable BTI [1] I have noticed that the program is built
without hardening flags on. Please consider the attached patch.

Thanks,
  Emanuele

[1] https://wiki.debian.org/ToolChain/PACBTI
diff -Nru cdparanoia-3.10.2+debian/debian/changelog 
cdparanoia-3.10.2+debian/debian/changelog
--- cdparanoia-3.10.2+debian/debian/changelog   2021-03-13 05:58:25.0 
+0100
+++ cdparanoia-3.10.2+debian/debian/changelog   2024-02-28 10:55:16.0 
+0100
@@ -1,3 +1,10 @@
+cdparanoia (3.10.2+debian-15) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with hardening flags, except for format.
+
+ -- Emanuele Rocca   Mon, 06 May 2024 17:42:04 +0200
+
 cdparanoia (3.10.2+debian-14) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru cdparanoia-3.10.2+debian/debian/rules 
cdparanoia-3.10.2+debian/debian/rules
--- cdparanoia-3.10.2+debian/debian/rules   2021-03-13 05:58:25.0 
+0100
+++ cdparanoia-3.10.2+debian/debian/rules   2024-02-28 10:55:16.0 
+0100
@@ -1,5 +1,10 @@
 #!/usr/bin/make -f
 
+# cdparanoia FTBFS with -Werror=format-security 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-format
+
+include /usr/share/dpkg/buildflags.mk
+
 export CFLAGS += -fPIC -g
 export LDFLAGS += -fPIC
 

Bug#1070651: apg: fix setting CFLAGS and LDFLAGS

[Emanuele Rocca]

Source: apg
Version: 2.2.3.dfsg.1-5
Tags: patch
User: debian-...@lists.debian.org
Usertags: pac-bti

Hallo Marc,

whilst trying to figure out why a rebuild of apg on arm64 does not
enable BTI [1] I noticed that there is an issue with the way the
upstream Makefile sets CFLAGS and LDFLAGS. Please see the attached
patch.

Thanks,
  Emanuele

[1] https://wiki.debian.org/ToolChain/PACBTI
diff -Nru apg-2.2.3.dfsg.1/debian/changelog apg-2.2.3.dfsg.1/debian/changelog
--- apg-2.2.3.dfsg.1/debian/changelog   2017-10-02 00:19:40.0 +0200
+++ apg-2.2.3.dfsg.1/debian/changelog   2024-02-13 11:43:54.0 +0100
@@ -1,3 +1,11 @@
+apg (2.2.3.dfsg.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix dpkg-buildflags invocation in debian/patches/Makefile to properly set
+CFLAGS and LDFLAGS.
+
+ -- Emanuele Rocca   Mon, 06 May 2024 17:40:04 +0200
+
 apg (2.2.3.dfsg.1-5) unstable; urgency=low
 
   * add warning to package description about FIPS 181 deprecation.
diff -Nru apg-2.2.3.dfsg.1/debian/patches/Makefile 
apg-2.2.3.dfsg.1/debian/patches/Makefile
--- apg-2.2.3.dfsg.1/debian/patches/Makefile2017-10-02 00:19:40.0 
+0200
+++ apg-2.2.3.dfsg.1/debian/patches/Makefile2024-02-13 11:43:54.0 
+0100
@@ -5,14 +5,16 @@
  add dpkg-buildflags for hardening
 Origin: vendor
 Forwarded: not-needed
 a/Makefile
-+++ b/Makefile
+Index: apg-2.2.3.dfsg.1/Makefile
+===
+--- apg-2.2.3.dfsg.1.orig/Makefile
 apg-2.2.3.dfsg.1/Makefile
 @@ -6,7 +6,7 @@ CC = gcc
  ##
  # Compilation flags
  # You should comment the line below for AIX+native cc
 -FLAGS = -Wall
-+FLAGS = -Wall `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get LDFLAGS`
++FLAGS = -Wall $(shell dpkg-buildflags --get CFLAGS) $(shell dpkg-buildflags 
--get LDFLAGS)
  
  ##
  # Libraries

Bug#1070652: ruby-json: breaks how-can-i-help

[Vincent Lefevre]

Package: ruby-json
Version: 2.7.2+dfsg-1
Severity: grave
Justification: renders package unusable

This new ruby-json version breaks how-can-i-help:

[...]
Unpacking ruby-json:amd64 (2.7.2+dfsg-1) over (2.6.3+dfsg-1+b2) ...
Setting up ruby-json:amd64 (2.7.2+dfsg-1) ...
/usr/bin/how-can-i-help:155:in `': uninitialized constant OpenStruct 
(NameError)

proxy_uri = $proxy_url.nil? ? OpenStruct.new : URI.parse($proxy_url)
  ^^

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

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

Versions of packages ruby-json depends on:
ii  libc6  2.38-7
ii  libruby1:3.1+nmu1
ii  libruby3.1t64  3.1.2-8.3

ruby-json recommends no packages.

ruby-json suggests no packages.

-- no debconf information

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

Bug#1070644: gnome-remote-desktop: System .service file enabled but not the user one?

[Jeremy Bícha]

Control: severity -1 serious

On Mon, May 6, 2024 at 11:03 AM Laurent Bigonville  wrote:
>
> Package: gnome-remote-desktop
> Version: 46.1-3
> Severity: normal
>
> Hello,
>
> It seems that the system systemd .service is enabled at boot, while the
> user one is not.
>
> Any reason why the former is enabled and the later is not?
>
> Not sure I see the rational here

That could be a critical bug so I'm bumping the severity. I think the
service ought not run unless it is enabled and it shouldn't be enabled
by default. (There is GUI in gnome-control-center to enable it but
that GUI is patched out for Unstable.)

Thank you,
Jeremy Bícha

Bug#1070041: waybar: wireplumber support disabled in 0.10.2-1

[Dylan Aïssi]

Hello,

On Mon, 29 Apr 2024 11:01:52 +0200 =?UTF-8?B?RHlsYW4gQcOvc3Np?= 
 wrote:

>
> Currently, wireplumber 0.5 is only available in experimental waiting 
for his

> transition slot.

wireplumber 0.5 was uploaded to unstable today.

Best regards,
Dylan

Bug#1070650: linux-image-6.7.7-amd64: Updates needed for 2024 Platform support - graphics, wifi, CPU, audio

[Mark Pearson]

Package: src:linux
Version: 6.7.7-1
Severity: important
X-Debbugs-Cc: mpearson-len...@squebb.ca

I realise this bug is overly broad, but testing Debian on the 2024 platforms 
and updated kernel is needed for a better user experience

 - Meteorlake support is a bit limited before 6.8. Need updated kernel for 
graphic, audio, power support.
 - Intel AX211 driver is in newer kernel.
 - AMD graphics drivers have seen significant improvements in 6.8

This also links to #1070647 and #1070648 where FW updates are required.

Very happy to help if any tested needed. I've had users trying to run Debian on 
their systems and would like to be able to help them get up and runninng.

Note - kernel logs below are with updated FW that I manually installed myself. 
Without these I don't have functional graphics of wifi :)

Thanks
Mark

-- Package-specific info:
** Version:
Linux version 6.7.7-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-16.1) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.7.7-1 (2024-03-02)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.7.7-amd64 
root=UUID=864f906b-6c9a-49b9-bdbe-78e4b4a88d9d ro quiet

** Not tainted

** Kernel log:
[5.157952] cryptd: max_cpu_qlen set to 1000
[5.164733] ACPI Warning: \_SB.PC00.XHCI.RHUB.HS10._DSM: Argument #4 type 
mismatch - Found [Integer], ACPI requires [Package] (20230628/nsarguments-61)
[5.165165] Bluetooth: hci0: DSM reset method type: 0x00
[5.165836] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, 
REV=0x441
[5.165896] thermal thermal_zone8: failed to read out thermal zone (-61)
[5.169658] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-0180-0041.sfi
[5.174253] Bluetooth: hci0: Found device firmware: intel/ibt-0180-0041.sfi
[5.174303] Bluetooth: hci0: Boot Address: 0x100800
[5.174304] Bluetooth: hci0: Firmware Version: 132-8.24
[5.176650] AVX2 version of gcm_enc/dec engaged.
[5.176706] AES CTR mode by8 optimization enabled
[5.177586] iwlwifi :00:14.3: WRT: Invalid buffer destination
[5.183424] sof-audio-pci-intel-mtl :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040380
[5.184986] sof-audio-pci-intel-mtl :00:1f.3: Digital mics found on 
Skylake+ platform, using SOF driver
[5.185540] sof-audio-pci-intel-mtl :00:1f.3: DSP detected with PCI 
class/subclass/prog-if 0x040380
[5.185595] sof-audio-pci-intel-mtl :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[5.192677] sof-audio-pci-intel-mtl :00:1f.3: use msi interrupt mode
[5.239977] typec port0: bound usb1-port3 (ops connector_ops [usbcore])
[5.240002] typec port0: bound usb4-port1 (ops connector_ops [usbcore])
[5.254026] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[5.254028] Bluetooth: BNEP filters: protocol multicast
[5.254032] Bluetooth: BNEP socket layer initialized
[5.258126] Btrfs loaded, zoned=yes, fsverity=yes
[5.273296] sof-audio-pci-intel-mtl :00:1f.3: hda codecs found, mask 5
[5.273298] sof-audio-pci-intel-mtl :00:1f.3: using HDA machine driver 
skl_hda_dsp_generic now
[5.273301] sof-audio-pci-intel-mtl :00:1f.3: DMICs detected in NHLT 
tables: 2
[5.274536] sof-audio-pci-intel-mtl :00:1f.3: firmware: direct-loading 
firmware intel/sof-ipc4/mtl/sof-mtl.ri
[5.274976] sof-audio-pci-intel-mtl :00:1f.3: Loaded firmware library: 
ADSPFW, version: 2.8.1.1
[5.342774] iwlwifi :00:14.3: Not valid error log pointer 0x0027B0C0 for 
RT uCode
[5.342847] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x1f
[5.342866] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[5.342873] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x80
[5.342882] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0
[5.343634] iwlwifi :00:14.3: RFIm is deactivated, reason = 4
[5.343711] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-ma-b0-gf-a0.pnvm
[5.343796] iwlwifi :00:14.3: loaded PNVM version ce1a5094
[5.353058] NET: Registered PF_QIPCRTR protocol family
[5.359195] iwlwifi :00:14.3: Detected RF GF, rfid=0x2010d000
[5.382188] sof-audio-pci-intel-mtl :00:1f.3: Booted firmware version: 
2.8.1.1
[5.389778] sof-audio-pci-intel-mtl :00:1f.3: firmware: direct-loading 
firmware intel/sof-ace-tplg/sof-hda-generic-2ch.tplg
[5.389812] sof-audio-pci-intel-mtl :00:1f.3: Topology: ABI 3:29:0 
Kernel ABI 3:23:0
[5.389997] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: Parent card not 
yet available, widget card binding deferred
[5.413768] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC287: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[5.413772] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[5.413773] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[5.413774] snd_hda_codec_realtek ehdaudio0D0:

Bug#1070649: libvmod-re2: FTBFS with libre2-11 (experimental)

[Stefano Rivera]

Source: libvmod-re2
Version: 2.0.0-2
Severity: important
Tags: ftbfs
Control: affects -1 src:re2

libvmod-re2 fails to build with re2 from experimental:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/varnish -Wall -Werror -Wextra -std=c99 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -pthread -fstack-protector -c 
vmod_re2.c  -fPIC -DPIC -o .libs/vmod_re2.o
In file included from /usr/include/absl/base/config.h:86,
 from /usr/include/absl/base/internal/invoke.h:40,
 from /usr/include/absl/base/call_once.h:34,
 from /usr/include/re2/re2.h:222,
 from vre2/vre2set.h:43,
 from vre2/vre2set.cpp:34:
/usr/include/absl/base/policy_checks.h:79:2: error: #error "C++ versions less 
than C++14 are not supported."

Full build log: 
https://debusine.debian.net/artifact/66531/libvmod-re2_2.0.0-2_amd64-2024-05-06T15:18:37Z.build

It looks like it needs to set a higher C++ std version.

Stefano

Bug#1070648: firmware-iwlwifi: Update needed for Intel AX211 Wifi support

[Mark Pearson]

Package: firmware-iwlwifi
Version: 20230625-2
Severity: important
X-Debbugs-Cc: mpearson-len...@squebb.ca

I've been testing Debian on the new Lenovo Meteorlake based platforms with 
AX211 Intel wifi, and seeing lots of problems related to out of date kernel and 
firmware support.

This bug is being raised to specifically track getting the iwlwifi firmware 
packages updated

Please let me know how I can help. Happy to do any testing, and I have some 
limited experience with packaging from maintaining the firmware-sof-signed 
packag>

Thanks
Mark



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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1033462: KMail: Sending emails fails via Gmail due to OAuth 2.0 Scopes

[Sedat Dilek]

Hi,

Unfortunately, I had no big success with playing with Google's OAuth Scopes.

But I found another solution ...

Gmail-Account > Data & Privacy > Apps and services > Third party apps
and services > Akonadi Service For Google Services

... I was able to send emails again via KMail.

[ INFO ]
Akonadi Resources for Google Services has some access to your Google Account

To use some Akonadi Resources for Google Services features, you gave
Akonadi Resources for Google Services some access to your Google
Account.
This access might include sensitive info

[ See your profile info ]
See your primary Google Account email address
Associate you with your personal info on Google

[ Read, compose, send, and permanently delete all your email from
Gmail ] <--- so-called "Scopes"
This app wants permission to do anything you can do in your Gmail, including:
Read your emails
Compose new emails
Add new emails meant for a different email address into your inbox
Send emails for you
Delete your email
Create, change or delete your email labels
Get notified when certain kinds of emails appear in your Gmail inbox,
like a travel confirmation

Your email may contain sensitive info, like names of your contacts,
your private communications, or financial or medical information

[ CONCLUSION ]
Unsure, if this was a clever/smart decision?

BR,
-Sedat-

Bug#1070647: firmware-misc-nonfree: Update needed to support Meteorlake graphics

[Mark Pearson]

Package: firmware-misc-nonfree
Version: 20230625-2
Severity: important
X-Debbugs-Cc: mpearson-len...@squebb.ca

I've been testing Debian on the new Lenovo Meteorlake based platforms and 
seeing lots of problems related to out of date kernel and firmware support.

This bug is being raised to specifically track getting the graphics firmware 
packages updated - /lib/firmware/i915

Please let me know how I can help. Happy to do any testing, and I have some 
limited experience with packaging from maintaining the firmware-sof-signed 
packag>

As a note - iwlwifi and kernel itself need updating too, but I will do separate 
bugs for those
Thanks
Mark

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

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

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1070646: rust-gst-plugin-gtk4: Please package GStreamer plugin .so as well for use by non-Rust applications

[Tim Müller]

Source: rust-gst-plugin-gtk4
Version: 0.12.5-1
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net, a...@sigxcpu.org

It would be great if there was also a stand-alone package with
the .so for the GStreamer Rust plugin(s) for use by normal/other
GStreamer applications.

Filing bug as discussed on IRC in #debian-rust with werdahias.

Many thanks for your work.

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

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

Bug#1070645: libavif: Please remove dependency on libgav1 on big-endian architectures

[John David Anglin]

Source: libavif
Version: 1.0.4-2
Severity: normal
Tags: ftbfs

Dear Maintainer,

libgav1 is broken on big-endian targets.  See this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068583

As a result, libavif no longer builds on hppa and other big-endian
architectures which depend on libgav1.

This blocks building glibc:
https://buildd.debian.org/status/package.php?p=glibc=sid

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.90+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1070644: gnome-remote-desktop: System .service file enabled but not the user one?

[Laurent Bigonville]

Package: gnome-remote-desktop
Version: 46.1-3
Severity: normal

Hello,

It seems that the system systemd .service is enabled at boot, while the
user one is not.

Any reason why the former is enabled and the later is not?

Not sure I see the rational here

Kind regards,
Laurent Bigonville

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

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

Versions of packages gnome-remote-desktop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  fuse33.14.0-5
ii  init-system-helpers  1.66
ii  libc62.38-7
ii  libcairo21.18.0-3+b1
ii  libei1   1.2.1-1
ii  libepoxy01.5.10-1+b2
ii  libfreerdp-server3-3 3.5.1+dfsg1-3
ii  libfreerdp3-33.5.1+dfsg1-3
ii  libfuse3-3   3.14.0-5
ii  libglib2.0-0t64  2.80.0-9
ii  libmutter-14-0   46.1-2
ii  libnotify4   0.8.3-1+b1
ii  libopus0 1.4-1+b1
ii  libpipewire-0.3-0t64 1.0.5-1+b3
ii  libpolkit-gobject-1-0124-2
ii  libsecret-1-00.21.4-1+b1
ii  libsystemd0  255.5-1
ii  libtss2-esys-3.0.2-0t64  4.0.1-7.2
ii  libtss2-mu-4.0.1-0t644.0.1-7.2
ii  libtss2-rc0t64   4.0.1-7.2
ii  libtss2-tctildr0t64  4.0.1-7.2
ii  libwinpr3-3  3.5.1+dfsg1-3
ii  libxkbcommon01.6.0-1+b1
ii  pipewire 1.0.5-1+b3
ii  systemd [systemd-sysusers]   255.5-1
ii  wireplumber  0.4.17-1+b2

gnome-remote-desktop recommends no packages.

gnome-remote-desktop suggests no packages.

-- no debconf information

Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs

[Thorsten Glaser]

Dixi quod…
>Dmitry Shachnev dixit:
>>Now that you dug so deeply, maybe you can try to replace qRound in those
>>three lines that you mentioned with TO_TTF, and check if it fixes the bug
>
>That *and* figure out somehow how to fix the PDF /FontBBox, at
>least… (though I binary-patched the hhea ascender in the PDF and
>it made Atril happy, so it “should”, despite the still-wrong OS/2
>table values some of which are notably used in clipping by some
>softwares…)

Yes, that worked. I’m attaching the final patch in entirety again
for your convenience.

>I’m trying this (attached). That does both (by letting toTruetype()
>adjust the already-existing scaling factor in the caller) and
>applies suitable rounding (normal for normal values, away from zero
>for the bounding box so it’s guaranteed to encompass all possible
>values). I’ll build it now so I don’t know if it even compiles yet…

It still does not address the OS/2 table, but it does manage to
fix both the PDF-side and font-side hhea table metrics, which is
enough for Atril at least. (Not sure whether it’s enough for my
gf’s printer, I’ll have to test. Or extend the patch to fix the
OS/2 table as well, which I probably should anyway; I have to find
the time for that sometime within the next few days.)

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.miscDescription: scale /FontBBox and hhea table when scaling fonts
 for embedding (the OS/2 table needs handling XXX TODO)
Author: mirabilos 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406

--- a/src/gui/painting/qpdf.cpp
+++ b/src/gui/painting/qpdf.cpp
@@ -1870,11 +1870,20 @@ void QPdfEnginePrivate::writeAttachmentR
 "endobj\n");
 }
 
+static inline int roundForBbox(qreal v)
+{
+return (v < 0) ? floor(v) : ceil(v);
+}
+
 void QPdfEnginePrivate::embedFont(QFontSubset *font)
 {
+QFontEngine::Properties properties = font->fontEngine->properties();
+QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
+qreal scale = 1000/properties.emSquare.toReal();
+
 //qDebug() << "embedFont" << font->object_id;
 int fontObject = font->object_id;
-QByteArray fontData = font->toTruetype();
+QByteArray fontData = font->toTruetype();
 #ifdef FONT_DUMP
 static int i = 0;
 QString fileName("font%1.ttf");
@@ -1891,11 +1900,7 @@ void QPdfEnginePrivate::embedFont(QFontS
 int toUnicode = requestObject();
 int cidset = requestObject();
 
-QFontEngine::Properties properties = font->fontEngine->properties();
-QByteArray postscriptName = properties.postscriptName.replace(' ', '_');
-
 {
-qreal scale = 1000/properties.emSquare.toReal();
 addXrefEntry(fontDescriptor);
 QByteArray descriptor;
 QPdf::ByteStream s();
@@ -1909,15 +1914,15 @@ void QPdfEnginePrivate::embedFont(QFontS
 s <<  '+' << postscriptName << "\n"
 "/Flags " << 4 << "\n"
 "/FontBBox ["
-  << properties.boundingBox.x()*scale
-  << -(properties.boundingBox.y() + 
properties.boundingBox.height())*scale
-  << (properties.boundingBox.x() + 
properties.boundingBox.width())*scale
-  << -properties.boundingBox.y()*scale  << "]\n"
+  << roundForBbox(properties.boundingBox.x()*scale)
+  << roundForBbox(-(properties.boundingBox.y() + 
properties.boundingBox.height())*scale)
+  << roundForBbox((properties.boundingBox.x() + 
properties.boundingBox.width())*scale)
+  << roundForBbox(-properties.boundingBox.y()*scale)  << "]\n"
 "/ItalicAngle " << properties.italicAngle.toReal() << "\n"
-"/Ascent " << properties.ascent.toReal()*scale << "\n"
-"/Descent " << -properties.descent.toReal()*scale << "\n"
-"/CapHeight " << properties.capHeight.toReal()*scale << "\n"
-"/StemV " << properties.lineWidth.toReal()*scale << "\n"
+"/Ascent " << qRound(properties.ascent.toReal()*scale) << "\n"
+"/Descent " << qRound(-properties.descent.toReal()*scale) << "\n"
+"/CapHeight " << qRound(properties.capHeight.toReal()*scale) << 
"\n"
+"/StemV " << qRound(properties.lineWidth.toReal()*scale) << "\n"
 "/FontFile2 " << fontstream << "0 R\n"
 "/CIDSet " << cidset << "0 R\n"
 ">>\nendobj\n";
--- a/src/gui/text/qfontsubset.cpp
+++ b/src/gui/text/qfontsubset.cpp
@@ -1162,13 +1162,14 @@ static QByteArray bindFont(const QVector
   if really required.
 */
 
-QByteArray QFontSubset::toTruetype() const
+QByteArray QFontSubset::toTruetype(qreal *scalep) const
 {
 qttf_font_tables font;
 memset(, 0, sizeof(qttf_font_tables));
 
 qreal ppem = fontEngine->fontDef.pixelSize;
 #define TO_TTF(x) qRound(x * 2048. / ppem)
+*scalep *= 

Bug#1070643: ITP: libhdrhistogram -- High Dynamic Range (HDR) Histogram library

[Micke Nordin]

Package: wnpp
Severity: wishlist
Owner: Micke Nordin 
X-Debbugs-Cc: debian-de...@lists.debian.org, k...@sunet.se

* Package name: libhdrhistogram
  Version : 0.11.8
* URL : https://github.com/HdrHistogram/HdrHistogram_c
* License : CC0-1.0 or BSD-2-clause
  Programming Lang: C
  Description : High Dynamic Range (HDR) Histogram library

 This C-based implementation of a High Dynamic Range (HDR) Histogram
 contains a subset of the functionality supported by the Java implementation.
 The current supported features are:
Standard histogram with 64 bit counts (32/16 bit counts not supported)
All iterator types (all values, recorded, percentiles, linear, logarithmic)
Histogram serialisation (encoding version 1.2, decoding 1.0-1.2)
Reader/writer phaser and interval recorder
  Features not supported, but planned
Auto-resizing of histograms
  Features unlikely to be implemented
Double histograms
Atomic/Concurrent histograms
16/32 bit histograms

  This package is needed by Debian Redict Maintainers
   so that we can devendor it from the
  redict package

Bug#1070642: RM: qflow/experimental -- ROM; depends on RMed graywolf,berkeley-abc

[Daniel Gröber]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: qf...@packages.debian.org, gayw...@packages.debian.org, 
d...@darkboxed.org
Control: affects -1 + src:qflow


Hi,

I've requested removal of bekerley-abc and rdeps from unstable
previously in Bug#1069032, but forgot about experimental (thanks
Andreas Beckmann for the reminder).

Please also remove qflow from experimental. Rationale is the same as
before, please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069032

Thanks,
--Daniel

Bug#1069032: RM: berkeley-abc (+ qflow and graywolf) -- ROM; replaced by yosys-abc

[Daniel Gröber]

Hi Andreas,

On Thu, May 02, 2024 at 09:33:20AM +0200, Andreas Beckmann wrote:
> should qflow/experimental be removed as well?

Right, I forgot about experimental. Thanks for the reminder.

> (please file a new RM bug in case you opt for removal)

Will do, thanks,
--Daniel


signature.asc
Description: PGP signature

Bug#1006889: frr / bgp failing to insert routes on boot (usually ipv6, sometimes ipv4)

[Nick]

Hi David,

No problem at all!  To be honest, I’d completely forgotten about this.

I was only setting up a test network for learning, and if what you say about 
interfaces bouncing is true then you are right not to mess with the systemd 
scripts.  If I try this again in future, I’ll go for loopback interfaces as you 
suggest.

Keep up the good work!

Kind regards,

Nick

> On 6 May 2024, at 15:16, David Lamparter  wrote:
> 
> Hi Nick,
> 
> 
> (first of all, sorry, I kinda blanked out this bug report for some time,
> see below for why)
> 
> On Mon, Mar 07, 2022 at 06:16:03PM +, Nick wrote:
> [...]
>>   Because of the above, I checked out 
>>   /etc/systemd/system/multi-user.target.wants/frr.service and found
>>   that it is set to start with 'After=network-pre.target'.  I replaced
>>   Wants= and After= with 'network-online.target' and removed Before=
>>   entirely.
>> 
>>   * What was the outcome of this action?
>> 
>>   Having modified the systemd start script, routes are always inserted
>>   on boot!
> [...]
> 
> The problem with this is that while this fixes your specific scenario,
> it also breaks other users' setups since network-online.target itself is
> on occasion made to depend on frr.service, which would now create a
> loop.
> 
> Further, the issue you're seeing is specific to your configuration with
> these two route-maps:
> 
> [...]
>> route-map RM_SET_SRC permit 10
>> set src 25.0.1.1
>> !
>> route-map RM_SET_SRC6 permit 10
>> set src :f0a1::1
> [...]
> 
> You're correct to observe that these require the interface that owns
> these IP addresses to be up and configured before they can take effect,
> and the kernel will reject them otherwise.  zebra's behavior on this
> is... call it "suboptimal" in not retrying the install;  however the
> behavior of FRR is designed against a limitation of "normal" policy
> setups.  route-maps, especially in zebra, are essentially code, and
> there are *lots* of possibilities to create edge cases or non-working
> setups.
> 
> In your specific setup, the "FRR recommended practice" would be: add
> both of these IP addresses (25.0.1.1 and XYZ:f0a1::1) as /32 / /128 to
> your loopback interface.  This will ensure they are always available.
> (This is generally recommended for a router's primary addresses.)
> 
> Alternatively, your fix in editing the dependency is also viable,
> assuming you don't need to deal with cases where the interface or
> addresses go away and come back.  I can't incorporate it into the
> package though because it is specific to your situation.
> 
> 
> Sorry, I'm not sure there is anything else I can do here,
> 
> 
> equi (David)

Bug#1070638: kde-spectacle: Build-depends on NBS libkcolorpicker-dev

[Scott Kitterman]

On Mon, 06 May 2024 10:33:54 -0400 Scott Kitterman  
wrote:
> Source: kde-spectacle
> Version: 22.12.3-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the 
past)
> 
> Once kcolorpicker is decrufted, this package will FTBFS.  Please update
> your build-depends.

Also libkimageannotator-dev needs updating.

Scott K

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

Bug#1070640: symfony: FTBFS with phpunit 11: PHP Fatal error: Trait "PHPUnit\Framework\TestListenerDefaultImplementation" not found in /<>/build/Symfony/Bridge/PhpUnit/Legacy/SymfonyTest

[Athos Ribeiro]

Source: symfony
Version: 6.4.6+dfsg-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: phpunit11

Hi,

phpunit 11 is out and is now available in experimental. During a test rebuild,
symfony was found to fail to build with this new phpunit version.

To reproduce this locally, you need to install phpunit from experimental on an
unstable system or build chroot.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> mkdir --parents vendor build
> cp -r src/Symfony build
> rm -r build/Symfony/Contracts
> cp debian/autoload_runtime.php vendor
> phpab --output vendor/autoload.php \
>   --whitelist '*\\tests\\*' \
>   --tolerant \
>   --template debian/autoload.php.tests.tpl \
>   --blacklist 
> 'symfony\\component\\dependencyinjection\\tests\\fixtures\\container\\projectservicecontainer'
>  \
>   --exclude 
> 'build/Symfony/Bridge/Doctrine/Tests/Fixtures/DoctrineLoaderEmbed.php' \
>   --exclude 
> 'build/Symfony/Bridge/Doctrine/Tests/Fixtures/DoctrineLoaderEntity.php' \
>   --exclude 
> 'build/Symfony/Bridge/Doctrine/Tests/Fixtures/EmbeddedIdentifierEntity.php' \
>   --exclude 
> 'build/Symfony/Bridge/Doctrine/Tests/PropertyInfo/Fixtures/DoctrineWithEmbedded.php'
>  \
>   --exclude 
> 'build/Symfony/Bridge/ProxyManager/Tests/LazyProxy/PhpDumper/Fixtures/proxy-implem.php'
>  \
>   --exclude 
> 'build/Symfony/Component/DependencyInjection/Tests/Fixtures/php/*' \
>   --exclude 
> 'build/Symfony/Component/Messenger/Tests/Exception/HandlerFailedExceptionTest.php'
>  \
>   --exclude 
> 'build/Symfony/Component/Routing/Tests/Fixtures/AttributesFixtures/*' \
>   build/Symfony
> phpab %development% - Copyright (C) 2009 - 2024 by Arne Blankerts and 
> Contributors
> 
> Scanning directory build/Symfony
> 
> Autoload file vendor/autoload.php generated.
> 
> ln -s /usr/share/php/AsyncAws build
> ln -s /usr/share/php/Cache build
> ln -s /usr/share/php/Composer build
> ln -s /usr/share/php/Cron build
> ln -s /usr/share/php/Doctrine build
> ln -s /usr/share/php/Egulias build
> ln -s /usr/share/php/GuzzleHttp build
> ln -s /usr/share/php/Http build
> ln -s /usr/share/php/League build
> ln -s /usr/share/php/Masterminds build
> ln -s /usr/share/php/Monolog build
> ln -s /usr/share/php/Nyholm build
> ln -s /usr/share/php/Pheanstalk build
> ln -s /usr/share/php/phpDocumentor build
> ln -s /usr/share/php/PHPStan build
> ln -s /usr/share/php/PHPUnit build
> ln -s /usr/share/php/Predis build
> ln -s /usr/share/php/ProxyManager build
> ln -s /usr/share/php/Psr build
> ln -s /usr/share/php/Symfony/Contracts build/Symfony
> ln -s /usr/share/php/Symfony/Component/Mercure build/Symfony/Component
> ln -s /usr/share/php/Symfony/Component/Security/Acl 
> build/Symfony/Component/Security
> ln -s /usr/share/php/Symfony/Polyfill build/Symfony
> ln -s /usr/share/php/Twig build
> ln -s build/Symfony .
> # Actual tests suite
> components=$(find build/Symfony -mindepth 3 -maxdepth 4 -type f -name 
> phpunit.xml.dist -printf '%h\n') && \
>  echo "$components" | parallel --gnu --keep-order '/bin/echo -e "\\nRunning 
> {} tests"; SYMFONY_DEPRECATIONS_HELPER=weak php -d assert.exception=1 -d 
> zend.assertions=1 /usr/bin/phpunit --include build --colors=always 
> --exclude-group jwt,network,tty,benchmark,intl-data,functional,composer {} || 
> (/bin/echo -e "\\e[41mKO\\e[0m {}" && $(exit 1));';
> 
> Running build/Symfony/Component/Mailer tests
> KO build/Symfony/Component/Mailer
> PHP Fatal error:  Trait "PHPUnit\Framework\TestListenerDefaultImplementation" 
> not found in 
> /<>/build/Symfony/Bridge/PhpUnit/Legacy/SymfonyTestsListenerForV7.php
>  on line 26
> 
> Running build/Symfony/Component/Cache tests
> KO build/Symfony/Component/Cache
> PHP Fatal error:  Trait "PHPUnit\Framework\TestListenerDefaultImplementation" 
> not found in 
> /<>/build/Symfony/Bridge/PhpUnit/Legacy/SymfonyTestsListenerForV7.php
>  on line 26
> 
> Running build/Symfony/Component/HttpKernel tests
> KO build/Symfony/Component/HttpKernel
> PHP Fatal error:  Trait "PHPUnit\Framework\TestListenerDefaultImplementation" 
> not found in 
> /<>/build/Symfony/Bridge/PhpUnit/Legacy/SymfonyTestsListenerForV7.php
>  on line 26
> 
> Running build/Symfony/Component/Finder tests
> KO build/Symfony/Component/Finder
> PHP Fatal error:  Trait "PHPUnit\Framework\TestListenerDefaultImplementation" 
> not found in 
> /<>/build/Symfony/Bridge/PhpUnit/Legacy/SymfonyTestsListenerForV7.php
>  on line 26
> 
> Running build/Symfony/Component/DependencyInjection tests
> KO build/Symfony/Component/DependencyInjection
> PHP Fatal error:  Trait "PHPUnit\Framework\TestListenerDefaultImplementation" 
> not found in 
> /<>/build/Symfony/Bridge/PhpUnit/Legacy/SymfonyTestsListenerForV7.php
>  on line 26
> 
> Running build/Symfony/Component/ErrorHandler tests
> KO build/Symfony/Component/ErrorHandler
> PHP Fatal error:  Trait 

Bug#1070641: twig-i18n-extension: FTBFS with phpunit 11: There were 12 PHPUnit errors

[Athos Ribeiro]

Source: twig-i18n-extension
Version: 4.1.1-1
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: phpunit11

Hi,

phpunit 11 is out and is now available in experimental. During a test rebuild,
twig-i18n-extension was found to fail to build with this new phpunit version.

To reproduce this locally, you need to install phpunit from experimental on an
unstable system or build chroot.

Relevant part (hopefully):
> There were 12 PHPUnit errors:
> 
> 1) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorDebugTest::testIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorDebugTest::testIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorDebugTest::getTests()
>  is not static
> 
> /<>/test/I18nExtensionMoTranslatorDebugTest.php:80
> 
> 2) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorDebugTest::testLegacyIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorDebugTest::testLegacyIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorDebugTest::getLegacyTests()
>  is not static
> 
> /<>/test/I18nExtensionMoTranslatorDebugTest.php:90
> 
> 3) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorSandboxTest::testIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorSandboxTest::testIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorSandboxTest::getTests()
>  is not static
> 
> /<>/test/I18nExtensionMoTranslatorSandboxTest.php:80
> 
> 4) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorSandboxTest::testLegacyIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorSandboxTest::testLegacyIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorSandboxTest::getLegacyTests()
>  is not static
> 
> /<>/test/I18nExtensionMoTranslatorSandboxTest.php:90
> 
> 5) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorTest::testIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorTest::testIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorTest::getTests()
>  is not static
> 
> /<>/test/I18nExtensionMoTranslatorTest.php:80
> 
> 6) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorTest::testLegacyIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorTest::testLegacyIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionMoTranslatorTest::getLegacyTests()
>  is not static
> 
> /<>/test/I18nExtensionMoTranslatorTest.php:90
> 
> 7) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionSandboxTest::testIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionSandboxTest::testIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionSandboxTest::getTests() is 
> not static
> 
> /<>/test/I18nExtensionSandboxTest.php:80
> 
> 8) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionSandboxTest::testLegacyIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionSandboxTest::testLegacyIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionSandboxTest::getLegacyTests()
>  is not static
> 
> /<>/test/I18nExtensionSandboxTest.php:90
> 
> 9) PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionTest::testIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionTest::testIntegration is 
> invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionTest::getTests() is not 
> static
> 
> /<>/test/I18nExtensionTest.php:80
> 
> 10) 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionTest::testLegacyIntegration
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionTest::testLegacyIntegration
>  is invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\I18nExtensionTest::getLegacyTests() is 
> not static
> 
> /<>/test/I18nExtensionTest.php:90
> 
> 11) PhpMyAdmin\Tests\Twig\Extensions\Node\MoTranslatorTransTest::testCompile
> The data provider specified for 
> PhpMyAdmin\Tests\Twig\Extensions\Node\MoTranslatorTransTest::testCompile is 
> invalid
> Data Provider method 
> PhpMyAdmin\Tests\Twig\Extensions\Node\MoTranslatorTransTest::getTests() is 
> not static
> 
> /<>/test/Node/MoTranslatorTransTest.php:27
> 
> 12) 

Bug#1070639: shaarli: FTBFS with phpunit 11: There were 11 PHPUnit errors

[Athos Ribeiro]

Source: shaarli
Version: 0.13.0+dfsg-3
Severity: normal
Justification: FTBFS
Tags: trixie sid ftbfs
User: pkg-php-p...@lists.alioth.debian.org
Usertags: phpunit11

Hi,

phpunit 11 is out and is now available in experimental. During a test rebuild,
shaarli was found to fail to build with this new phpunit version.

To reproduce this locally, you need to install phpunit from experimental on an
unstable system or build chroot.

Relevant part (hopefully):
> There were 11 PHPUnit errors:
> 
> 1) 
> Shaarli\Front\Controller\Admin\ShaareManageControllerTest\PinBookmarkTest::testPinBookmarkIsStickyNull
> The data provider specified for 
> Shaarli\Front\Controller\Admin\ShaareManageControllerTest\PinBookmarkTest::testPinBookmarkIsStickyNull
>  is invalid
> Data Provider method 
> Shaarli\Front\Controller\Admin\ShaareManageControllerTest\PinBookmarkTest::initialStickyValuesProvider()
>  is not static
> 
> /<>/tests/front/controller/admin/ShaareManageControllerTest/PinBookmarkTest.php:37
> 
> 2) Shaarli\Helper\DailyPageHelperTest::testExtractRequestedType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testExtractRequestedType is invalid
> Data Provider method Shaarli\Helper\DailyPageHelperTest::getRequestedTypes() 
> is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:19
> 
> 3) Shaarli\Helper\DailyPageHelperTest::testExtractRequestedDateTime
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testExtractRequestedDateTime is invalid
> Data Provider method 
> Shaarli\Helper\DailyPageHelperTest::getRequestedDateTimes() is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:34
> 
> 4) Shaarli\Helper\DailyPageHelperTest::testGetFormatByType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGetFormatByType is invalid
> Data Provider method Shaarli\Helper\DailyPageHelperTest::getFormatsByType() 
> is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:57
> 
> 5) Shaarli\Helper\DailyPageHelperTest::testGetStartDatesByType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGetStartDatesByType is invalid
> Data Provider method 
> Shaarli\Helper\DailyPageHelperTest::getStartDatesByType() is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:75
> 
> 6) Shaarli\Helper\DailyPageHelperTest::testGetEndDatesByType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGetEndDatesByType is invalid
> Data Provider method Shaarli\Helper\DailyPageHelperTest::getEndDatesByType() 
> is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:96
> 
> 7) Shaarli\Helper\DailyPageHelperTest::testGeDescriptionsByType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGeDescriptionsByType is invalid
> Data Provider method 
> Shaarli\Helper\DailyPageHelperTest::getDescriptionsByType() is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:117
> 
> 8) 
> Shaarli\Helper\DailyPageHelperTest::testGeDescriptionsByTypeNotIncludeRelative
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGeDescriptionsByTypeNotIncludeRelative
>  is invalid
> Data Provider method 
> Shaarli\Helper\DailyPageHelperTest::getDescriptionsByTypeNotIncludeRelative() 
> is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:130
> 
> 9) Shaarli\Helper\DailyPageHelperTest::testGeRssLengthsByType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGeRssLengthsByType is invalid
> Data Provider method 
> Shaarli\Helper\DailyPageHelperTest::getRssLengthsByType() is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:151
> 
> 10) Shaarli\Helper\DailyPageHelperTest::testGetCacheDatePeriodByType
> The data provider specified for 
> Shaarli\Helper\DailyPageHelperTest::testGetCacheDatePeriodByType is invalid
> Data Provider method 
> Shaarli\Helper\DailyPageHelperTest::getCacheDatePeriodByType() is not static
> 
> /<>/tests/helper/DailyPageHelperTest.php:169
> 
> 11) Shaarli\Legacy\LegacyControllerTest::testProcess
> The data provider specified for 
> Shaarli\Legacy\LegacyControllerTest::testProcess is invalid
> Data Provider method 
> Shaarli\Legacy\LegacyControllerTest::getProcessProvider() is not static
> 
> /<>/tests/legacy/LegacyControllerTest.php:29
> 
> --
> 
> There was 1 PHPUnit test runner warning:
> 
> 1) Class PluginReadItLaterTest cannot be found in 
> /<>/tests/plugins/PluginReadItLaterTest.php
> 
> --
> 
...
> 
> There were 27 errors:
> 
> 1) 
> Shaarli\Front\Controller\Admin\ManageTagControllerTest::testSaveRenameTagValid
> Error: Call to undefined method 
> PHPUnit\Framework\MockObject\Builder\InvocationMocker::withConsecutive()
> 
> /<>/tests/front/controller/admin/ManageTagControllerTest.php:114
> /usr/bin/phpunit:104
> 
> 2) 
> Shaarli\Front\Controller\Admin\ManageTagControllerTest::testSaveDeleteTagValid
> Error: Call to undefined method 
> PHPUnit\Framework\MockObject\Builder\InvocationMocker::withConsecutive()
> 
>