date:20230426


Control: tags -1 moreinfo

Hi Andreas,

On 20-04-2023 19:16, Andreas Beckmann wrote:

Looks like I forgot to merge the -fvisibility=hidden changes from
src:spirv-llvm-translator-14 (and the corresponding removal of 4500+
useless C++ symbols from the .symbols file) into
src:spirv-llvm-translator-15. Just noticed while preparing -16 for
experimental.


I'm a bit paranoid and not very well versed on C++ symbols. Can you 
please summarize (or point to a short explanation elsewhere on the 
internet) why they are useless and can be safely *removed*? In other 
words, why is it not possible that something already uses those symbols? 
(I recall rra had a good explanation why symbol files were rather 
useless for C++, but from memory that feels not exactly the same)


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034639: unblock: spamassassin/4.0.0-5


Control: tags -1 confirmed moreinfo

Hi Noah.

On 20-04-2023 18:22, Noah Meyerhans wrote:

This is a targeted change that addresses #1034347,


Please go ahead and remove the moreinfo tag once the upload happened.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034634: unblock: freetype/2.12.1+dfsg-5


Control: tags -1 confirmed moreinfo

On 20-04-2023 13:47, Hugh McMaster wrote:

An integer overflow vulnerability was discovered in FreeType (specifically, the
tt_hvadvance_adjust() function). This is CVE-2023-2004.


Please go ahead and remove the moreinfo tag once the package has been 
uploaded.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1


Control: tags -1 confirmed moreinfo
Control: retitle -1 unblock: isc-dhcp/4.4.3-P1-2

On 18-04-2023 14:11, Santiago R.R. wrote:

2. This is the autopkgtest included in this request applied to the
current version in testing:


Minor question: I *think* you are configuring the test to use the 
internet (nameserver 8.8.8.8). If that's true, please add the 
`needs-internet` restriction. (Or maybe it doesn't need to be configured 
like that.



unblock isc-dhcp/4.4.3-P1-1.1


That version is already in testing. I have fixed the title too (which, 
for next time, could have done with the word `pre-approval` or similar).


Anyways, please go ahead.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034881: falcosecurity-scap-dkms: Cannot compile linux kernel 6.2.12 due to failure with scap dkms

2023-04-26 Thread Dima Kogan

Hi. Thanks for the report. Debian is currently in a freeze while the
bookworm release is being prepared. bookworm is unaffected (it ships
with linux 6.1). I will look at this after the release is out (in a few
months probably).

Bug#1034898: unblock: speech-dispatcher-contrib/0.11.4-3

2023-04-26 Thread Samuel Thibault

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: speech-dispatcher-cont...@packages.debian.org
Control: affects -1 + src:speech-dispatcher-contrib

Hello,

I have uploaded speech-dispatcher-contrib 0.11.4-3 to unstable, for
inclusion in bookworm.

[ Reason ]
As detailed in Bug#1034897, there is a missing breaks+replace between
the speech-dispatcher-ivona package and the speech-dispatcher package.
What happened is that /etc/speech-dispatcher/modules/ivona.conf was
moved from the latter to the former in version 0.10.2-3, but adding
breaks replaces was missed.

[ Impact ]
The impact is not that high since speech-dispatcher-ivona didn't exist
in bullseye, so provided that the user first upgrades the
speech-dispatcher package to the bookworm version, before attempting to
install speech-dispatcher-ivona, things will go fine (and no package
depends on speech-dispatcher-ivona so it cannot come through an
upgrade).

But if the user tries to install speech-dispatcher-ivona from bookworm
on a bullseye system, the conflict will hit dpkg:

| dpkg: error processing archive speech-dispatcher-ivona_0.11.4-1_amd64.deb 
(--unpack):
|  trying to overwrite '/etc/speech-dispatcher/modules/ivona.conf', which is 
also in package speech-dispatcher 0.10.2-2+deb11u2

[ Tests ]
This was tested by hand by installing
speech-dispatcher-ivona_0.11.4-1_amd64.deb on a bullseye system with
speech-dispatcher installed.

[ Risks ]
The code is very trivial.

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

Thanks!

unblock speech-dispatcher-contrib/0.11.4-3
diff -Nru speech-dispatcher-contrib-0.11.4/debian/changelog 
speech-dispatcher-contrib-0.11.4/debian/changelog
--- speech-dispatcher-contrib-0.11.4/debian/changelog   2022-10-30 
23:06:55.0 +0100
+++ speech-dispatcher-contrib-0.11.4/debian/changelog   2023-04-27 
01:08:20.0 +0200
@@ -1,3 +1,11 @@
+speech-dispatcher-contrib (0.11.4-3) unstable; urgency=medium
+
+  * control: Add missing breaks+replaces between speech-dispatcher-ivona and
+speech-dispatcher, missed when moving ivona.conf from the latter to the
+former (Closes: Bug#1034897)
+
+ -- Samuel Thibault   Thu, 27 Apr 2023 01:08:20 +0200
+
 speech-dispatcher-contrib (0.11.4-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru speech-dispatcher-contrib-0.11.4/debian/control 
speech-dispatcher-contrib-0.11.4/debian/control
--- speech-dispatcher-contrib-0.11.4/debian/control 2022-10-30 
23:06:55.0 +0100
+++ speech-dispatcher-contrib-0.11.4/debian/control 2023-04-27 
01:08:20.0 +0200
@@ -176,6 +176,8 @@
  ${misc:Depends},
  speech-dispatcher (>= ${source:Upstream-Version}),
  speech-dispatcher (<< ${source:Upstream-Version}.0~)
+Breaks: speech-dispatcher (<< 0.10.2-3)
+Replaces: speech-dispatcher (<< 0.10.2-3)
 Description: Speech Dispatcher: Ivona output module
  Speech Dispatcher provides a device independent layer for speech synthesis.
  It supports various software and hardware speech synthesizers as

Bug#1032868: sendxmpp: Stopped working after dist-upgrade to bookworm

2023-04-26 Thread Markus Gschwendt

same issue here after upgrade bullseye -> bookworm

Debian bookworm

My XMPP-server is running ejabberd 23.01-1~bpo11+1

echo 'test' | sendxmpp -t -a /etc/ssl/certs/ -u  -j
 -p  -s "test1" 

gives same output as OP posted.

from apt history:
2023-04-04 dist-upgrade
libnet-xmpp-perl:amd64 (1.05-1, 1.05-1.1)
libxml2:amd64 (2.9.4+dfsg1-7+deb10u5, 2.9.10+dfsg-6.7+deb11u3)
2023-04-10  15:07:07
libnet-xmpp-perl:amd64 (1.05-1.1, 1.05-2)
2023-04-24
libxml2:amd64 (2.9.14+dfsg-1.1+b3, 2.9.14+dfsg-1.2)

markus

Bug#1034897: speech-dispatcher-ivona: missing Breaks + Replaces on speech-dispatcher

Package: speech-dispatcher-ivona
Version: 0.11.4-1
Severity: serious

Attempting to unpack speech-dispatcher-ivona from bookworm on a bullseye
system with speech-dispatcher can cause an error:

| Selecting previously unselected package speech-dispatcher-ivona.
| (Reading database ... 7758 files and directories currently installed.)
| Preparing to unpack speech-dispatcher-ivona_0.11.4-1_amd64.deb ...
| Unpacking speech-dispatcher-ivona (0.11.4-1) ...
| dpkg: error processing archive speech-dispatcher-ivona_0.11.4-1_amd64.deb 
(--unpack):
|  trying to overwrite '/etc/speech-dispatcher/modules/ivona.conf', which is 
also in package speech-dispatcher 0.10.2-2+deb11u2
| Errors were encountered while processing:
|  speech-dispatcher-ivona_0.11.4-1_amd64.deb

As such, speech-dispatcher-ivona must declare Breaks and Replaces for
speech-dispatcher with a suitable version.

Helmut

Bug#1034896: libadasockets12-dev: missing Breaks and Replaces for libadasockets10-dev

Package: libadasockets12-dev
Version: 1.12-2
Severity: serious

Attempting to unpack libadasockets12-dev from bookworm on a bullseye
system with libadasockets10-dev installed can cause an error:

| Selecting previously unselected package libadasockets12-dev.
| (Reading database ... 11106 files and directories currently installed.)
| Preparing to unpack .../libadasockets12-dev_1.12-7_amd64.deb ...
| Unpacking libadasockets12-dev (1.12-7) ...
| dpkg: error processing archive ./libadasockets12-dev_1.12-7_amd64.deb 
(--unpack):
|  trying to overwrite '/usr/bin/adasockets-config', which is also in package 
libadasockets10-dev 1.12-2
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
| Errors were encountered while processing:
|  ./libadasockets12-dev_1.12-7_amd64.deb

To avoid this situation, libadasockets12-dev must declare Breaks and
Replaces for libadasockets10-dev with a suitable version.

Helmut

Bug#1034895: pcp-zeroconf: missing Replaces: pcp (<< ?)

Package: pcp-zeroconf
Version: 6.0.3-1
Severity: serious

Unpacking pcp-zeroconf from bookworm on a stable system with pcp
installed fails:

| dpkg: considering deconfiguration of pcp, which would be broken by 
installation of pcp-zeroconf ...
| dpkg: yes, will deconfigure pcp (broken by pcp-zeroconf)
| (Reading database ... 10139 files and directories currently installed.)
| Preparing to unpack pcp-zeroconf_6.0.3-1_amd64.deb ...
| De-configuring pcp (5.2.6-1) ...
| invoke-rc.d: could not determine current runlevel
| All runlevel operations denied by policy
| invoke-rc.d: policy-rc.d denied execution of stop.
| invoke-rc.d: could not determine current runlevel
| All runlevel operations denied by policy
| invoke-rc.d: policy-rc.d denied execution of stop.
| invoke-rc.d: could not determine current runlevel
| All runlevel operations denied by policy
| invoke-rc.d: policy-rc.d denied execution of stop.
| invoke-rc.d: could not determine current runlevel
| All runlevel operations denied by policy
| invoke-rc.d: policy-rc.d denied execution of stop.
| Unpacking pcp-zeroconf (6.0.3-1) ...
| dpkg: error processing archive pcp-zeroconf_6.0.3-1_amd64.deb (--unpack):
|  trying to overwrite '/etc/pcp/pmieconf/zeroconf/all_threads', which is also 
in package pcp 5.2.6-1
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
| invoke-rc.d: could not determine current runlevel
| All runlevel operations denied by policy
| invoke-rc.d: policy-rc.d denied execution of start.
| invoke-rc.d: could not determine current runlevel
| All runlevel operations denied by policy
| invoke-rc.d: policy-rc.d denied execution of start.
| Errors were encountered while processing:
|  pcp-zeroconf_6.0.3-1_amd64.deb

Due to shipping /etc/pcp/pmieconf/zeroconf/all_threads in both
pcp-zeroconf/bookworm and pcp/bullseye, pcp-zeroconf must declare
Replaces: pcp (<< someversion) in addition to the existing Breaks.

Helmut

Bug#1034894: missing Breaks+Replaces: liblxqt0

Package: liblxqt-backlight-helper
Version: 1.2.0-5
Severity: serious

Trying to unpack liblxqt-backlight-helper in a bullseye chroot yields
this:

| Preparing to unpack .../liblxqt-backlight-helper_1.2.0-5_amd64.deb ...
| Unpacking liblxqt-backlight-helper (1.2.0-5) ...
| dpkg: error processing archive ./liblxqt-backlight-helper_1.2.0-5_amd64.deb 
(--unpack):
|  trying to overwrite '/usr/bin/lxqt-backlight_backend', which is also in 
package liblxqt0 0.16.0-1
| Errors were encountered while processing:
|  ./liblxqt-backlight-helper_1.2.0-5_amd64.deb

This situation should be prevented by adding suitable Breaks and
Replaces.

Helmut

Bug#1034893: openboard crash when paste with mouse click right in a textbox

2023-04-26 Thread lebardix

Package: openboard
Version: 1.5.4+dfsg1-2+deb11u1
Severity: important
X-Debbugs-Cc: lebar...@ogm-techno.org

Dear Maintainer,


* This bug is described on the github site
https://github.com/OpenBoard-org/OpenBoard/issues/479
it also affects version 1.6.1 provided in the bullseye backport packages

* only copy/paste from the keyboard works


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

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

Versions of packages openboard depends on:
ii  libavcodec58  7:4.3.5-0+deb11u1
ii  libavformat58 7:4.3.5-0+deb11u1
ii  libavutil56   7:4.3.5-0+deb11u1
ii  libc6 2.31-13+deb11u6
ii  libgcc-s1 10.2.1-6
ii  libgomp1  10.2.1-6
ii  libpoppler102 20.09.0-3.1+deb11u1
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5multimedia5 5.15.2-3
ii  libqt5multimediawidgets5  5.15.2-3
ii  libqt5network55.15.2+dfsg-9
ii  libqt5script5 5.15.2+dfsg-2
ii  libqt5svg55.15.2-3
ii  libqt5webkit5 5.212.0~alpha4-11
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5xml55.15.2+dfsg-9
ii  libquazip5-1  0.9.1-1
ii  libssl1.1 1.1.1n-0+deb11u4
ii  libstdc++610.2.1-6
ii  libswresample37:4.3.5-0+deb11u1
ii  libswscale5   7:4.3.5-0+deb11u1
ii  libx11-6  2:1.7.2-1
ii  openboard-common  1.5.4+dfsg1-2+deb11u1
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

openboard recommends no packages.

Versions of packages openboard suggests:
ii  openboard-contrib  1.5.4+dfsg1-2+deb11u1

Bug#1034892: php8.2: reproducible-builds: Timestamps in phar files

2023-04-26 Thread Vagrant Cascadian

Source: php8.2
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org, Jelle van der Waa 


Somehow the build time affects or is embedded in the generation of
/usr/bin/phar*.phar:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/php8.2.html

The attached patch fixes this by setting the timestamp embedded to "0".

I have not tested that the resulting phar8.2.phar functions correctly,
but it does build, so it would be good for someone who knows how to use
phar to test that before applying!

According to my local tests, with this patch applied (and the one for
usrmerge) php8.2 should become reproducible once it transitions to
bookworm/testing!

Other outstanding issues (e.g. build paths) which are tested only on
unstable and experimental, and still need further investigation.

Thanks for maintaining php8.2!

live well,
  vagrant
From 743402aceee59da001af1e522290cda56484 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 25 Apr 2023 11:20:24 -0700
Subject: [PATCH 4/6] Remove timestamps from "phar".

Thanks to Jelle van der Waa!

https://gist.github.com/jelly/96847934239aac19c512c54ca65d6baa
---
 ext/phar/phar.c | 2 +-
 ext/phar/util.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ext/phar/phar.c b/ext/phar/phar.c
index f60b0d6a..12cc7b63 100644
--- a/ext/phar/phar.c
+++ b/ext/phar/phar.c
@@ -2999,7 +2999,7 @@ int phar_flush(phar_archive_data *phar, char *user_stub, zend_long len, int conv
 			4: metadata-len
 			+: metadata
 		*/
-		mytime = time(NULL);
+		mytime = 0;
 		phar_set_32(entry_buffer, entry->uncompressed_filesize);
 		phar_set_32(entry_buffer+4, mytime);
 		phar_set_32(entry_buffer+8, entry->compressed_filesize);
diff --git a/ext/phar/util.c b/ext/phar/util.c
index 72e633a5..d126d392 100644
--- a/ext/phar/util.c
+++ b/ext/phar/util.c
@@ -574,7 +574,7 @@ phar_entry_data *phar_get_or_create_entry_data(char *fname, size_t fname_len, ch
 
 	phar_add_virtual_dirs(phar, path, path_len);
 	etemp.is_modified = 1;
-	etemp.timestamp = time(0);
+	etemp.timestamp = 0;
 	etemp.is_crc_checked = 1;
 	etemp.phar = phar;
 	etemp.filename = estrndup(path, path_len);
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1034769: singular: build-dependencies unsatifiable on architectures where sagemath is unavailable.

2023-04-26 Thread Jerome BENOIT


Hello Again,

I think that something is wrong with the package brial.
Sage is an umbrella software which involves brial,
so it makes no sense that brial depends on a sage package.
This is my first remark.
I will have a closer look on the dependency of singular on brial.
Best wishes,
Jerome

--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034733: unblock: irony-mode/1.5.0-5

2023-04-26 Thread Nicholas D Steeves

Paul Gevers  writes:

> Hi Nicholas,
>
> On 23-04-2023 00:06, Nicholas D Steeves wrote:
>> unblock irony-mode/1.5.0-5
>
> llvm-toolchain-15 isn't expected to change and migration in it's current 
> for is not accepted. Please upload your changes to tpu, with only a new 
> changelog entry targeting 'bookworm', preferably with version 
> 1.5.0-5+deb12u1.

Thank you for the discussion and help determining the correct solution!
I've uploaded to tpu, targeted 'bookworm', used the suggested version,
and I'll remove the moreinfo tag when I see evidence that the upload is
in the archive.  I don't know if this will be hours or days.

Testing to tpu debdiff attached.

Regards,
Nicholas

1.5.0-4_to_1.5.0-5+deb12u1.debdiff
Description: Testing to tpu debdiff for irony-mode

signature.asc
Description: PGP signature

Bug#1034733: unblock: irony-mode/1.5.0-5

2023-04-26 Thread Nicholas D Steeves

Cyril Brulebois  writes:

> Nicholas D Steeves  (2023-04-25):
>> I had added this block in error.  Llvm-15-toolchain/1:15.0.6-4, which is
>> in bookworm, fulfills the requirements for irony-mode/1.5.0-5.
>
> Not really, with such dependency:
>
> libclang1-15 (>= 1:15.0.7-1)
>
> vs.
>
> llvm-toolchain-15 | 1:15.0.6-4| testing| source
>

Indeed, runtime deps (determined when package is built) vs build deps
for the source package :)  Thank you for expecting more clear
communication, as well as for the discussion and help determining the
correct solution.

Cheers,
Nicholas

signature.asc
Description: PGP signature

Bug#1004184: gcc-11: generate bad code for matplotlib with -O1/-O2 on mips64el


Hi mips porters,

On Fri, 24 Feb 2023 23:10:29 + James Addison  wrote:

Source: gcc-11
Control: forwarded -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914

Hi Frederic: I'm linking a forwarded GCC GNU bug report that I _think_ is the
upstream report matching this bug.  I found it from a related GitHub issue[1]
for matplotlib.

The GCC bug reporter has done some work to create a minimal reproducer case.
Could you check whether the issue reported there is the same one as here?  (I
will do eventually, but am not familiar with C and do not have mips hardware
available so it may take some time)

[1] - https://github.com/matplotlib/matplotlib/issues/21789


We're you ever made aware of this bug in gcc-11 and gcc-12? Maybe a bit 
of your help is appropriate.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034886: docker.io: CVE-2022-37708

2023-04-26 Thread Shengjing Zhu

On Thu, Apr 27, 2023 at 1:39 AM Moritz Mühlenhoff  wrote:
>
> Source: docker.io
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
>
> Hi,
>
> The following vulnerability was published for docker.io.
>
> CVE-2022-37708[0]:
> | Docker version 20.10.15, build fd82621 is vulnerable to Insecure
> | Permissions. Unauthorized users outside the Docker container can
> | access any files within the Docker container.
>
> The only reference here seems to be
> upstream: https://github.com/thekevinday/docker_lightman_exploit
>
> Not sure if this was reported upstream

I have talked to Tianon on 2023-02-28, and we concluded that it's not
a security issue, just working as expected.

Tianon said he will ask someone inside the Docker company. Not sure if
they have successfully invalidated this CVE.

-- 
Shengjing Zhu

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386


Oops, link missing.

On 26-04-2023 22:09, Paul Gevers wrote:

We discussed this during the Release Team IRC meeting [1]


[1] 
http://meetbot.debian.net/debian-release/2023/debian-release.2023-04-26-18.59.html


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#973414: rustc: produces non-baseline opcodes for compiler_builtins::int::udiv::__udivmoddi4 on i386


Control: severity -1 important

Hi,

We discussed this during the Release Team IRC meeting [1], and we 
decided that it's too late in the release cycle to fix this. We'll 
accept the de-facto baseline bump for bookworm and document the fact in 
the Release Notes.


Having said that, without having discussed it, I don't think we object 
having support for the previous baseline in trixie, if we still release 
i386 with it.


Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#918774: fixed in lasi 1.1.3-1

2023-04-26 Thread Nilesh Patra

On Sun, 23 Apr 2023 06:18:58 + Debian FTP Masters 
 wrote:

Source: lasi
Source-Version: 1.1.3-1
Done: Nilesh Patra 


Sending BTS mail to help reset the autorm counter.

Thanks
Nilesh

Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

2023-04-26 Thread Rainer Dorsch

Sorry, I misunderstood.

The second crash is worse:
- The upstream developer think it is Debian or QT related and there is no 
known workaround
- And it is still there with 100% occurrence probability:

rd@h370:~/tmp.nobackup$ digikam 
digikam.facedb: Cannot found faces engine model "shapepredictor.dat" 
digikam.facedb: Faces recognition feature cannot be used! 
digikam.facedb: Cannot found faces engine DNN model 
"openface_nn4.small2.v1.t7" 
digikam.facedb: Faces recognition feature cannot be used! 
kf.xmlgui: Unhandled container to remove :  Digikam::DigikamApp 
ASSERT: "!isEmpty()" in file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, 
line 363 
21 -- exe=/usr/bin/digikam 
13 -- platform=xcb 
11 -- display=:0 
16 -- appname=digikam 
17 -- apppath=/usr/bin 
9 -- signal=6 
11 -- pid=475825 
17 -- appversion=7.9.0 
20 -- programname=digiKam 
31 -- bugaddress=sub...@bugs.kde.org 
KCrash: crashing... crashRecursionCounter = 2 
KCrash: Application Name = digikam path = /usr/bin pid = 475825 
KCrash: Arguments: /usr/bin/digikam  
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi 

[1]+  Stopped digikam 
rd@h370:~/tmp.nobackup$ 


It is not clear to me though if it has something to do with the faces 
features. What I just realize when looking at the failing assertion, it seems 
to be the same assertion in qlist which triggers the abortion. Could be by 
coincidence though.

Rainer


Am Mittwoch, 26. April 2023, 15:24:46 CEST schrieben Sie:
> I understood that upstream fixed a splash screen bug from your traces.  I do
> plan to look into applying that patch.
> 
> But I thought that even after disabling the splash screen you were seeing a
> second crash?  That is what I’m trying to figure out.
> 
> Sent from my iPhone
> 
> > On Apr 26, 2023, at 1:24 AM, Rainer Dorsch  wrote:
> > 
> > 
> > Hi Steve,
> > 
> > Am Mittwoch, 26. April 2023, 05:49:03 CEST schrieben Sie:
> > > On Tuesday, April 25, 2023 12:50:39 P.M. CDT Rainer Dorsch wrote:
> > > > Am Dienstag, 25. April 2023, 03:51:44 CEST schrieben Sie:
> > > > > I'd be interested to know if the issue persists on your system after
> > > > > upgrading.
> > > > 
> > > > Yes, it repros always.
> > > 
> > > OK.
> > > 
> > > > -- System Information:
> > > > Debian Release: 12.0
> > > > 
> > > >   APT prefers testing-security
> > > >   APT policy: (500, 'testing-security'), (500, 'testing-debug'), (105,
> > > > 
> > > > 'testing')
> > > > Architecture: amd64 (x86_64)
> > > > Foreign Architectures: i386
> > > > 
> > > > Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT)
> > > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> > > > LANGUAGE=de:en_US
> > > 
> > > I'm still not able to reproduce the issue.  Today I was trying with the
> > > same locale as you (de_DE.UTF-8).   I have seen issues in the past with
> > > certain locales -- typically in software that isn't careful enough and
> > > gets into trouble when a locale switches the period and comma in number
> > > formats.> 
> > Be aware that upstream also was unable to repro the issue and finally they
> > managed to understand and fix the problem by the traces I was able to
> > generated.> 
> > > Even though I wasn't able to reproduce the problem here, it would be
> > 
> > > interesting if you can try with locale set to en_US for example:
> > There is no change if I unset LANG:
> > 
> > rd@h370:~/tmp.nobackup$ unset LANG
> > rd@h370:~/tmp.nobackup$ digikam
> > digikam.facedb: Cannot found faces engine model "shapepredictor.dat"
> > digikam.facedb: Faces recognition feature cannot be used!
> > digikam.facedb: Cannot found faces engine DNN model
> > "openface_nn4.small2.v1.t7" digikam.facedb: Faces recognition feature
> > cannot be used!
> > kf.xmlgui: Unhandled container to remove :  Digikam::DigikamApp
> > ASSERT: "!isEmpty()" in file
> > /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 363 21 --
> > exe=/usr/bin/digikam
> > 13 -- platform=xcb
> > 11 -- display=:0
> > 16 -- appname=digikam
> > 17 -- apppath=/usr/bin
> > 9 -- signal=6
> > 11 -- pid=459194
> > 17 -- appversion=7.9.0
> > 20 -- programname=digiKam
> > 31 -- bugaddress=sub...@bugs.kde.org
> > KCrash: crashing... crashRecursionCounter = 2
> > KCrash: Application Name = digikam path = /usr/bin pid = 459194
> > KCrash: Arguments: /usr/bin/digikam
> > KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
> > 
> > [1]+  Stopped digikam
> > rd@h370:~/tmp.nobackup$
> > 
> > > I have no idea where else to look.  Given that no-one else has reported
> > > this, I'm leaning towards downgrading the severity to keep digikam in
> > > the
> > > upcoming release.
> > 
> > That is certainly and option. For me as a user it would be helpful if you
> > would highlight in the changelog that I get during the upgrade the
> > information to disable the splash screen if they run into this issue.
> > 
> > Alternatively you could apply the bugfix
> > 
> >

Bug#1034889: mariadb: CVE-2022-47015

2023-04-26 Thread Otto Kekäläinen

This will be fixed as part of next upstream maintenance release update in
all versions of Debian and Ubuntu. I expect to do it in coming 1-2 weeks.

Bug#1034816: aide aborts with error "realloc: failed to allocate memory", exit code 22

2023-04-26 Thread Hannes von Haugwitz

Hello Thomas,

On Wed, Apr 26, 2023 at 07:46:40AM +0200, Thomas Dorner wrote:
> > How many files are in the AIDE database on a successful run? Does this
> > number significantly differ when the aide check fails?
> 
> You mean the /var/lib/aide/aide.db?
> # zcat /var/lib/aide/aide.db | wc
>  755240 21146627 442199792

This shouldn't be large enough to fill up 32 GB of memory.

Can you try to reproduce the failure and verify that the memory is
actually used up by the aide process?

> > Is 0.18.2-1 the only version you experience this behaviour or does
> > this error also occur with an older version?
> 
> I've never encountered this before, but I did not work with the
> specific directory tree parallel to the AIDE run for at least 3 weeks
> before the this one.

Additionally can you try to directly call aide limited to the specific
directory (see --limit option).

Best regards

hannes

Bug#1034891: 389-ds-base: CVE-2023-1055

Source: 389-ds-base
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2023-1055[0]:
| A flaw was found in RHDS 11 and RHDS 12. While browsing entries LDAP
| tries to decode the userPassword attribute instead of the
| userCertificate attribute which could lead into sensitive information
| leaked. An attacker with a local account where the cockpit-389-ds is
| running can list the processes and display the hashed passwords. The
| highest threat from this vulnerability is to data confidentiality.

https://bugzilla.redhat.com/show_bug.cgi?id=2173517

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1034890: gpac: CVE-2023-0841

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

Hi,

The following vulnerability was published for gpac.

CVE-2023-0841[0]:
| A vulnerability, which was classified as critical, has been found in
| GPAC 2.3-DEV-rev40-g3602a5ded. This issue affects the function
| mp3_dmx_process of the file filters/reframe_mp3.c. The manipulation
| leads to heap-based buffer overflow. The attack may be initiated
| remotely. The exploit has been disclosed to the public and may be
| used. The associated identifier of this vulnerability is VDB-221087.

Only reference here is the following, doesn't seem to have been forwarded:
https://github.com/qianshuidewajueji/poc/blob/main/gpac/mp3_dmx_process_poc3

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1034888: ruby-commonmarker: CVE-2022-39209

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

Hi,

The following vulnerability was published for ruby-commonmarker.

CVE-2022-39209[0]:
| cmark-gfm is GitHub's fork of cmark, a CommonMark parsing and
| rendering library and program in C. In versions prior to 0.29.0.gfm.6
| a polynomial time complexity issue in cmark-gfm's autolink extension
| may lead to unbounded resource exhaustion and subsequent denial of
| service. Users may verify the patch by running `python3 -c
| 'print("![l"* 10 + "\n")' | ./cmark-gfm -e autolink`, which will
| resource exhaust on unpatched cmark-gfm but render correctly on
| patched cmark-gfm. This vulnerability has been patched in
| 0.29.0.gfm.6. Users are advised to upgrade. Users unable to upgrade
| should disable the use of the autolink extension.

https://github.com/github/cmark-gfm/security/advisories/GHSA-cgh3-p57x-9q7q
https://github.com/github/cmark-gfm/commit/cfcaa0068bf319974fdec283416fcee5035c2d70
 (0.29.0.gfm.6)


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1034889: mariadb: CVE-2022-47015

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

Hi,

The following vulnerability was published for mariadb.

CVE-2022-47015[0]:
| MariaDB Server before 10.3.34 thru 10.9.3 is vulnerable to Denial of
| Service. It is possible for function spider_db_mbase::print_warnings
| to dereference a null pointer.

https://jira.mariadb.org/browse/MDEV-29644, fixed in 10.11.3


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1034887: python-cmarkgfm: CVE-2022-39209

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

Hi,

The following vulnerability was published for python-cmarkgfm.

CVE-2022-39209[0]:
| cmark-gfm is GitHub's fork of cmark, a CommonMark parsing and
| rendering library and program in C. In versions prior to 0.29.0.gfm.6
| a polynomial time complexity issue in cmark-gfm's autolink extension
| may lead to unbounded resource exhaustion and subsequent denial of
| service. Users may verify the patch by running `python3 -c
| 'print("![l"* 10 + "\n")' | ./cmark-gfm -e autolink`, which will
| resource exhaust on unpatched cmark-gfm but render correctly on
| patched cmark-gfm. This vulnerability has been patched in
| 0.29.0.gfm.6. Users are advised to upgrade. Users unable to upgrade
| should disable the use of the autolink extension.

https://github.com/github/cmark-gfm/security/advisories/GHSA-cgh3-p57x-9q7q
https://github.com/github/cmark-gfm/commit/cfcaa0068bf319974fdec283416fcee5035c2d70
 (0.29.0.gfm.6)


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1034886: docker.io: CVE-2022-37708

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

Hi,

The following vulnerability was published for docker.io.

CVE-2022-37708[0]:
| Docker version 20.10.15, build fd82621 is vulnerable to Insecure
| Permissions. Unauthorized users outside the Docker container can
| access any files within the Docker container.

The only reference here seems to be
upstream: https://github.com/thekevinday/docker_lightman_exploit

Not sure if this was reported upstream

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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1034885: RM: golang-github-go-macaron-binding -- RoQA; Obsolete

2023-04-26 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-go-macaron-bind...@packages.debian.org
Control: affects -1 + src:golang-github-go-macaron-binding

Please remove golang-github-go-macaron-binding. This was originally uploaded for
gitea which is no longer in the archive.

Bug#1034883: RM: golang-github-go-macaron-csrf -- RoQA; Obsolete, open security issues

2023-04-26 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-go-macaron-c...@packages.debian.org
Control: affects -1 + src:golang-github-go-macaron-csrf

Please remove golang-github-go-macaron-csrf. It was only packaged for
Gitea, which is no longer in the archive and there's an open security issue.

Bug#1034884: RM: golang-github-go-macaron-gzip -- RoQA; Obsolete

2023-04-26 Thread Moritz Muehlenhoff

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-go-macaron-g...@packages.debian.org
Control: affects -1 + src:golang-github-go-macaron-gzip

Please remove golang-github-go-macaron-gzip. The version in the archive is a 
very
old snapshot from 2015 without rdeps, Macaron was originally uploaded for gitea
which is no longer in the archive.

Bug#1034668: Please update to new upstream release 3.22.3 in experimental

2023-04-26 Thread Pirate Praveen

On Mon, 24 Apr 2023 12:03:35 +0530 Pirate Praveen 
 wrote:

> CMake Warning at cmake/abseil-cpp.cmake:28 (message):
>   protobuf_ABSL_PROVIDER is "module" but ABSL_ROOT_DIR is wrong
> Call Stack (most recent call first):
>   CMakeLists.txt:350 (include)
>
> I could skip building googletest easily, but this is not very 
straight

> forward. Any ideas?

I tried setting -Dprotobuf_ABSL_PROVIDER=package similar to grpc, but 
the rules file seems too complex, so I will leave it to the maintainer 
for a proper update. In the meanwhile, gitlab can use the version from 
rubygems.org (being in contrib).

Bug#1032970: installation-reports to Pinebook Pro, d-i alpha 2

Vagrant Cascadian  (2023-04-26):
> Or the same thing from the daily-images:
> 
>   https://d-i.debian.org/daily-images/arm64/daily/
> 
>   ... which appears to be missing the netboot images today (probably in
>   the middle of the kernel transition) ...

Yes, the linux upload is a little too young, and I'm planning on
sticking with linux/testing for the RC 2. One part of my plan for the
upcoming debugging session was building a netboot image (mini.iso and/or
SD images) against testing.

> Technically, the Tow-boot on your SPI (or eMMC?) will likely take over
> and not use the u-boot on the microsd, but I *think* it should support
> those images, which should pass the correct device-tree at least. You
> might need a USB-ethernet adapter if the wifi firmware is not included
> in those images... or otherwise do the firmware dance to get the wifi
> working (I've only ever used the pinebook-pro-rk3399 with USB
> ethernet/wifi).


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


signature.asc
Description: PGP signature

Bug#1032970: installation-reports to Pinebook Pro, d-i alpha 2

2023-04-26 Thread Vagrant Cascadian

On 2023-04-02, znot...@mailbox.org wrote:
> On Wed, Mar 15, 2023 at 09:50:23AM -0400, Znoteer wrote:
>> On Tue, Mar 14, 2023 at 11:34:42PM +0100, Cyril Brulebois wrote:
>> > Znoteer  (2023-03-14):
>> > How reliable is your storage?
>> > 
>> > Mar 14 21:26:04 in-target: dpkg-deb (subprocess): decompressing archive 
>> > '/tmp/firmware-brcm80211_20230117-2_all.deb' (size=5349764) member 
>> > 'data.tar': lzma error: compressed data is corrupt
>> > Mar 14 21:40:09 in-target: dpkg-deb (subprocess): decompressing archive 
>> > '/tmp/apt-dpkg-install-JqSiZc/097-libllvm15_1%3a15.0.6-4+b1_arm64.deb' 
>> > (size=20662856) member 'data.tar': lzma error: compressed data is corrupt^M
>> 
>> I'm not sure how to answer that. It's an nvme drive that I bought for this 
>> pinebook pro, so was new though I've had the pinebook pro for some time.

Some NVME draw a bit too much power with the default power profiles, but
can be configured to be a bit more conservative. I picked slower NVME
devices partly to avoid having to do this, and still I had one NVME that
was reliable, and one that was not out-of-the-box (but worked fine in
another computer).

You might want to set the NVME power usage (using the "nvme" command
from the "nvme-cli" package):

https://wiki.pine64.org/index.php/Pinebook_Pro#Post_NVMe_install_power_limiting

Main commands that are useful are "nvme id-ctrl" to see the various
power profiles, and "nvme get-feature" and "nvme set-feature" to select
a different profile.

> I've succesfully installed, first try, Armbian to the eMMC of my Pinebook 
> Pro. Install is maybe not as accurate as "copied".
...
> I took out the SD card after and rebooted (I chose not to write anything to 
> SPI as I was confident that Tow-boot would do).

Since you're using Tow-boot (presumably installed to SPI?), you might be
booting in EFI mode, and grub might be using the device-tree that is
provided by Tow-boot... which might not be fully compatible with the
kernel you are running. You might have to configure grub to use the
device-tree consistent with your kernel (which is unfortunately more
difficult than it ought to be).

Alternately, switch to using u-boot-menu which generates an
extlinux.conf boot menu, or flash-kernel boot scripts... both of those
will use a device-tree that matches your running kernel.

Another option might be to try the sd-card-images:

https://ftp.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/SD-card-images/

Or the same thing from the daily-images:

  https://d-i.debian.org/daily-images/arm64/daily/

  ... which appears to be missing the netboot images today (probably in
  the middle of the kernel transition) ...

Technically, the Tow-boot on your SPI (or eMMC?) will likely take over
and not use the u-boot on the microsd, but I *think* it should support
those images, which should pass the correct device-tree at least. You
might need a USB-ethernet adapter if the wifi firmware is not included
in those images... or otherwise do the firmware dance to get the wifi
working (I've only ever used the pinebook-pro-rk3399 with USB
ethernet/wifi).

live well,
  vagrant

signature.asc
Description: PGP signature

Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6

2023-04-26 Thread Matt Taggart


On 4/26/23 06:16, Cyril Brulebois wrote:

Control: severity -1 important

Matt Taggart  (2023-04-25):

As reported in #999811 the haveged package is obsolete starting in
linux 5.6 and newer, as the kernel adopted a similar algorithm and
also stopped blocking /dev/random reads.

I am upgrading severity to serious because I believe this is release
critical for bookworm.


No, thanks.


OK.

There may still be reasons to keep haveged in Debian, I do not know.
(do all archs have these >5.6 features? is it still needed in
addition?)


https://bugs.debian.org/1034361#12

1+ month into the hard freeze isn't when you suddenly want to remove a
dependency of the installer.


Sorry, I hadn't seen that bug :(

Post-bookworm I guess...

Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency

2023-04-26 Thread Lisandro Damián Nicanor Pérez Meyer

Hi,

On Tue, 25 Apr 2023 at 17:38, Dmitry Shachnev  wrote:
>
> Hi all!
>
> On Tue, Apr 25, 2023 at 05:21:45PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > To the best of my knowledge Qt installs lots of really not-required headers 
> > in
> > it's private stuff. If you ask them it's for the sake of simplicity, as you 
> > are
> > not supposed to use private headers...
> >
> > The reason we export those private headers is because we build Qt by
> > submodules instead of a big huuuge build including webengine et all, and Qt
> > submodules do have internal private dependencies.
> >
> > So yes, it is a valid bug, but I am afraid that it will be too hard to get
> > that right. Non the less I really appreciate you filing this bug report, it 
> > is
> > a good thing to have it around.
> >
> > @Dmitry: I would mark this as wontfix, what do you think?
>
> Well, if adding just one small dependency will make Steve's script happy,
> then I don't mind doing it. But if we are talking about a dozen of extra
> dependencies, I would rather not do it. Or maybe they should be Recommends or
> Suggests.

Oh, I actually had my mind mostly on the dependencies that are
unsolvable on Debian. But yes, I agree with those.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1034756: dpkg: please add support for riscv32

2023-04-26 Thread Jessica Clarke

On 26 Apr 2023, at 17:22, Bo YU  wrote:
> 
> Hi,
> On Tue, Apr 25, 2023 at 02:08:33PM -0400, Darius Rad wrote:
>> On Tue, Apr 25, 2023 at 10:52:52PM +0800, Bo YU wrote:
>>> On Tue, Apr 25, 2023 at 04:22:49AM +0200, Guillem Jover wrote:
>>> 
>>> >
>>> > > I thought the riscv32 has met the request[2] also.
>>> >
>>> > I assume the ABI is set in stone and well defined.
>>> >
>> 
>> There are three ABIs for 32-bit RISC-V.  They are well defined, but it is
>> not clear which ABI is being proposed for Debian here.
>> 
>>> > > Please let me know if there is any issue.
>>> >
>>> > I think at the time when we added riscv64 we didn't also add riscv32
>>> > because it was not clear whether there was then interest or demand,
>>> > and I don't recall whether there were concerns about what ISA baseline
>>> > to choose? (But I guess this would use the default baseline specified
>>> > currently by the compiler.)
>>> 
>>> There is no doubt that the porting of riscv64 is our first priority and
>>> it's already in a good shape -- except for the official port.:(
>>> 
>>> For riscv32 case, I think it'd be pretty helpful to let users to setup
>>> rv32 Debian rootfs or to let rv32 Debain run on RISC-V 32 bit hardware that
>>> will be emerged in the near future.
>> 
>> Do you have any references for this hardware?
> 
> From my vague memory, there will be k230 fully support rv32 in userspace
> from canaan. Sorry, I was trying to find news or useful url but fail
> here.

From what I can see it’s using a C908 which is RV64. Maybe it can also
do RV32 if you switch mode, but why would you, just as we don’t
recommend people run i386 on amd64.

RV32-only Unix-capable hardware would be more interesting, but seems
like a foolish thing to build in this decade.

>>> Here I simply assume that rv32 compiler with `--with-arch=rv32gc
>>> --with-abi=ilp32d`[0] is enough?
>>> 
>> 
>> That is one choice, but not the only one.
>> 
>> The argument in favor of a 32-bit port of RISC-V is typically motivated by
>> the assumption that such processors will be smaller, in terms of the
>> hardware (i.e., ASIC gates or FPGA LUTs).  However, as compared to rv64gc,
>> eliminating floating point typically provides a much more significant
>> decrease in size.  Thus, often when one is talking about smaller, 32-bit
>> RISC-V processors, they *also* eliminate floating point.  In other words,
>> the processors are rv32imac, not rv32gc.
>> 
>> In fact, I wouldn't be surprised if rv64imac processors were more common
>> than rv32gc, given the minimal hardware resources for 64-bit versus 32-bit,
>> all else being equal.
> 
> Thanks for explaining this. Here are some of my thoughts about it.
> 
> I think, as a distribution, we should provide a basic baseline of
> instruction set supported to cover most hardware vendors. We should not 
> assume that hardware vendors will product their CPUs on a certain instruction
> set.

We should support hardware that does exist, not hardware that might
exist. So long as there is no RV32-only Unix-capable hardware out
there, what is the point in Debian producing a distribution?

> In addition, refer to other 32-bit architectures, like armhf[1] and mips[2], 
> They are also supporting floating point instructions(IIUC).

Because they date back to when 32-bit computing was common practice,
and wanted floating-point. These days, 64-bit is the standard, and
there is little motivation for building a 32-bit core with
floating-point given the tiny additional area needed to make it 64-bit
(especially since you already need 64-bit data paths for the D
extension).

> Also, keep
> the same baseline with rv64, maybe it will reduce confusion for users. 
> I am not sure how much would we benefit from dropping support for 'F' or
> 'D', but maybe we can't lost something if we support full set(rv32gc)
> from port's view.

If you’re going to provide a distribution for RV32, dropping F and D
seems like the right thing to do, since that’s the only sensible thing
to build hardware for. But why commit to one now when nothing exists
yet to motivate any of them.

Jess

> [0]: https://www.canaan.io/
> [1]: 
> https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L485
> [2]: 
> https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L646
> 
>> 
>> // darius
>> 
> 
> -- 
> Regards,
> --
>  Bo YU

Bug#1034882: msmtp: Debconf prompt on upgrade without systemwide configuration

2023-04-26 Thread Simon Chopin

Package: msmtp
Version: 1.8.23-1
Followup-For: Bug #1034882
X-Debbugs-Cc: scho...@ubuntu.com

Attached is the debdiff I uploaded to Ubuntu Lunar (yet to be approved
by our Stable Release team)
diff -Nru msmtp-1.8.23/debian/changelog msmtp-1.8.23/debian/changelog
--- msmtp-1.8.23/debian/changelog   2023-02-05 07:25:20.0 +0100
+++ msmtp-1.8.23/debian/changelog   2023-04-26 15:03:45.0 +0200
@@ -1,3 +1,10 @@
+msmtp (1.8.23-2) unstable; urgency=medium
+
+  * Disable the security-information debconf prompt in the absence of
+system-wide configuration (Closes: #1034882, LP: #2017759)
+
+ -- Simon Chopin   Wed, 26 Apr 2023 15:03:45 +0200
+
 msmtp (1.8.23-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru msmtp-1.8.23/debian/msmtp.config msmtp-1.8.23/debian/msmtp.config
--- msmtp-1.8.23/debian/msmtp.config2022-10-25 19:08:33.0 +0200
+++ msmtp-1.8.23/debian/msmtp.config2023-04-26 14:50:50.0 +0200
@@ -7,7 +7,7 @@
 fi
 
 if [ "${1}" = "configure" ]; then
-if [ -n "${2}" ]; then
+if [ -n "${2}" ] && [ -e /etc/msmtprc ]; then
 db_fget msmtp/security-information seen || true
 if [ "${RET}" = "false" ]; then
 db_input critical msmtp/security-information || true

Bug#1034756: dpkg: please add support for riscv32

2023-04-26 Thread Bo YU

Hi,
On Tue, Apr 25, 2023 at 02:08:33PM -0400, Darius Rad wrote:

On Tue, Apr 25, 2023 at 10:52:52PM +0800, Bo YU wrote:

On Tue, Apr 25, 2023 at 04:22:49AM +0200, Guillem Jover wrote:

>
> > I thought the riscv32 has met the request[2] also.
>
> I assume the ABI is set in stone and well defined.
>

There are three ABIs for 32-bit RISC-V.  They are well defined, but it is
not clear which ABI is being proposed for Debian here.

> > Please let me know if there is any issue.
>
> I think at the time when we added riscv64 we didn't also add riscv32
> because it was not clear whether there was then interest or demand,
> and I don't recall whether there were concerns about what ISA baseline
> to choose? (But I guess this would use the default baseline specified
> currently by the compiler.)

There is no doubt that the porting of riscv64 is our first priority and
it's already in a good shape -- except for the official port.:(

For riscv32 case, I think it'd be pretty helpful to let users to setup
rv32 Debian rootfs or to let rv32 Debain run on RISC-V 32 bit hardware that
will be emerged in the near future.

Do you have any references for this hardware?

From my vague memory, there will be k230 fully support rv32 in userspace
from canaan. Sorry, I was trying to find news or useful url but fail
here.

Here I simply assume that rv32 compiler with `--with-arch=rv32gc
--with-abi=ilp32d`[0] is enough?

That is one choice, but not the only one.

The argument in favor of a 32-bit port of RISC-V is typically motivated by
the assumption that such processors will be smaller, in terms of the
hardware (i.e., ASIC gates or FPGA LUTs).  However, as compared to rv64gc,
eliminating floating point typically provides a much more significant
decrease in size.  Thus, often when one is talking about smaller, 32-bit
RISC-V processors, they *also* eliminate floating point.  In other words,
the processors are rv32imac, not rv32gc.

In fact, I wouldn't be surprised if rv64imac processors were more common
than rv32gc, given the minimal hardware resources for 64-bit versus 32-bit,
all else being equal.

Thanks for explaining this. Here are some of my thoughts about it.

I think, as a distribution, we should provide a basic baseline of
instruction set supported to cover most hardware vendors. We should not 
assume that hardware vendors will product their CPUs on a certain instruction

set.

In addition, refer to other 32-bit architectures, like armhf[1] and mips[2], 
They are also supporting floating point instructions(IIUC). Also, keep
the same baseline with rv64, maybe it will reduce confusion for users. 

I am not sure how much would we benefit from dropping support for 'F' or
'D', but maybe we can't lost something if we support full set(rv32gc)
from port's view.

[0]: https://www.canaan.io/
[1]: 
https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L485
[2]: 
https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L646

// darius

--
Regards,
--
  Bo YU

signature.asc
Description: PGP signature

Bug#1034882: msmtp: Debconf prompt on upgrade without systemwide configuration

2023-04-26 Thread Simon Chopin

Package: msmtp
Version: 1.8.23-1
Severity: normal
X-Debbugs-Cc: scho...@ubuntu.com

The debconf prompt warning the user about the setgid change should only
be showed if they have a systemwide configuration file. It's a poor
upgrade experience to have it otherwise.


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

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

Versions of packages msmtp depends on:
ii  adduser3.129ubuntu1
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.37-0ubuntu2
ii  libgnutls303.7.8-5ubuntu1
ii  libgsasl18 2.2.0-1ubuntu1
ii  libsecret-1-0  0.20.5-3
ii  ucf3.0043+nmu1

Versions of packages msmtp recommends:
ii  ca-certificates  20230311

Versions of packages msmtp suggests:
ii  msmtp-mta  1.8.23-1

-- debconf information excluded

Bug#1034881: falcosecurity-scap-dkms: Cannot compile linux kernel 6.2.12 due to failure with scap dkms

2023-04-26 Thread Dario Susman

Package: falcosecurity-scap-dkms
Version: 0.1.1dev+git20220316.e5c53d64-5.1
Severity: important
Tags: patch upstream

Dear Maintainer,

I've tried to compile linux kernel 6.2.12, but when I wanted to install
it I had the following errors:

root@warpcore:/usr/src/linux-6.2.12# make install
  INSTALL /boot
run-parts: executing /etc/kernel/postinst.d/dkms 6.2.12 /boot/vmlinuz-6.2.12
dkms: running auto installation service for kernel 6.2.12.
Sign command: /lib/modules/6.2.12/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
make -j16 KERNELRELEASE=6.2.12 -C /lib/modules/6.2.12/build 
M=/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.2.12 (x86_64)
Consult /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/make.log for 
more information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.2.12 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
make: *** [arch/x86/Makefile:292: install] Error 1
root@warpcore:/usr/src/linux-6.2.12#

The log shows:

root@warpcore:/usr/src/linux-6.2.12# cat  
/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/make.log
DKMS make.log for scap-0.1.1dev+git20220316.e5c53d64 for kernel 6.2.12 (x86_64)
Wed Apr 26 12:35:26 PM -03 2023
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/main.o
  CC [M]  
/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/dynamic_params_table.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/fillers_table.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/flags_table.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/ppm_events.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/ppm_fillers.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/event_table.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/syscall_table.o
  CC [M]  /var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/ppm_cputime.o
/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/main.c: In function 
‘scap_init’:
/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/main.c:2501:30: error: 
assignment to ‘char * (*)(const struct device *, umode_t *)’ {aka ‘char * 
(*)(const struct device *, short unsigned int *)’} from incompatible pointer 
type ‘char * (*)(struct device *, umode_t *)’ {aka ‘char * (*)(struct device *, 
short unsigned int *)’} [-Werror=incompatible-pointer-types]
 2501 | g_ppm_class->devnode = ppm_devnode;
  |  ^
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:252: 
/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build/main.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [Makefile:2021: 
/var/lib/dkms/scap/0.1.1dev+git20220316.e5c53d64/build] Error 2

I've found patches on two sources:

https://bugs.launchpad.net/ubuntu/+source/falcosecurity-libs/+bug/2009505
https://github.com/falcosecurity/libs/issues/918

Patch in https://github.com/falcosecurity/libs/issues/918 seems to have
worked and compiled just fine.

I believe the debian package just needs to be updated since it's
already been updated in upstream several times.

Thank you!

Best regards,
Dario Susman

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages falcosecurity-scap-dkms depends on:
ii  dkms  3.0.10-8

Versions of packages falcosecurity-scap-dkms recommends:
ii  sysdig  0.29.3-1+b1

falcosecurity-scap-dkms suggests no packages.

Bug#1034819: nft default disabled

2023-04-26 Thread Arturo Borrero Gonzalez

reassign 1034819 debian-installer

On Tue, 25 Apr 2023 11:27:56 +0200 Bonno Bloksma wrote:

Package: d-i
Severity: minor

Dear Maintainer,

Testing with a new Debian bookworm install, downloaded apr 24 2023, I noticed my nftables.conf firewall configuration never gets loaded.

After some testing a searching on the net I found it is disabled by default. As
the /etc/nftables.conf file is marked executable by default this lead me to
think it would get loaded by the service.
As the default firewall in that file quite innocent I wonder why the service is
not enabled by default?

In my case not getting any errors and having a proper config led me to believe
my firewall was working.
All services worked as well. Of course they did, there was no firewall. :-(

As Buster still had a working iptables I never noticed the problem there, not
even when I converted some of my itables config to a nft config file.
All my services still worked after the conversion so I assumed the conversion
was successfull.
Never realizing the filewall config never got loaded and there was no filewall
at all, so my services did indeed work as there was nothing to block it. :-(

Bookworm does not have iptables anymore by default, it should have at least one
acvtive firewall.
Please by default enable the nft service during install and have it load the (innocent) default config in /etc/nftables.conf

The recommended firewall for Debian is the firewalld utility. The default should
be to have firewalld up and running. This is since Debian 11 Bullseye [0].

I don't think there is nothing wrong in the nftables package.

Please Debian installer folks, what would we need for tasksel to enable
firewalld by default? (if tasksel is the right place).

regards.

[0] https://lists.debian.org/debian-devel/2019/07/msg00332.html

Bug#1034229: wsdd2: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

Matteo F. Vescovi  (2023-04-26):
> LGTM. Please, go ahead with a DELAYED/0.
> Thanks for taking care of the issue for me.

My pleasure! Rescheduled.


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


signature.asc
Description: PGP signature

Bug#1034871: podman: "sudo podman system reset" can delete current working directory

Hi,

Reinhard Tartler  (2023-04-26):
> On Wed, Apr 26, 2023 at 6:48 AM Jan Hendrik Farr  wrote:
> > if /etc/containers/storage.conf does not include the runRoot
> > variable, then running "sudo podman system reset" will delete the
> > current working directory.

Ouch!

> > Including this fix in Debian 12 has a really low chance of affecting
> > other packages, but if this fix is not included there will
> > inevitably be more people like me that accidentally remove their
> > home directory.

I'm not sure where exactly people draw the line for “data loss” but
that's what it looks like to me.

> It indeed sounds like a significant papercut. I'm seeking for further
> thoughts and opinions: Is this something worth backporting that late
> in the release cycle?

I'd say: definitely!

(This is not an official statement from the release team though.)

Please keep in mind I know nothing about podman or containers-storage
and I haven't spotted what would set up /etc/containers/storage.conf,
and whether some default configuration would contain that runRoot
setting; but even if it's present… if people have legitimate reasons to
remove that setting, that's no reason to load the gun, aim at their
foot, and wait for them to press the trigger.

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

signature.asc
Description: PGP signature

Bug#1034229: wsdd2: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

2023-04-26 Thread Matteo F. Vescovi

Hi Cyril!

On Tue, Apr 25, 2023 at 5:54 PM Cyril Brulebois  wrote:

[...]

> Maintainer: I'm uploading to DELAYED/5, it can be either rescheduled to
> DELAYED/0 if you're happy with the changes right now, or be superseded
> by an upload of yours if that happens before the delay is over.
>

LGTM. Please, go ahead with a DELAYED/0.
Thanks for taking care of the issue for me.

Cheers.

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A

Bug#1034880: Please update to nautilus 43.4 for Debian 12

2023-04-26 Thread Amr Ibrahim


Package: nautilus

Hello,

Please update to nautilus 43.4 for Debian 12.

https://gitlab.gnome.org/GNOME/nautilus/-/blob/gnome-43/NEWS

Major changes in 43.4
=
* Bugfixes:
  - Dismiss obsolete toast when undo action has changed (Corey Berla)
  - Fix crashes when cloning window (Gary Li, António Fernandes)
  - Fix selection issues after some operations (Corey Berla)
  - Fix dead characters handling in batch rename dialog (Gary Li)
  - Allow displaying unthemed emblems to fix some extensions (António 
Fernandes)
  - Disable properties for special locations to prevent crashes (Khalid 
Abu Shawarib)

  - Prevent opening folder when re-ordering bookmarks (Sayan Bhattacharjee)
  - Prevent location change when autofs timeouts (Ondrej Holy)
  - Fix issues with translations in libadwaita widgets (Peter Eisenmann)
  - Fix other issues (Carlos Garnacho, Corey Berla, Peter Eisenmann, 
Ondrej Holy)

* Translation updates (GNOME Translation Project contributors)

Major changes in 43.3
=
* Bugfixes:
  - Fix critical errors with recent GLib versions (Ondrej Holy)
  - Fix file order after renaming (Corey Berla, António Fernandes)
  - Fix several memory leaks (Corey Berla)
  - Fix crashes caused by inverted g_assert condition (Ondrej Holy)
  - Fix various drag and drop issues (Corey Berla)
  - Fix other issues (Corey Berla, António Fernandes, Ondrej Holy, 
Athul Iddya)

* Translation updates (GNOME Translation Project contributors)


Best,
Amr

Bug#1028417: udev deletes symlink to a device according to a rule and then deletes it as "no longer belonging to this device"

2023-04-26 Thread Michael Biebl


Control: tags -1 + unreproducible moreinfo upstream

On Tue, 10 Jan 2023 23:00:37 +0300 =?UTF-8?B?S09MQU5JQ0g=?= 
 wrote:


Package: udev
Version: 252.4-1
Severity: important
I have encountered an issue with `udev` after upgrade from the latest Ubuntu
Impish (the issue was not experienced on it).


I do hope, you did not cross-upgrade from Ubuntu to Debian, since that 
is not supported.



The issue reproduces on all of them (including the ones there was no issue on 
when I used to be using Ubuntu).
So it is likely that the issue is in udev or in some of its rules and
not in the hardware or kernel.


I can't reproduce the problem.
So in case you still encounter the problem, it would be best if you file 
this upstream at

https://github.com/systemd/systemd/issues
after upgrading to the latest version of systemd.

Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033808: ImportError: cannot import name 'Markup' from 'jinja2'

2023-04-26 Thread Simon McVittie

Control: severity -1 grave
Control: tags -1 + patch

On Sat, 01 Apr 2023 at 21:05:12 -0400, David Mandelberg wrote:
> salt-ssh and salt-call are both giving me the error below, though with
> different parts at the top of the stack trace. Upstream bug is:
> https://github.com/saltstack/salt/issues/61848

After resolving the immediate issue with Markup, there's a similar issue
with contextfunction. Both are fixed in upstream PR
.

I'm raising this to grave because it makes salt(-ssh) unusable on bookworm,
although that doesn't have any practical effect on migration to testing
because there are multiple RC bugs already.

smcv

Bug#1031721: udev fails to autoload kernel modules (wifi, sound, video, bluetooth, thermals)

2023-04-26 Thread Michael Biebl


Control: tags -1 + moreinfo unreproducible

On Wed, 22 Feb 2023 00:55:21 +1100 Sohum Banerjea  wrote:

Package: udev
Version: 252.5-2
Severity: important

Dear Maintainer,

Since upgrading my system to udev 252 from 250, kernel module autoloading has 
been broken
on my machine. I've confirmed that it's exactly a problem with the udev package 
via zfs
rollbacks.

The modules themself work fine; I can run:

sudo modprobe coretemp intel_pch_thermal thinkpad_acpi iwlwifi 
nvidia-current-drm modeset=1 bluetooth snd-hda-intel btusb

and return to a functioning system.

I do not understand how kernel module autoloading is supposed to work, and 
could not find
documentation that helped, so I apologise for not having further information. 
I'm happy to
do any further investigation that may help.


Is this problem still reproducible?
Can you provided a verbose debug log?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034879: unblock: lacme/0.8.2-1

2023-04-26 Thread Guilhem Moulin

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

Please unblock package lacme

[ Reason ]

The ACME specification (RFC 8555 sec. 7.1.6) clearly reads that state
transition for Order Objects follows (‘pending’ →) ‘ready’ →
‘processing’ → ‘valid’, but lacme 0.8.1-1 fails to handle the transition
via ‘processing’ state.
https://www.rfc-editor.org/rfc/rfc8555#section-7.1.6

[ Impact ]

As of today Order Requests still work on the production Let's Encrypt
environment, but now fails on the staging one.  It's unclear whether the
production server has different timing conditions (faster machine, so
the client doesn't have time to issue follow-up request while the server
is in ‘processing’ state), or if there was some code change deployed to
the staging server which is not in production (yet).

In the former case, the lacme client suffers from a race condition that
needs to be fixed anyway.  In the latter case, lacme will fail to handle
Order Requests (incl. certificate renewals) if/when the production ACME
server is upgraded.

[ Tests ]

Manual tests: I successfully ran the upstream test suite (which includes
multiple Order Requests) on the staging server.  (There is unfortunately
no autopkgtest running the test suite, because it requires inbound
80/tcp and a stable (wildcard) domain name.)

I also successfully issued Order Requests to Let's Encrypt's production
server.

[ Risks ]

src:lacme is a leaf package and the diff is so trivial I uploaded
0.8.2-1 rather than backported the fix to 0.8.1-1.  AFAICT the only
change is a more lax handling of Order Object responses, so there
shouldn't be any risk associated with the upgrade.

[ Checklist ]

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

unblock lacme/0.8.2-1

-- 
Guilhem.
diffstat for lacme-0.8.1 lacme-0.8.2

 Changelog  |   11 +++
 client |   31 +--
 debian/changelog   |   12 
 lacme  |2 +-
 lacme-accountd |2 +-
 tests/old-accountd |2 +-
 6 files changed, 43 insertions(+), 17 deletions(-)

diff -Nru lacme-0.8.1/Changelog lacme-0.8.2/Changelog
--- lacme-0.8.1/Changelog   2023-01-25 03:23:51.0 +0100
+++ lacme-0.8.2/Changelog   2023-04-25 20:06:22.0 +0200
@@ -1,3 +1,14 @@
+lacme (0.8.2) upstream;
+
+  + client: Handle "ready" → "processing" → "valid" status change during
+newOrder, instead of just "ready" → "valid".  The latter may be what
+we observe when the server is fast enough, but according to RFC 8555
+sec. 7.1.6 the state actually transitions via "processing" state and
+we need to account for that.
+  - Test suite: Point stretch's archive URL to archive.d.o.
+
+ -- Guilhem Moulin   Tue, 25 Apr 2023 20:06:22 +0200
+
 lacme (0.8.1) upstream;
 
  + lacme-accountd: improve log messages and refactor logging logic.
diff -Nru lacme-0.8.1/client lacme-0.8.2/client
--- lacme-0.8.1/client  2023-01-25 03:23:51.0 +0100
+++ lacme-0.8.2/client  2023-04-25 20:06:22.0 +0200
@@ -43,7 +43,7 @@
 # instance own by another user and created with umask 0177) is not a
 # problem since SOCKET_FD can be bound as root prior to the execve(2).
 
-our $VERSION = '0.8.1';
+our $VERSION = '0.8.2';
 my $PROTOCOL_VERSION = 1;
 my $NAME = 'lacme-client';
 
@@ -346,11 +346,12 @@
 }
 
 # poll the order URL (to get the status of all challenges at once)
-# until the status become 'valid'
+# until the status become 'valid'; see RFC 8555 sec. 7.1.6 for the
+# the status change flow
 my $orderstr = join(', ', map {uc($_->{type}) .":". $_->{value}} 
@identifiers);
 my $certuri;
-for (my $i = 0;;) {
-my $r = acme($orderurl);
+for (my $i = 0, my $url = $orderurl, my $payload;;) {
+my $r = acme($url => $payload);
 my $resp = request_json_decode($r);
 if (defined (my $problem = $resp->{error})) { # problem document (RFC 
7807)
 my $msg = $problem->{status};
@@ -361,19 +362,21 @@
 my $status = $resp->{status};
 if (!defined $status or $status eq "invalid") {
 die "Error: Invalid order $orderstr\n";
-}
-elsif ($status eq "ready") {
-my $r = acme($order->{finalize}, {csr => encode_base64url($csr)});
-my $resp = request_json_decode($r);
-$certuri = $resp->{certificate};
-last;
-}
-elsif ($status eq "valid") {
+} elsif ($status eq "pending") {
+# keep retrying
+} elsif ($status eq "ready") {
+$url = $order->{finalize};
+$payload = {csr => encode_base64url($csr)};
+# retry after moving to "processing" or "valid" state
+next;
+} elsif ($status eq

Bug#1034878: meld gives python traceback if run as root

2023-04-26 Thread Wookey

Package: meld
Version: 3.22.0-2
Severity: normal

I change to root inorder to be able to access some files to diff and ran meld. 
I got the following traceback:
root@mongol:~# meld
Traceback (most recent call last):
  File "/usr/bin/meld", line 463, in 
sys.exit(main())
 ^^
  File "/usr/bin/meld", line 458, in main
setup_settings()
  File "/usr/bin/meld", line 317, in setup_settings
meld.settings.create_settings()
  File "/usr/lib/python3/dist-packages/meld/settings.py", line 124, in 
create_settings
_meldsettings = MeldSettings()
^^
  File "/usr/lib/python3/dist-packages/meld/settings.py", line 39, in __init__
self.on_setting_changed(settings, 'prefer-dark-theme')
  File "/usr/lib/python3/dist-packages/meld/settings.py", line 58, in 
on_setting_changed
gtk_settings.props.gtk_application_prefer_dark_theme = prefer_dark
^^
AttributeError: 'NoneType' object has no attribute 'props'

~#meld boot0 boot1
(i.e supplying filenames) gave the same output.

meld runs fine when run as the desktop user
It should deal more elegantly with this situation.

--
Wookey

Bug#1034867: smplayer: crash when playing video files using mplayer under Wayland

2023-04-26 Thread Lorenzo

Hi James,

thanks for reporting this

> This is reproducible if launching mplayer standalone to play the
> video file with the 'wid' argument specified manually.  Audio will
> play, but video does not appear.
> 
> What is worse, however, is that when the 'nokeepaspect' parameter is
> added, as is the case with smplayer, then mplayer itself crashes with
> a floating-point math exception.  This appears to occur here:
> https://sources.debian.org/src/mplayer/2%3A1.5%2Bsvn38408-1/libvo/vo_xv.c/#L365-L367

I've opened an issue for this at mplayer upstream tracker
https://trac.mplayerhq.hu/ticket/2411
let's see if this can be addressed in mplayer

Lorenzo

Bug#1034877: update ffuf to version 2.0.0

2023-04-26 Thread Thiago Andrade


Package: ffuf
Severity: wishlist

Dear Maintainer,
Please update ffuf to new upstream version 2.0.0.
Cheers.

Thiago Andrade

--
...
⢀⣴⠾⠻⢶⣦⠀ Thiago Andrade Marques
⣾⠁⢰⠒⠀⣿⡁ GPG: 4096R/F8CDB08B
⢿⡄⠘⠷⠚⠋⠀ GPG Fingerprint: 1D38 EE3C 624F 955C E1FA  3C85 5A30 3591 F8CD B08B
⠈⠳⣄

Bug#766458: lynx-cur: some tables are not rendered correctly

2023-04-26 Thread Vincent Lefevre

Control: tags -1 - unreproducible

On 2023-04-26 15:41:36 +0200, Vincent Lefevre wrote:
> I suspect that the test was done with a wider terminal.
> So removing the "unreproducible" tag.

Now doing it correctly...

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

Bug#766458: lynx-cur: some tables are not rendered correctly

2023-04-26 Thread Vincent Lefevre

Control: found -1 2.9.0dev.12-1
Control: tags -1 unreproducible

On 2015-06-05 01:51:15 +0200, Vincent Lefevre wrote:
> Note: the test must be done in a 80-column terminal, otherwise the
> result is not reproducible.

I suspect that the test was done with a wider terminal.
So removing the "unreproducible" tag.

I recall that the testcase is the attached file at

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766458#5

i.e. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=766458;filename=tables.html;msg=5

lynx 2.9.0dev.12-1 still produces

   Table 1:▮
   ▮
   A: 123456789 123456789 foo  ▮
   B: 12345678 foo foo foo foo foo foo foo foo foo foo foo foo foo foo ▮
   foo foo ▮
   ▮
   Table 2:▮
   ▮
   A: 123456789 123456789 foo  ▮
   B: 1234567 foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo  ▮
   foo ▮

while ELinks is correct, for instance:

   Table 1:

   A: 123456789 123456789 foo
   B: 12345678foo foo foo foo foo foo foo foo foo foo foo foo foo
  foo foo foo

   Table 2:

   A: 123456789 123456789 foo
   B: 1234567 foo foo foo foo foo foo foo foo foo foo foo foo foo
  foo foo foo

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

Bug#999811: HAVEGED is obsolete starting from linux kernel 5.6