Bug#1040783: libvirt-daemon: libvirt firewalld zone is missing

[Nick Hastings]

Hi,

On Tue, 11 Jul 2023 04:41:07 +0200 =?UTF-8?Q?Niccol=C3=B2_Belli?= 
 wrote:
> I've found the root of the problem: I was connecting to libvirt via ssh 
> using an unprivileged user part of the libvirt group. That works for 
> most of the tasks but not for creating the firewalld libvirt zone. Using 
> root, while being less than ideal, works fine.

I'm facing the same problem. I'm running virt-manager on the localhost as
a user who is a member of the libvirt group. What did you actually run as
root to have the libvirt zone created?

Thanks,

Nick.

Bug#1040962: src:sympy: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: sympy
Version: 1.11.1-1
Severity: serious
Control: close -1 1.12-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1040058

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:sympy has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The package in unstable causes an 
autopkgtest regression is sagemath as reported in bug 1040058.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=sympy



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040965: O: python-phpserialize -- Python port of PHP serialize and unserialize functions

[Bastian Germann]

Package: wnpp

The maintainer has retired, so I am orphaning the package.

Description:
This module implements the Python serialization interface (eg: provides 
dumps, loads and similar functions).


Please only consider adopting the package if you can afford the time and 
have the skills to maintain it.

Bug#1040704: #1040704: check_running_kernel fails to find version on bookworm/armhf as well

[Holger Levsen]

control: retitle -1 check_running_kernel fails to find version on 
bookworm/(arm64|armhf)
thanks

hi,

I can confirm this bug affects armhf as well:

holger@jtx1a:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-10-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 
(2023-07-03) != Linux version 6.1.0-10-arm64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP 
Debian 6.1.37-1 (2023-07-03)]

holger@jtx1a:~$ dpkg -l |grep linux-image ; dpkg --print-architecture ; uname -a
ii  linux-image-5.10.0-23-arm64:arm645.10.179-1  arm64  
  Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-10-arm64:arm64 6.1.37-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-9-arm64:arm64  6.1.27-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64:arm64  6.1.37-1arm64  
  Linux for 64-bit ARMv8 machines (meta-package)
armhf
Linux jtx1a 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 GNU/Linux

I can also confirm the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1033791;filename=0001-Extend-fix-for-on-disk-version-detection-on-Bookworm.patch;msg=15
to be working:

holger@jtx1a:~$ sudo sed -i "s#grep 'Linux version' | head -n1#grep 'Linux 
version' | tail -n1#" /usr/lib/nagios/plugins/check_running_kernel
holger@jtx1a:~$ /usr/lib/nagios/plugins/check_running_kernel
OK: Running kernel matches on disk image: [Linux version 6.1.0-10-arm64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 (2023-07-03)]

And this also affects armhf systems running with an arm64 kernel:

holger@virt64c:~$ /usr/lib/nagios/plugins/check_running_kernel
WARNING: Running kernel does not match on-disk kernel image: [Linux version 
6.1.0-10-arm64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 
(2023-07-03) != Linux version 6.1.0-10-arm64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) # SMP 
Debian 6.1.37-1 (2023-07-03)]

holger@virt64c:~$ sudo sed -i "s#grep 'Linux version' | head -n1#grep 'Linux 
version' | tail -n1#" /usr/lib/nagios/plugins/check_running_kernel
holger@virt64c:~$ /usr/lib/nagios/plugins/check_running_kernel
OK: Running kernel matches on disk image: [Linux version 6.1.0-10-arm64 
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU 
Binutils for Debian) 2.40) #1 SMP Debian 6.1.37-1 (2023-07-03)]

holger@virt64c:~$ dpkg -l |grep linux-image ; dpkg --print-architecture ; uname 
-a
ii  linux-image-5.10.0-23-arm64:arm645.10.179-1  arm64  
  Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-10-arm64:arm64 6.1.37-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-6.1.0-9-arm64:arm64  6.1.27-1arm64  
  Linux 6.1 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64:arm64  6.1.37-1arm64  
  Linux for 64-bit ARMv8 machines (meta-package)
armhf
Linux virt64c 6.1.0-10-arm64 #1 SMP Debian 6.1.37-1 (2023-07-03) aarch64 
GNU/Linux


-- 
cheers,
Holger

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

We can send billionaires to space but not kids to fully funded public schools.


signature.asc
Description: PGP signature

Bug#1040976: crowdsec: only looks at traditional log files

[Cyril Brulebois]

Package: crowdsec
Version: 1.4.6-4
Severity: serious
Justification: maintainer/upstream's judgement

Hi,

One critical thing that was missed during the bookworm release cycle is
that crowdsec's default configuration only checks traditional log files.
In particular: /var/log/auth.log to detect failed SSH logins.

That was fine in Debian 11, but with rsyslog's Priority being lowered
from important to optional in Debian 12, the traditional log files are
no longer produced and we're lacking detection. :/

There are two things to consider here to provide a fix:
 - We could try and enable the journalctl datasource selectively, but
   since we're shipping the default config file marked conffiles, that
   is likely to trigger prompting users during upgrades, so that doesn't
   look too appealing. If we *don't* do that though, crowdsec's current
   version would fail to initialize the journalctl datasource if
   journald isn't available, and would error out.
 - So the current plan is to apply two changes: one updating the default
   config file, and one adjusting crowdsec's behaviour when it comes to
   unavailable datasources: logging and continuing instead of failing.

Upstream has:
 - https://github.com/crowdsecurity/crowdsec/pull/2316 to update the
   config file.
 - 
https://github.com/crowdsecurity/crowdsec/commit/a910b7becad1e06cb460949ab448d3172eb5679f
   to make sure the engine doesn't fail with an unavailable datasource.

The second one comes with a slight behavorial change: crowdsec now
errors out if there's no valid datasources. That seems way better than
running with a broken config though.


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

Bug#1040975: perl: pod2man uses CW, groff-base no longer supports this by default

[Andrew Ruthven]

Package: perl
Version: 5.36.0-7
Severity: normal

Dear Maintainer,

groff-base v1.23 has been uploaded to unstable, which disables the CW macro
by default. This causes errors like this to be generated with pod2man now:

puck@dirk:~$ pod2man /usr/share/perl/5.36.0/version.pod | nroff -man | grep CW  

troff::145: warning: cannot select font 'CW'
troff::182: warning: cannot select font 'CW'
troff::191: warning: cannot select font 'CW'
troff::205: warning: cannot select font 'CW'
troff::207: warning: cannot select font 'CW'
...

This is causing lintian to be upset when build packages, e.g.:

W: rt-extension-mergeusers-common: groff-message troff::115: 
warning: cannot select font 'CW' 
[usr/share/man/man3/RT::Extension::MergeUsers.3pm.gz:1]

This version of groff-base introduces a new option in /etc/groff/man.local:

.\" "CW" is not a portable font name, but some man pages use it anyway.
.\" Uncomment this to suppress warnings produced by such pages.  This
.\" test remaps the font to roman ("R") on nroff (terminal) devices. You
.\" might prefer to remap it to bold ("B") instead.
.\" .if n .ftr CW R

Now, is it pod2man or groff-base that is at fault here? Perl 5.38 still uses
CW in pod2man by default.

Cheers,
Andrew

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_NZ.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 perl depends on:
ii  dpkg   1.21.22
ii  libperl5.365.36.0-7
ii  perl-base  5.36.0-7
ii  perl-modules-5.36  5.36.0-7

Versions of packages perl recommends:
ii  netbase  6.4

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.45-1
ii  libterm-readline-perl-perl   1.0303-2.1
ii  make 4.3-4.1
ii  perl-doc 5.36.0-7

-- no debconf information

Bug#1040974: libscrypt: LowNMU 1.21-3.1

[Bastian Germann]

Source: libscrypt
Version: 1.21-3
Severity: wishlist

Please find the debdiff attached that I am uploading as LowNMU.
I have updated the git repo as well.diff -Nru libscrypt-1.21/debian/changelog libscrypt-1.21/debian/changelog
--- libscrypt-1.21/debian/changelog 2016-02-22 01:14:56.0 +0100
+++ libscrypt-1.21/debian/changelog 2023-07-13 14:40:40.0 +0200
@@ -1,3 +1,11 @@
+libscrypt (1.21-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Migrate repository from alioth to salsa.
+  * Remove retired uploader.
+
+ -- Bastian Germann   Thu, 13 Jul 2023 14:40:40 +0200
+
 libscrypt (1.21-3) unstable; urgency=medium
 
   * Switch Vcs-Git to https.
diff -Nru libscrypt-1.21/debian/control libscrypt-1.21/debian/control
--- libscrypt-1.21/debian/control   2016-02-22 01:04:16.0 +0100
+++ libscrypt-1.21/debian/control   2023-07-13 14:39:24.0 +0200
@@ -1,13 +1,12 @@
 Source: libscrypt
 Priority: extra
 Maintainer: Micah Anderson 
-Uploaders: Tristan Seligmann 
 Build-Depends: debhelper (>= 9)
 Standards-Version: 3.9.7
 Section: libs
 Homepage: http://www.lolware.net/libscrypt.html
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/libscrypt.git
-Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/libscrypt.git
+Vcs-Git: https://salsa.debian.org/debian/libscrypt.git
+Vcs-Browser: https://salsa.debian.org/debian/libscrypt
 
 Package: libscrypt-dev
 Section: libdevel

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Il giorno gio 13 lug 2023 alle 08:46:47 +02:00:00, Bastian Germann 
 ha scritto:
The wasted effort is writing this paragraph. If you want me to 
sponsor the upload you _must_ eliminate the unpublished revision.


Yesterday night I was pretty tired and lazy, but yeah, I'll do it now.

You do not need to upload to mentors. But with the new upstream 
version, please wait for it to pass NEW before posting the security 
fix to the security team. That is the major drawback and in case of a 
more serious bug that would have beend unacceptable.


Oh okay, now I got it. I didn't quite understand what you were trying 
to explain to be before, but now I got it. Having a security fix wait 
in NEW is not ideal. Thanks for making me realize it.



Lintian is giving me this error:


I guess that is okay.


Perfect.

I'll re-do the updates more appropriately, roughly in this order:

1. Backport the fix in unstable, and push it to the archive
2. Backport the fix in bookworm-security, and push it to the archive
3. Package the latest upstream version, and push it to mentors

Does this look ok to you?

Bug#1007809: (no subject)

[Martin Mayer]

This can be close due to

https://gitlab.gnome.org/GNOME/geary/-/commit/a14f5d4799ae3d5f81804c9501fc6aab3f5020a0

Bug#1040637: Liferea cannot load RSS feed

[Paul Gevers]

Control: reassign -1 libsoup2.4-1

Hi,

I'm pretty sure that liferea uses libsoup2.4-1 to do the actual 
downloading, hence reassigning. I think this should even go lower in the 
stack, but for that I'm less sure where it should go.


curl (but not wget) fails in the same way on that URL:
paul@mulciber ~/tmp $ curl 
https://www.eleconomista.es/rss/rss-seleccion-ee.php


Access Denied

Access Denied

You don't have permission to access 
"httpwwweleconomistaesrssrssseleccioneephp" 
on this server.

Reference184937655f16892464251a90fd4d



Paul

On 08-07-2023 10:38, Camaleón wrote:

I'm unable to get Liferea loading the following feed:

https://www.eleconomista.es/rss/rss-seleccion-ee.php


From GUI it displays:


***
There was a problem when fetching this subscription!
1. Authentication
2. Download
3. Feed Discovery
4. Parsing

Details:
HTTP 403: No tiene permiso para acceder a este recurso
***


From logs:



GUI: Enabling reader mode for 'liferea://'
< HTTP/1.1 403 Forbidden
< Soup-Debug-Timestamp: 1688804042
< Soup-Debug: SoupMessage 2 (0x55c24b3922b0)
< Mime-Version: 1.0
< Content-Type: text/html
< Content-Length: 309
< Cache-Control: max-age=0
< Date: Sat, 08 Jul 2023 08:14:02 GMT
< Connection: close
< Server-Timing: cdn-cache; desc=HIT
< Server-Timing: edge; dur=1
< Strict-Transport-Security: max-age=600
< Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
< Access-Control-Allow-Origin: *
< Server-Timing: ak_p; desc="469112_1224186702_579621971_26_12001_74_-_-";dur=1

NET: download status code: 403
NET: source after download: 
>>>https://www.eleconomista.es/rss/rss-seleccion-ee.php<<<
NET: 309 bytes downloaded
UPDATE : searching through link tags
UPDATE : No links in HTML
'https://www.eleconomista.es/rss/rss-seleccion-ee.php' for icon
'mgqtspn' found!
UPDATE : Icon 'mgqtspn' trying URL: 'https://www.eleconomista.es/rss'
UPDATE : processing request (https://www.eleconomista.es/rss)
NET: downloading https://www.eleconomista.es/rss


And no news are rendered.

The same goes for Liferea 1.13.4 (Bullseye).

Instead, Thunderbird 102.13.0 loads the feed fine.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040969: fish: Make uploader the maintainer

[Bastian Germann]

Source: fish
Version: 3.6.1-1
X-Debbugs-Cc: lu...@debian.org

Tristan has retired from the Debian project.
Mo, please consider assigning yourself the maintainership.

Bug#1039569: new dependencies

[georgesk]

Hello,

I adopted the package python-reportlab and upgraded it to version 4.0.4,
which is now a pure-Python package. There are still transitional
packages like python3-renderpm, but I would like to suppress them as
they are empty now.

Developers of python-biopython have already prepared the change, which
is straightforward:

Please replace 

python3-renderpm,
python3-reportlab,

by

python3-reportlab (>= 4.0.4-1~),

Features of the last version of python-reportlab are much alike features
of the previous version. One difference is that lines of code which
"import renderPM" are loading now a pure-Python module which uses also
the package python3-rlpycairo to render text as pixmaps.

I added a new debian patch which substitutes the font Vera.ttf to
default T1 fonts on the fly, when those T1 fonts cannot be found.

Thank you in advance.   Georges.



signature.asc
Description: PGP signature

Bug#1037100: cpp-httplib: CVE-2023-26130

[Bastian Germann]

Am 13.07.23 um 12:09 schrieb Andrea Pappacoda:
Il giorno gio 13 lug 2023 alle 12:08:28 +02:00:00, Bastian Germann 
 ha scritto:

2.: Please email the security team with the debdiff instead.


Ok, so they'll push it to the archive for me? Perfect!


They will tell you what to do. Sometimes they say to hand in a stable 
update (for point release) instead.

Bug#1030804: refpolicy: more rigorous validation

[Christian Göttsche]

control: severity -1 serious
control: affects -1 src:libsepol

The duplicate declaration of the filecontext

/var/log/rspamd(/.*)?

became a hard error with libsepol 3.5 and thus is preventing libsepol
from migrating to testing.

Please apply patch 0001-d-patches-drop-addition-of-existent-file-context.patch.

Bug#1040973: RFP: haunt -- static site generator written in Guile Scheme

[David Bremner]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: vagr...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: haunt
  Version : 0.3.0
  Upstream Contact: David Thompson 
* URL : https://git.dthompson.us/haunt.git
* License : GPL3+
  Programming Lang: guile (scheme)
  Description : static site generator written in Guile Scheme

  - Easy blog and Atom/RSS feed generation
  - Supports any markup language that can be parsed to SXML
  - Simple development server
  - Purely functional build process

Looks like dependencies guile-reader and guile-commonmark would also
need packaging.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmSv8O8ACgkQA0U5G1Wq
FSG7rw//Yo9Y7P8jEdP0LuBf8aO4lxVvqb6WR09APZjBffjklu71R7Xe3k4vkq1t
CSwYRg1txPfXIglR0ioZ0sBFtJFusvgWG1C1kihhRidoC2Hf/BcgqVbXuEaiy50+
Gz750qhe6W5RIRftVOigv494Il37J88M56plsH9F0EC+qjyazmcLPN5cihvSZE55
wZSvAOBslsSSrGFOPxLr3F64eUC60iEO9r2VKqYKi5oXlzMDwI6S52CH+lQl36oF
Mpj2Xw0EcFwQeIepMf89aDU5tbAl7UMJCSxgX2WXU+BbklmEq3rlI8131hQCeGRr
W1WKwKLk4MOOnje6ykbD2/qxDy0xsgBrV0RiI5aXGUcGFhnMLO34BuS1538Sibva
Ke8GHByU3gqJke4yeajG689aM+l9ZT+o7Wk/DXCWygJOZKuAj1jX8OHi+n453WlO
IBMlwTcMZ1RB6LpA55CbQhOqwm45n9ZDRCX3oRWSmQVZcPkXUGnMWPLI8MoW3peC
Ll5HQZ1rcqseKkYGIq7ksrt0KZhOVnYgCQ+6HdscUbG9hLgGPcoQqen9oQ67LAeP
3XcwYOCb2YUw8xH46zn5KDu5p4Cd+n6pu5p+0xEVCMwvLovQzlt3A3fvTSMtPfLo
h4+yRJNvNFINWxikf/MKpNfkkJYqm2F0Q6obbDPCO86QpViKaoA=
=qxnu
-END PGP SIGNATURE-

Bug#1040966: linux-image-6.1.0-9-amd64: Thinkpad T470 fails to wake from suspend after bookworm upgrade

[Caren Hern]

Package: src:linux
Version: 6.1.27-1
Severity: serious
Justification: 0 (Preface)
X-Debbugs-Cc: senc...@riseup.net

Dear Maintainer,

after a running the bookworm update I have frequent and recurring problems 
waking the machine from sleep.
I have seen two possible states after waking up:
1. Completely unresponsive with dark screen: Power LED is lit. FnLock LED 
doesn't respond. MagicSysrq doesn't work.
2. Completely unresponsive with lock screen: Screen wakes up and show the gnome 
screen. FnLock can be toggled. Otherwise no interaction possible. MagicSysrq 
doesn't do anything.

Before the upgrade Suspend to RAM worked completely fine. For some time I 
suspected tl-smapi-dkms to be the cause, but this was ruled out now (it just 
happened again after removing the package).
The only other kernel module I am aware of is the broadcom-sta-dkms. I tried to 
unload it before sleep, but the issue happened again. 

journalctl revealed no interesting messages before sleep, and nothing after a 
failed wake up.


-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 
root=UUID=2258140b-a9a9-46ab-94ae-4c5e09a007d6 ro

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[   19.930813] intel_rapl_common: Found RAPL domain uncore
[   19.930815] intel_rapl_common: Found RAPL domain dram
[   19.930817] intel_rapl_common: Found RAPL domain psys
[   19.943525] audit: type=1400 audit(1689240616.727:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=854 
comm="apparmor_parser"
[   19.947026] audit: type=1400 audit(1689240616.731:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="firejail-default" pid=853 
comm="apparmor_parser"
[   19.951740] audit: type=1400 audit(1689240616.735:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="ping" pid=847 
comm="apparmor_parser"
[   19.957230] audit: type=1400 audit(1689240616.739:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default" 
pid=855 comm="apparmor_parser"
[   19.958443] audit: type=1400 audit(1689240616.739:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default-cgns" 
pid=855 comm="apparmor_parser"
[   19.959416] audit: type=1400 audit(1689240616.739:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="lxc-container-default-with-mounting" pid=855 comm="apparmor_parser"
[   19.960453] audit: type=1400 audit(1689240616.739:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="lxc-container-default-with-nesting" pid=855 comm="apparmor_parser"
[   20.358776] Adding 12597056k swap on /dev/mapper/swap.  Priority:-2 
extents:1 across:12597056k SSFS
[   20.403115] mc: Linux media interface: v0.10
[   20.431583] videodev: Linux video capture interface: v2.00
[   20.551062] input: keyd virtual keyboard as /devices/virtual/input/input23
[   20.551189] input: keyd virtual pointer as /devices/virtual/input/input24
[   20.593068] usb 1-8: Found UVC 1.00 device Integrated Camera (5986:111c)
[   20.622551] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/input/input25
[   20.623878] usbcore: registered new interface driver uvcvideo
[   20.674648] Process accounting resumed
[   20.943691] IPv6: ADDRCONF(NETDEV_CHANGE): v-peer1: link becomes ready
[   20.944744] IPv6: ADDRCONF(NETDEV_CHANGE): v-eth1: link becomes ready
[   20.968704] usbcore: registered new device driver apple-mfi-fastcharge
[   21.009079] systemd-journald[469]: File 
/var/log/journal/2452626f3a7f4738ab5cba389727f188/user-1000.journal corrupted 
or uncleanly shut down, renaming and replacing.
[   21.304365] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   21.615076] Bluetooth: Core ver 2.22
[   21.616164] NET: Registered PF_BLUETOOTH protocol family
[   21.617211] Bluetooth: HCI device and connection manager initialized
[   21.619479] Bluetooth: HCI socket layer initialized
[   21.620499] Bluetooth: L2CAP socket layer initialized
[   21.621504] Bluetooth: SCO socket layer initialized
[   21.689563] usbcore: registered new interface driver btusb
[   21.715416] usb 1-7.1: USB disconnect, device number 4
[   21.811326] Bluetooth: hci0: BCM: chip id 73 build 1125
[   21.813302] Bluetooth: hci0: BCM: product 05ac:828d
[   21.815314] Bluetooth: hci0: BCM: features 0x07
[   21.832308] Bluetooth: hci0: BCM20702B0 Generic USB Class 1 @ 20 MHz
[   21.888108] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   21.889080] Bluetooth: BNEP filters: protocol multicast
[   21.894728] Bluetooth: BNEP socket layer initialized
[   21.899522] Bluetooth: MGMT 

Bug#1037100: cpp-httplib: CVE-2023-26130

[Bastian Germann]

Am 13.07.23 um 12:06 schrieb Andrea Pappacoda:

I'll re-do the updates more appropriately, roughly in this order:

1. Backport the fix in unstable, and push it to the archive
2. Backport the fix in bookworm-security, and push it to the archive


2.: Please email the security team with the debdiff instead.


3. Package the latest upstream version, and push it to mentors

Bug#1037100: cpp-httplib: CVE-2023-26130

[Andrea Pappacoda]

Il giorno gio 13 lug 2023 alle 12:08:28 +02:00:00, Bastian Germann 
 ha scritto:

2.: Please email the security team with the debdiff instead.


Ok, so they'll push it to the archive for me? Perfect!

Bug#996432: ITS: newlib

[Bastian Germann]

Hi John,

what is the state of this? Do you have a newlib 4.* draft ready?

Thanks,
Bastian

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Graham Inggs]

Hi Dirk

On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel  wrote:
> On 12 July 2023 at 19:47, Paul Gevers wrote:
> | On 12-07-2023 16:02, Dirk Eddelbuettel wrote:
> | > I can add the Breaks as a 'best of the worse alternative'. And, I 
> presume, I
> | > can remove the existing four-year breaks? [1]
> |
> | Yes, you only need to carry the Breaks until in the next release. So
> | every Breaks that's present in the r-base package in bookworm can be
> | removed from the r-base package in unstable.
>
> Good point and much less ugly then :)

I'll prepare a patch dropping the old and adding the new Breaks.

Regards
Graham

Bug#1040967: cpp-httplib FTBFS with googletest 1.13.0

[Adrian Bunk]

Source: cpp-httplib
Version: 0.11.4+ds-1
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/fetch.php?pkg=cpp-httplib=amd64=0.11.4%2Bds-2=1689245748=0

...
In file included from /usr/include/gtest/gtest-message.h:57,
 from /usr/include/gtest/gtest-assertion-result.h:46,
 from /usr/include/gtest/gtest.h:64,
 from ../test/test.cc:4:
/usr/include/gtest/internal/gtest-port.h:270:2: error: #error C++ versions less 
than C++14 are not supported.
  270 | #error C++ versions less than C++14 are not supported.
  |  ^
...



Removing the line
  'cpp_std=c++11',
from meson.build fixes the FTBFS.

Bug#1040968: dpkg: Less noisy output

[Julian Andres Klode]

Package: dpkg
Severity: wishlist
X-Debbugs-Cc: j...@debian.org

Users are complaining loudly that dpkg's output is too noisy,
and we should be looking at how we can improve that, currently
for each package we print at least 3 lines, and it's very
distracting:

Preparing to unpack
Unpacking
Setting up

I think these should be a rolling status line with a carriage
return at the end, such that it gets overriden by output,
but I'm not quite sure.

Optimally we'd be able to turn the output off, and control
it from apt based on the dpkg status log. And then also capture
output from maintainer script and essentially prepend the line
to the backlog when the maintainer script has output.

But not sure if that's feasible, probably needs some very
annoying manipulation of pty stuff.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1040934: bookworm-pu

[Gwyll Gwyllin]

Hello,

 

"If you're asking where's the fix for this issue in bookworm-pu (please

correct me if I guessed your question wrong), - it is not there yet."

 

I did, since you answered earlier:

"This is #1037341, fixed in sid and in bookworm-pu."
 
So . the error is fixed, but the fix is not downloadable yet. 



"BTW, your mail server seems to be misconfigured, - my email for you bounces
back"
Thank you, I'll check.
 
 
Gwyll

Bug#1040877: netavark: phasing out clap version 3.

[Reinhard Tartler]

Hi Peter,


Thanks for the report!

On 7/11/23 4:39 PM, Peter Green wrote:

Please consider moving to clap v4.



Gladly. The thing is, netavark and aardvark-dns need to be updated in lockstep. 
I've started looking into this, and then got stuck with a number of additional 
required dependencies. I'm currently stuck at 'rust-mozim', which in turn drags 
in a number of additional deps, such as ethtool, and (potentially required) 
version upgrades to the various netlink and rtnetlink packages.

Let's coordinate on IRC/matrix for packaging those dependencies.

Thanks,
-rt

Bug#1040970: libwebp: Please package new upstream release 1.3.1 with libsharpyuv

[Boyuan Yang]

Source: libwebp
Version: 1.2.4-0.2
Tags: sid trixie
X-Debbugs-CC: f...@debian.org j...@debian.org

Dear Debian libwebp maintainer,

As previously discussed in https://bugs.debian.org/1022001 , we have a need
for a separate libsharpyuv library, which is available only after libwebp
v1.3.0. For Debian 12 Bookworm release, we postponed the preparation of
new libwebp for stability. Now that Debian Bookworm has been released, it is
the time to do the packaging for new version.

Thanks,
Boyuan Yang


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

Bug#1040971: RFP: hyprland -- dynamic tiling Wayland compositor based on wlroots

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: hyprland
  Version : 0.27.1
  Upstream Contact: vaxerski  
* URL : https://github.com/hyprwm/Hyprland
* License : BSD-3-Clause
  Programming Lang: C++
  Description : dynamic tiling Wayland compositor based on wlroots

- From the readme: 
" 
Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn't 
sacrifice on its looks.
It supports multiple layouts, fancy effects, has a very flexible IPC model 
allowing for a lot of customization, a powerful plugin system and more.
"

Packaging-wise it'll be complicated. hyprland embeds multiple subprojects [0]. 
hyprland-protocols [1] would need to be a seperate source package; this is 
easily doable from a
quick glance. A fork of udis86 [2] is also embedded; coincidently I prepared 
some initial udis86 packaging for ppsspp so this won't be that much of an issue.
The third embedded project is wlroots [3] which will be the biggest problem imo 
as hyprland (statically) links onto the latest wlroots HEAD which will be hard 
to
devendor, if not impossible. 

I built hyprland locally and ran it for a bit; it looks promising but still has 
some (minor) bugs and quirks imo.
I don't have time to package or maintain this atm but I might get back to it at 
some point.
This bugreport is to document the progress/work needed for hyprland.

[0] https://github.com/hyprwm/Hyprland/tree/main/subprojects
[1] https://github.com/hyprwm/hyprland-protocols
[2] https://github.com/canihavesomecoffee/udis86 
[3] https://github.com/hyprwm/Hyprland/blob/main/subprojects/wlroots

regards, 

Matthias Geiger

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmSv6yAVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1FfEP/3l0+CAcsuHWj5XiUPjQs2QmJFGp
6I9KAiI0ZSaVFZo9215x/M1bmGoFy4SDc3BotHvjrTH4zijb3z+IR5osyq1heiqS
M/r318uF5eQqJfzwoV9OGjn+/rAG/+ssH3MjWbOZ1N8IM+/yVK3gGzsQ23RVzbWQ
nFrNNJ3ZFeZE3Fo8nOArRdyAMvoSkLjbEoBpBTUg5/xoAQosTZ42nyFZuWkgebUW
+8JLHdnzCbKAm6ggWOFfN8zcwxDF66XaOo/RoBtzFsKB8JnDwxXaJngG5MhCLTaS
4msqyRE8XRu/ocTN1farIWPp8PQuXZE3qTlf6jIdFn5+vdLx6hbGhhXzrRqmFY1C
6vzIf5JgZ2DYvduACrFbYRuLzW/RwZnaJnobVT5SeUfmqIaF1uJIeDdDx3M1L7tk
j9sIrL1CDMpS2x0mTFh5TMMXV5rdpB6mZiy1C69khaaLe6Sf/uh8N+dhwyK/phWn
1NjI0DzI7C/xCTHClPkxbGM19KnTmBWOwTTpInf40BUABfVt+81QxXtIhl3gPYBe
IclGqBIsUPG1TZn1Dhk3x4AYR+lb0stsnM3YTyXfLUM2KtwcuYp7oaNqitHfO3fm
XJvDrrP/W1r77LHHlSVTWoh8DuZUATMOpJQ3Wr9TdKO0lSJQr75tNWcvcIavpejt
qO4B+3+/xLepI3L7
=d9Ch
-END PGP SIGNATURE-

Bug#1040972: libwebp: Please consider the switch to CMake buildsystem

[Boyuan Yang]

Source: libwebp
Version: 1.2.4-0.2
Tags: sid trixie
X-Debbugs-CC: f...@debian.org j...@debian.org

Dear Debian libwebp maintainer,

Package libwebp has been built using autotools. However, there is an
emerging need to use CMake build system in order to provide related
config files, such as 
https://bugs.launchpad.net/ubuntu/+source/libwebp/+bug/2013083 .
Please consider switching the build system to CMake.

Thanks,
Boyuan Yang


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

Bug#1019494: localepurge: uses egrep and fgrep: fgrep/egrep: warning: egrep is obsolescent; using grep -F/-E

[sov6rk+f2st9r1qfysds]

Package: localepurge
Version: 0.7.3.10
Followup-For: Bug #1019494

Dear Maintainer,

This issue has now bit Debian 12 Bookworm stable, localepurge now reports many 
warnings about egrep/fgrep being obsolete when run.

Note: on my system I disabled the debian patch that removes the warning from 
/bin/egrep and /bin/fgrep because I want to be informed when tools still use 
the obsolete non-standard syntax, and localepurge is one of those tools.

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Following up with that, it seems that the failure is due to a change in 
the kernel.


I'm testing 2 Kali netinst ISOs, one from last week (no problem), and a 
daily iso from today (which fails).


Last weekly iso had kernel 6.1.0-kali9-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives nothing, hence the grub-installer 
postinst doesn't try to mount the efivarfs.


Today's iso has kernel 6.3.0-kali1-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives `nodev efivarfs`, hence the 
grub-installer postinst tries to mount efivarfs, and fails.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1031975: kodi: Windowed kodi takes wrong size when run under KDE Plasma Wayland with fractional scaling

[Mark Cookson]

In case anyone else encounters this problem, a workaround is to run:
 kodi --windowing=x11

which will bypass any problems with scaling under Wayland

Bug#1040934: Missing USB and other support in qemu

[Michael Tokarev]

13.07.2023 02:29, Gwyll Gwyllin wrote:

Hi,

„You didn't mention what's up with "other support in qemu", though.„

Sorry. Here  I read this:

„Please don't report multiple unrelated bugs — especially ones in different 
packages — in a single bug report.”


Well yes. The thing is that you mentioned some "other" in your bug report but
neither gave information about this "other" in the same bug report nor filed
another bug report for this "other", so it's confusing.


I don’t know if those are related, but:

in a domU config file I can’t use:

  * device_model
  * device_model_override

or the domU will not start.


What's the error message?  Also, it would be great if you provide the qemu 
command line
when xen starts your domU with these options.  I know right to nothing about 
xen, so I
need help with this one.


„This is #1037341, fixed in sid and in bookworm-pu.”

I upgraded from bullseye … probably to bookworm.

12.0 is bookworm, right?


Yes 12 is bookworm.  The fix for the lack of USB aren't in bookworm yet, as I
mentioned in other reply.

BTW, your mail server seems to be misconfigured, - my email for you bounces back
with "Timeout connecting to mail.gwyll.eu port 25" error message.

/mjt

Bug#1040860: bookworm-pu: package mrtg/2.17.10-5+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Tue, Jul 11, 2023 at 02:07:17PM -0300, Joao Eriberto Mota Filho wrote:
> [ Reason ]
> Older versions of the MRTG on Debian had the /etc/mrtg.cfg configuration
> file. Currently, this file is located in /etc/mrtg/ directory. This PU
> introduces changes from Sid (revision 2.17.10-6) to ask to user if the
> configuration file must be moved to /etc/mrtg/, if it exists in /etc/.
> Some updated and new translations for the debconf template are being sent
> with this PU (from revisions 2.17.10-7 and 2.17.10-8). This PU closes
> #1039103.

Please go ahead.

On aother note, some of the templates look like they would benefit from a
review by debian-l10n-engl...@lists.debian.org. That's not necessary for
this upload, just something to consider.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1040960: gcc-sh-elf binary-all build rejected

[Adrian Bunk]

Source: gcc-sh-elf
Version: 7
Severity: serious
Tags: ftbfs

bunk@coccia:~$ cat  
/srv/ftp-master.debian.org/queue/reject/gcc-sh-elf_7_all-buildd.changes.reason

Version check failed:
Your upload included the binary package libnewlib-sh-elf-dev, version 
3.3.0-1.3+7, for all,
however testing already has version 3.3.0+6.
Uploads to unstable must have a higher version than present in testing.
bunk@coccia:~$


Fixing #996432 including the upgrade would be one way to fix
this problem.

Bug#1040963: src:starpu: fails to migrate to testing for too long: unsatisfiable dependency on armel, mipsel and s390x + segfault

[Paul Gevers]

Source: starpu
Version: 1.3.10+dfsg-2
Severity: serious
Control: close -1 1.4.1+dfsg-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:starpu has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. According to the migration 
software, the new version of libstarpu-dev can't be installed on armel, 
mipsel and s390x. Additionally the autopkgtest segfaults on armhf.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=starpu



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040924: clevis-udisks2: Depends on NBS libblockdev-crypto2

[Christoph Biedl]

Control: Tags 1040924 +pending

Jeremy Bícha wrote...

> Yes, it's a transition. Sorry that it didn't follow the recommended procedure.

Thanks for the clarification. New version is underway, I'd like to do
some thourough testing, though.

Christoph


signature.asc
Description: PGP signature

Bug#1040958: bluezalsa: D-Bus policy is installed in /etc instead of /usr

[Gioele Barabucci]

Package: bluezalsa
Version: 4.0.0-2
Tags: patch

Dear bluezalsa maintainers,

bluez-alsa-utils installs its D-Bus policy file in `/etc/dbus-1`. Since 
Debian 9 the standard directory for package-installed dbus policies is 
`/usr/share/dbus-1`.


See: https://bugs.debian.org/1006631

Lintian complains with `dbus-policy-in-etc`.

A patch to fix this issue is available at

https://salsa.debian.org/bluetooth-team/bluez-alsa/-/merge_requests/1


Regards,

--
Gioele Barabucci

Bug#1040959: rust-sequoia-sq: build dependency got updated

[Paul Gevers]

Source: rust-sequoia-sq
Version: 0.27.0-2
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertag: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting issues with your packages. Normally your build 
dependencies shouldn't be removed from testing without removal all 
reverse build dependencies too, nor should a package be allowed to 
migrate unless all build dependencies are candidate for migration too. 
However, somehow we ended up in the current state and your source 
package is missing some Build-Depends for some while now. Not being able 
to build from source in a suite is an RC bug in that suite.


Can you please solve the situation?

Paul

[1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040165: pacemaker: Migration regression after upgrading bullseye to bookworm

[Ferenc Wágner]

Florent Carli  writes:

> I could not reproduce with the packages you mentionned, so it's a good sign

Hi,

Pacemaker 2.1.5-1+deb12u1 is already available in the
bookworm-proposed-updates archive.  It also contains the two other
patches Ken mentioned [1], please give it some testing if you can.

[1] https://bugs.clusterlabs.org/show_bug.cgi?id=5521#c10.
-- 
Thanks,
Feri.

Bug#1040807: Processed: Re: Bug#1040807: debian-reference: typo hdparam(8) -> hdparm(8)

[肖盛文]

Hi,
    I fixed PO files.

I used bluefish to deal with fuzzy lines in PO files,
and use sed -i s/ // *.po to deal with typo.


在 2023/7/12 17:35, Osamu Aoki 写道:


For these trivial typo fix, you may fix PO files if you have extra time.

Osamu


Regards,

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040964: src:slixmpp: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: slixmpp
Version: 1.8.3-1
Severity: serious
Control: close -1 1.8.4-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1040057

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:slixmpp has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. There was bug 1040057 filed about 
the version in unstable failing it's autopkgtest on arm64.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=slixmpp



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037100: cpp-httplib: CVE-2023-26130

[Bastian Germann]

Am 13.07.23 um 00:40 schrieb Andrea Pappacoda:
I'd prefer not to remove the experimental 0.12 from the changelog, since 
I have already uploaded everything to git and mentors. It's also 
something that actually happened, but I simply didn't find a sponsor in 
time and a new unstable release was prepared before uploading the 
experimental one. Unless I really _must_ remove the experimental entry 
from the changelog and git history I'd prefer to keep everything as is; 
it just looks like wasted effort to me, and I'd like to spend my time 
packaging a new yuzu version instead 


The wasted effort is writing this paragraph. If you want me to sponsor 
the upload you _must_ eliminate the unpublished revision.


I've uploaded the bookworm-security branch on Git, see 
. I'm unable to upload it to mentors because bookworm-security hasn't been added to the site yet.


You do not need to upload to mentors. But with the new upstream version, 
please wait for it to pass NEW before posting the security fix to the 
security team. That is the major drawback and in case of a more serious 
bug that would have beend unacceptable.



I think that everything is ok, but Lintian is giving me this error:


I guess that is okay.

Bug#1040783: libvirt-daemon: libvirt firewalld zone is missing

[Niccolò Belli]

Il 2023-07-13 08:05 Nick Hastings ha scritto:
I'm facing the same problem. I'm running virt-manager on the localhost 
as
a user who is a member of the libvirt group. What did you actually run 
as

root to have the libvirt zone created?


Nothing, I've just connected to virt-manager using the ssh root account 
instead and virt-manager automatically took care of everything during 
the routed virtual network creation.

Bug#1040961: src:wike: fails to migrate to testing for too long: build depends on version in experimental

[Paul Gevers]

Source: wike
Version: 1.8.2-1
Severity: serious
Control: close -1 2.0.1-3
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:wike has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. It seems you're waiting for a 
build dependency that is only available in experimental.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=wike



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040406: python3-azure-cli - fails with No module named 'azure.mgmt.compute.v2022_11_01'

[Ross Vandegrift]

Package: azure-cli
Version: 2.45.0-1
Followup-For: Bug #1040406
X-Debbugs-Cc: rvandegr...@debian.org

Hi Luca,

I'm hitting this issue on azure-cli in bookworm.  It sounds like this package
is difficult - but is there any possibility of a stable update?


$ az vm
The command failed with an unexpected error. Here is the traceback:
No module named 'azure.mgmt.compute.v2022_11_01'
...

Thanks,
Ross


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

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

Versions of packages azure-cli depends on:
ii  python33.11.2-1+b1
ii  python3-azure-cli  2.45.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#1040680: node-openpgp-seek-bzip 1.0.5-2+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040680 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: node-openpgp-seek-bzip
Version: 1.0.5-2+deb12u1

Explanation: correct installation of files in seek-bzip package

Bug#1040756: spip 4.1.9+dfsg-1+deb12u2 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040756 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: spip
Version: 4.1.9+dfsg-1+deb12u2

Explanation: security fix (authentication data filtering)

Bug#1040921: dkms 3.0.10-8+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1040921 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: dkms
Version: 3.0.10-8+deb12u1

Explanation: add Breaks against obsolete, incompatible *-dkms packages

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  wrote:
> The Ubuntu diff contains a patch that looks like a workaround 
(untested).


This patch says data directory is reserved for golang autopkgtest in 
Ubuntu. Is this the same on debian too? If yes, that looks like a bad 
idea to me.

Bug#1040108: mercurial: deprecation of Python libraries asyncore and asynchat

[Julien Cristau]

Control: tag 1040108 upstream
Control: tag 1040121 upstream
Control: forwarded 1040108 https://bz.mercurial-scm.org/show_bug.cgi?id=6700
Control: forwarded 1040121 https://bz.mercurial-scm.org/show_bug.cgi?id=6727

On Sat, Jul  1, 2023 at 21:44:30 -0400, Louis-Philippe Véronneau wrote:

> In Python 3.6, asyncore and asynchat have been formally marked as
> deprecated. Code that imports these libraries will no longer work from
> Python 3.12, which is currently in Trixie.
> 
On Sat, Jul  1, 2023 at 22:03:40 -0400, Louis-Philippe Véronneau wrote:

> In Python 3.5.4, smtpd has been formally marked as deprecated. Code that
> imports this library will no longer work from Python 3.12, which is
> currently in Trixie.
> 
> Since mercurial use this Python library, please prepare for this removal and
> migrate away from them.
> 
Basically these boil down to tests/dummysmtpd.py needing to be rewritten.
Unless/until that happens we'll have to skip test-patchbomb-tls.t.

Cheers,
Julien

Bug#1040978: sbuild: Please also mention "directory" is available for "--extra-package" in manpage synopsis

[Boyuan Yang]

Package: sbuild
Severity: wishlist
Version: 0.85.2
Tags: sid patch

Dear Debian sbuild maintainers,

The question in thread started at 
https://lists.debian.org/debian-devel/2023/07/msg00167.html
show the need to mention that --extra-package also accepts a directory as 
parameter in the
man page synopsis section. I am proposing the following patch:

diff --git a/man/sbuild.1.in b/man/sbuild.1.in
index b1fcf70f..5d7ac8f8 100644
--- a/man/sbuild.1.in
+++ b/man/sbuild.1.in
@@ -99,7 +99,7 @@ sbuild \- build debian packages from source
 .RB [ \-\-setup\-hook=\fIhook-script\fP ]
 .RB [ \-\-build\-dep\-resolver=\fIresolver\fP ]
 .RB [ \-\-resolve\-alternatives \[or] \-\-no\-resolve\-alternatives ]
-.RB [ \-\-extra\-package=\fIpackage.deb\fP ]
+.RB [ \-\-extra\-package=\fIpackage.deb|directory\fP ]
 .RB [ \-\-extra\-repository=\fIspec\fP ]
 .RB [ \-\-extra\-repository\-key=\fIfile.asc\fP ]
 .RB [ \-\-build\-path=\fIstring\fP ]

Please consider applying this patch.

Best,
Boyuan Yang


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

Bug#1040973: RFP: haunt -- static site generator written in Guile Scheme

[Vagrant Cascadian]

On 2023-07-13, David Bremner wrote:
> * Package name: haunt
...
> Looks like dependencies guile-reader and guile-commonmark would also
> need packaging.

Looks like guile-reader, guile-commonmark and haunt look likely to be
fairly trivial to package... see the recently packaged guile-avahi for a
simple example.

I am not sure I am up for being haunted with three more guile packages!

... that said, haunt is available in guix, which is available in Debian,
and is the main reason I maintain any guile packages at all! :)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1040954: Acknowledgement (inspircd: PID and Logging have broken permissions)

[Victor Coss]

Hello, I have an update. I have talked to the head developer of 
InspIRCd, Sadie and figured out a few things.


Firstly, the PID is not required for the sslrehashsignal module as you 
can send the required signal using systemd, systemctl kill 
--signal=SIGUSR1 inspircd.service. So you can keep the --nopid flag in 
the systemd service, that is not an issue.


However, the logging is broken because you do not pass --system at 
configure. Instead you define directories which logdir is not accounted 
for so it ends up as /usr/lib/inspircd/logs/ instead of 
/var/log/inspircd/ in the AppArmor profile, as this profile is 
automatically generated at compile time based on the directories that 
are defined.


In ./configure do *not* pass prefix, config-dir, module-dir, 
example-dir, data-dir, and binary-dir. Just pass *--system* and it will 
account for these system-wide directories. Please see 
https://docs.inspircd.org/packaging/ for more information on how to 
package inspircd.


Also FYI, the  and  configuration options in the 
/etc/inspircd/inspircd.conf you ship are deprecated, you should probably 
remove those to prevent issues in the future when InspIRCd is updated.


Thank you,
Victor Coss

On 7/12/2023 11:21 PM, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

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

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

Your message has been sent to the package maintainer(s):
  Filippo Giunchedi

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

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

Bug#1040644: [INTL:ro] Translation-revision of "apt" to Romanian

[David Kalnischkies]

On Wed, Jul 12, 2023 at 10:24:12PM +, Remus-Gabriel Chelu wrote:
>   first of all, I must admit that in the translation process, I peek at
> the translations made by the other Latin teams (I studied also French
> in the school, and I have lived in Spain for 20 years), so at least
> in part , the reported errors/"sins", are due to this.

I would classify these as "mistake" at most 


> În miercuri 12 iulie 2023 14:41:44 (+02:00), David Kalnischkies a scris:
>> On Sat, Jul 08, 2023 at 01:04:28PM +, Remus-Gabriel Chelu wrote:
>> | +# Advanced Package Transfer - APT message translation catalog
>
>   "Sinning" because of the French/Spanish team, but... a search for
> "Advanced Package Transfer" or "APT message translation catalog" in the
> "po/" directory will yield more surprises.
>
>> | +# Copyright © 2002-2023 Free Software Foundation, Inc.
>>
>> Are you, like, sure?
>
>   Same as above, "sinning" because of the Spanish team, but... a search for
> "Free Software Foundation, Inc" in the "po/" directory,
> will "sing, bingo!" more than once.

Removing things is hard, especially if it includes the word "Copyright"
and as long as the "rewind" mode of my time machine is broken I am
trying to focus on not adding too many new potentially future problems
at least. Sounds like double-standard, but you have to start somewhere
and given how old apt is and through how many hands it has passed in all
those years its kind of a mess.


>   Regarding using the git commands, you have to admit that the "curious"
> would have to do a «git clone» first, before they can use the git search/show
> commands, which I think is too much of a "disturbance" for the ultimate
> goal of satisfying this curiosity.

Well, you can browse/search our version control system online in various
places, including salsa, but I get what you mean and if you think its
important I see no problem for us with it.



>> | "Language-Team: Romanian \n"
>
>   I don't know/understand what you meant here.

(You picked up on what I meant, so this is just for completeness)

The line is included in the first msgstr in the po file – although it
includes the email address, but I suppose your mail client might have
eaten that… so manually HTML encoded:
| "Language-Team: Romanian debian-l10n-roman...@lists.debian.org\n"


> PS2: Please help me with a clear example for the new message that appeared
> in version apt 2.7.2: "Missing Signed-By in the %s entry for '%s'";

An example would be:
| N: Missing Signed-By in the sources.list(5) entry for 
'http://example.org/debian'

So, "Signed-By" is an option mentioned in the pointed to man page and
should probably not be translated (as I am not a huge fan of this
message I will refrain from commenting that one further).


Best regards

David Kalnischkies

P.S.: Attached is a refreshed ro.po file with initial file, the changes
discussed here and our upstream 2.7.2 merged together.


ro.po.gz
Description: application/gzip


signature.asc
Description: PGP signature

Bug#1040957: xine-lib-1.2: FTBFS on hurd-i386

[Patrick Matthäi]

Am 13.07.2023 um 07:05 schrieb Pino Toscano:

Source: xine-lib-1.2
Version: 1.2.13+hg20230710-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Control: found -1 1.2.12-1

Hi,

xine-lib-1.2 currently FTBFSes on hurd-i386 [1].

The problem is that the VAAPI support is not available on hurd-i386,
and libxine2-x unconditionally installs files that are built for that.
The attached patch fixes the issue, by limiting the VAAPI plugins that
were not already limited on some architectures (e.g. the wayland one)
as !hurd-any, like the libva-dev build dependency.

As I was tweaking/fixing the packaging for hurd-i386, I included also
few more Hurd-related changes:
- enable the smb plugin also on the Hurd, as samba is now built there
- change the exclusion architecture pattern for the vcdo plugin to
   !hurd-any, as it applies to any Hurd architecture and not only to
   hurd-i386

[1] 
https://buildd.debian.org/status/fetch.php?pkg=xine-lib-1.2=hurd-i386=1.2.13%2Bhg20230710-1=1689013434=0

Thanks,
Thank you very much for your patch and improvements, I will include it 
with the next upload

Bug#1011625: mercurial: autopkgtest regression on s390x

[Julien Cristau]

Control: retitle -1 mercurial: test-convert-svn-encoding.t fails on s390x

On Sun, Mar 26, 2023 at 20:08:31 +0200, Paul Gevers wrote:

> tags 1011625 serious
> user release.debian@packages.debian.org
> usertag 1011625 bookworm-can-defer
> retitle 1011625 mercurial: autopkgtest regression
> thanks
> 
> Hi,
> 
> On Wed, 25 May 2022 15:03:58 +0200 Graham Inggs  wrote:
> > Sometime between 2021-10-16 and 2021-11-25 [1], mercurial's
> > autopkgtests regressed on s390x in testing.
> 
> It now regressed everywhere.
> 
Please don't mix unrelated issues in the same bug.  Retitling back to
focus on the s390x convert-svn-encoding issue.  If there's something
else on other architectures then they need their own report.

Cheers,
Julien

Bug#1040929: gcc-13-cross-ports: please add arm64 to HOST_ARCHS_

[Emanuele Rocca]

Hi Matthias,

On 2023-07-12 08:22, Matthias Klose wrote:
> how will you care about build time regressions?  The change is not
> difficult, however I'd like to see some commitment how to deal with these
> issues.

Happy to help should any issues arise.

FWIW there's no need to enable all arches in one go, we could start with
a subset (one or more of m68k, hppa, sh4, and sparc64?) if we want to be
extra cautious.

  Emanuele

Bug#1040977: htdig built without SSL support

[Dianne Skoll]

Package: htdig
Version: 1:3.2.0b6-19+b1
Severity: important

Dear Maintainer,

The version of htdig shipped with Debian Bookworm is built without SSL support
and cannot index HTTPS sites.

The simple fix is to add "--with-ssl" to the configure invocation in
debian/rules; I have built my own debian packages with this change and
have verified that it works.

Regards,

Dianne.


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

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

Versions of packages htdig depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9
ii  libstdc++6 12.2.0-14
ii  lockfile-progs 0.1.19
ii  perl   5.36.0-7
ii  zlib1g 1:1.2.13.dfsg-1

htdig recommends no packages.

Versions of packages htdig suggests:
ii  apache2 [httpd]  2.4.57-2
pn  htdig-doc

-- Configuration Files:
/etc/htdig/footer.html changed [not included]
/etc/htdig/header.html changed [not included]
/etc/htdig/htdig.conf changed [not included]
/etc/htdig/nomatch.html changed [not included]

-- debconf information excluded

Bug#1040980: grimripper: Buffer overflow

[Vigar]

Package: grimripper
Version: 3.0.2-1
Severity: important
X-Debbugs-Cc: vi...@free.fr

Dear Maintainer,

the software open, I can set the options but when I click on the Rip button,
grimripper close with *** buffer overflow detected ***: terminated message in
the console.

Best regards,


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grimripper depends on:
ii  cdparanoia3.10.2+debian-14
ii  libc6 2.37-5
ii  libcddb2  1.3.2-7
ii  libglib2.0-0  2.74.6-2
ii  libgtk-3-03.24.37-2

Versions of packages grimripper recommends:
ii  flac  1.4.3+ds-2
ii  lame  3.100-6
ii  vorbis-tools  1.4.2-1+b1
ii  wavpack   5.6.0-1

grimripper suggests no packages.

-- no debconf information

Bug#986223: Much newer version available

[Paul Hecker]

Package: python3-pg8000
Version: 1.10.6-2
Followup-For: Bug #986223

Dear Maintainer,

is it still intended to upgrade this package? Besides installing a newer
version (with pip and --break-system-packages) there is no way of
installing a more current version than this 7 years old version.

Reason for me is that Bareos needs a more recent version (1.16) to WAL
backup my PostgreSQL database.

Again, please consider updating this package to a more recent versio!

Thanks,
Paul


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

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

Versions of packages python3-pg8000 depends on:
ii  python3  3.11.2-1+b1
ii  python3-six  1.16.0-4

python3-pg8000 recommends no packages.

Versions of packages python3-pg8000 suggests:
pn  python-pg8000-doc  

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture

[Venkata.Pyla]

Package: klibc-utils
Version: 2.0.12-1
Severity: normal

Hi,

I observed segfaults in armhf architecture when executing any of the
binaries /usr/lib/klibc/bin/{fstype, ls, cat, ...}, same is not seen in
amd64 and arm64 architectures.

This issue originally occurred when I am updating initramfs using
command `update-initramfs -u` which internally [1] uses klibc binary
`/usr/lib/klibc/bin/fstype` to check the fstype, it doesn't stop
creating initramfs but it creates core dumps in the rootfs and that
makes our images non-reproducible.

Follow below steps to reproduce this issue
```
$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
http://deb.debian.org/debian/
$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
```

Expectation:
It should not generate core dumps

Kindly suggest us what is going wrong where all the binaries are generating 
core dumps in armhf architecture?

[1] 
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.142/hooks/fsck?ref_type=tags#L55


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_IN, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to 
default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages klibc-utils depends on:
ii  libklibc  2.0.12-1

klibc-utils recommends no packages.

klibc-utils suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_IN:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "en_IN"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Shengjing Zhu]

Control: reopen -1

Hi,

On Thu, Jul 13, 2023 at 6:09 PM Pirate Praveen  wrote:
>
> On Thu, 9 Feb 2023 14:40:48 +0100 Sebastian Ramacher
>  wrote:
>  > Source: golang-github-go-enry-go-license-detector
>  > Version: 4.3.0+git20221007.a3a1cc6-1
>  > Severity: serious
>  > Tags: ftbfs
>  > Justification: fails to build from source (but built successfully in
> the past)
>  >
>  >
> https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-1%2Bb2=1675941345=0
>  >
>
> This looks like a temporary error, last build was passing
>
> https://buildd.debian.org/status/fetch.php?pkg=golang-github-hhatto-gorst=mipsel=0.0%7Egit20181029.ca9f730-2%2Bb6=1681037294=0

You look at the wrong log, it's golang-github-hhatto-gorst, not
golang-github-go-enry-go-license-detector.
It FTBFS on buildd currently.

-- 
Shengjing Zhu

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Nilesh Patra]

Control: tags -1 patch

On Thu, Jul 13, 2023 at 03:10:40PM +0530, Pirate Praveen wrote:
> On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  wrote:
> > The Ubuntu diff contains a patch that looks like a workaround (untested).
> 
> This patch says data directory is reserved for golang autopkgtest in Ubuntu.
> Is this the same on debian too? If yes, that looks like a bad idea to me.

AFAIK, it uses the standard AUTOPKGTEST_TMP directory which is the
standard across debian. I got the same impression on skimming through
dh-golang code.

As far as fix for your package is concerned, it is as simple as avoiding
to remove entire data directory (which is just 28K in size). I'm able to get
autopkgtests passing locally. Patch pasted
inline.

From 7aa6fc7ccf9bb7b938d290bc1e2eab2b324fb7ff Mon Sep 17 00:00:00 2001
From: Nilesh Patra 
Date: Thu, 13 Jul 2023 21:22:59 +0530
Subject: [PATCH] Avoid removing entire data dir during dh_install step

---
 debian/rules | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index c858f56..28c01cd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,5 +7,4 @@ export DH_GOLANG_INSTALL_EXTRA := data

 override_dh_install:
dh_install -O--builddirectory=_build -O--buildsystem=golang 
-O--with=golang
-   rm -rf 
debian/golang-github-hhatto-gorst-dev/usr/share/gocode/src/github.com/hhatto/gorst/data
rm -rf 
debian/golang-github-hhatto-gorst-dev/usr/share/gocode/src/github.com/hhatto/gorst/*.html
--
2.39.2


signature.asc
Description: PGP signature

Bug#1040928: (no subject)

[Patrick Schleizer]

duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032408

Bug#1040985: metis: New upstream release (v5.2.1, 2022 Dec 5)

[Florian Ernst]

Source: metis
Version: 5.1.0.dfsg-7
Severity: wishlist

Dear maintainer,

there is a new upstream release available at
 provided by one of the
original authors, cf. .

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1040774: msolve FTBFS on 32bit: test failure and hang

[Torrance, Douglas]

Control: severity -1 important

On Thu 13 Jul 2023 12:21:48 PM -04, Doug Torrance  
wrote:

[[PGP Signed Part:Undecided]]
Control: forwarded -1 https://github.com/algebraic-solving/msolve/issues/66

On Mon 10 Jul 2023 03:33:43 PM +03, Adrian Bunk  wrote:

Source: msolve
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=msolve=0.5.0-1

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: fglm_build_matrixn_radical_shape-31
PASS: neogb_io
PASS: fglm_build_matrixn_nonradical_shape-31
PASS: fglm_build_matrixn_nonradical_radicalshape-31
FAIL: test/diff/diff_elim-qq.sh
PASS: test/diff/diff_elim-31.sh
PASS: test/diff/diff_F4SAT-31.sh
FAIL: test/diff/diff_kat6-31.sh
FAIL: test/diff/diff_eco11-31.sh
E: Build killed with signal TERM after 150 minutes of inactivity


[[End of PGP Signed Part]]


The latest upload (0.5.0-2) of msolve skips the tests on 32-bit architectures
so that it will still build.  The issue has been reported upstream and hopefully
will be fixed in a future release.

Since the program still works for some inputs on these architectures, I'm
dropping the severity of the bug to "important".


signature.asc
Description: PGP signature

Bug#1040943: systemd-logind: 'HandlePowerKey=ignore' works in logind.conf, not in logind.conf.d/custom.conf

[Michael Biebl]

Am 12.07.23 um 20:39 schrieb Diederik de Haas:

Package: systemd
Version: 253.5-1
Severity: normal

I'm working on a Debian system/image for Pine64's PineTab2 (tablet) and
by default when I (short) press the power button, the device powers off.
Right now I'm not using any DE, so it's a CLI only system.

When I created /etc/systemd/logind.conf.d/custom.conf with
HandlePowerKey=ignore


If this is the whole content of /etc/systemd/logind.conf.d/custom.conf, 
you are missing a [Login] section at the top of the file


Rule of thumb: Please always attach such configuration data verbatim to 
the bug report.

Makes it much easier for us.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040986: ipcalc: New upstream release (0.51, 2021 Nov 3)

[Florian Ernst]

Source: ipcalc
Version: 0.42-2
Severity: wishlist

Dear maintainer,

there is a new upstream release available at
 (as linked to from
), apparently consolidating many patches
(including some from you) and applying some further changes.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1040982: libexttextcat: New upstream release (3.4.6, 08-Nov-2021)

[Florian Ernst]

Source: libexttextcat
Version: 3.4.5-1
Severity: wishlist

Dear maintainer,

there is a new upstream release available at
, adding support for
some more languages / variants.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1040983: RM: libncurses5-dev libncursesw5-dev libtinfo-dev -- NBS; uninstallable, superseded by libncurses-dev

[Sven Joachim]

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

Please remove the binary packages libncurses5-dev, libncursesw5-dev and
libtinfo-dev from unstable.  They are no longer built from src:ncurses
and are not installable.

The daily cruft report[1] lists a lot of broken Depends and
Build-Depends, but they are in fact all fulfilled by libncurses-dev
which has a versioned Provides on libncurses5-dev, libncursesw5-dev and
libtinfo-dev.


1. https://ftp-master.debian.org/cruft-report-daily.txt

Bug#1040979: write_files: defer not working any more

[Sven Strickroth]

Package: cloud-init
Version: 22.4.2-1
Severity: important
X-Debbugs-Cc: em...@cs-ware.de

Dear Maintainer,

starting with the shipped version in Debian 12 the write_files feature with 
defer option does not work any more.

Example:
#cloud-config
locale: de_DE.UTF-8
timezone: Europe/Berlin
package_update: true # Implied with `package_upgrade: true`
package_upgrade: true
packages: 
['joe','mariadb-server','aptitude','psmisc','bzip2','fail2ban','postfix','apticron','nagios-nrpe-server','monitoring-plugins','libmariadb3','borgbackup','logwatch']
write_files:
- content: |
[mysqldump]
max_allowed_packet = 60M
  path: /etc/mysql/mariadb.conf.d/51-dump.cnf
  defer: true

The file /etc/mysql/mariadb.conf.d/51-dump.cnf is not created any more 
(compared to Debian 11; 20.4.1-2+deb11) by cloud-init. Nothing can be seen in 
the logs.

This significantly limits how cloud-init can be used to set up new machines.

Providing an updated version as backport etc. does not help as cloud-init is 
particularly used to set up a machine from a plain base image. It would be 
important to get a fix in the next point release.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloud-init depends on:
ii  eject  2.38.1-5+b1
ii  fdisk  2.38.1-5+b1
ii  gdisk  1.0.9-2.1
ii  isc-dhcp-client4.4.3-P1-2
ii  locales2.36-9
ii  lsb-release12.0-1
ii  procps 2:4.0.2-3
ii  python33.11.2-1+b1
ii  python3-configobj  5.0.8-1
ii  python3-jinja2 3.1.2-1
ii  python3-jsonpatch  1.32-2
ii  python3-jsonschema 4.10.3-1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-oauthlib   3.2.2-1
ii  python3-requests   2.28.1+dfsg-1
ii  python3-serial 3.5-1.1
ii  python3-yaml   6.0-3+b2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  util-linux 2.38.1-5+b1

Versions of packages cloud-init recommends:
ii  cloud-guest-utils  0.33-1
ii  eatmydata  130-2
ii  sudo   1.9.13p3-1

Versions of packages cloud-init suggests:
ii  btrfs-progs  6.2-1
ii  e2fsprogs1.47.0-2
ii  xfsprogs 6.1.0-1

-- no debconf information

Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote:
> On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote:
> > [ Reason ]
> > https://bugs.debian.org/1040790
> > [ Changes ]
> > All changes are part of resolving or testing #1040790.
> 
> Debdiff attached.
> 
> > [ Tests ]
> 
> I should also have mentioned that I'm running the proposed package on
> a bookworm desktop system and it works normally.
> 

Please go ahead, bearing in mind that the window for 12.1 closes over
the coming weekend.

Regards,

Adam

Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2023-07-11 at 20:51 +0200, Aurelien Jarno wrote:
> The upstream stable branch got a few fixes during the bookworm freeze
> period, and this update pulls them into the debian package. In short:
>  - Fix a buffer overflow and memory corruption in the gmon
>functionality.
>  - Fix a deadlock in getaddrinfo() and system() functions
>  - Fix y2038 support in strftime on 32-bit architectures.
>  - Fix possible segmentation fault in applications using sgetsgent()
>when /etc/gshadow contains very long lines
>  - Fix support for old C90 compilers.
> 
> In addition this include a Slovak translation update fixing typos,
> that
> 

Please go ahead, bearing in mind that the window for 12.1 closes over
the coming weekend.

Regards,

Adam

Bug#1040982: libexttextcat: New upstream release (3.4.6, 08-Nov-2021)

[Rene Engelhard]

Hi,

Am 13.07.23 um 18:08 schrieb Florian Ernst:

there is a new upstream release available at
, adding support for
some more languages / variants.


Oops, indeed. November 2021.. Bummer...


Regards,


Rene

Bug#1040774: msolve FTBFS on 32bit: test failure and hang

[Torrance, Douglas]

Control: forwarded -1 https://github.com/algebraic-solving/msolve/issues/66

On Mon 10 Jul 2023 03:33:43 PM +03, Adrian Bunk  wrote:

Source: msolve
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=msolve=0.5.0-1

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: fglm_build_matrixn_radical_shape-31
PASS: neogb_io
PASS: fglm_build_matrixn_nonradical_shape-31
PASS: fglm_build_matrixn_nonradical_radicalshape-31
FAIL: test/diff/diff_elim-qq.sh
PASS: test/diff/diff_elim-31.sh
PASS: test/diff/diff_F4SAT-31.sh
FAIL: test/diff/diff_kat6-31.sh
FAIL: test/diff/diff_eco11-31.sh
E: Build killed with signal TERM after 150 minutes of inactivity




signature.asc
Description: PGP signature

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Dirk Eddelbuettel]

Hi Graham,

On 13 July 2023 at 11:14, Graham Inggs wrote:
| On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel  wrote:
| > On 12 July 2023 at 19:47, Paul Gevers wrote:
| > | Yes, you only need to carry the Breaks until in the next release. So
| > | every Breaks that's present in the r-base package in bookworm can be
| > | removed from the r-base package in unstable.
| >
| > Good point and much less ugly then :)
| 
| I'll prepare a patch dropping the old and adding the new Breaks.

Sounds good, and thanks for the assist! I should be able to provide a pretty
quick turn-around.

Onwards!

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1040984: lsyncd: New upstream release (2.3.1, 2022 Nov 17)

[Florian Ernst]

Source: lsyncd
Version: 2.2.3-1
Severity: wishlist

Dear maintainer,

there are two new upstream releases available at
, their changes include

| 2.3.1 - Squeaker Latest
| - multiple bugfixes
| - code cleanup
| 
| 2.3.0 - Spell of Resurrection
| This is the first release since quite a while and under new the new 
maintainer @poelzi
| Not only does the release fix many outstanding issues, it also contains quite 
a few additions.
| 
| Whats new
| - nix flake support
| - support for tunnel commands
| - support for batchSizeLimit
| - -onepass option
| - crontab support
| - support relative executable paths
| What's Changed
| - Fix typo: width => with by @msabramo in #380
| - default.collect: Print target by @msabramo in #379
| - Fix typo: Exlcusions => Exclusions by @msabramo in #378
| - Updated lbash.lua and lrsync.lau to remove the equals (=) by @mralexjuarez 
in #398
| - fix: direct mode allows injecting unauthorized filesystem operations by 
@wodny in #349
| - config file url by @gsouf in #459
| - Add example config for syncing with an AWS S3 bucket by @danielkza in #463
| - Fix for non-versioned lua not being searched in Cmake by @yokogawa-k in #500
| - Enable ssh._extra args by @taylor-s-dean in #583
| - Remove /System/Volumes/Data from fsevent paths on macOS by @ajdavis in #615
| - version format in lua.h changed by @j1cken in #568
| - add -onepass option, allowing exit after initial sync by @cleary in #541
| - Expose rsync's copy_unsafe_links by @rotu in #567
| - Fixed typo at readme.md by @schneiderl in #538
| - allow deleting excluded files with rsync by @tomjnixon in #595
| - fix error - bad binary format (version mismatch) by @CoolTuxNet in #656

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1039695: libtracker-sparql-3.0-0: keeps segfaulting and restarting endlessly

[Bernhard Übelacker]

Hell Mulas,
I tried to get to the source line of you dmesg output:



[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 
24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 
c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



I think this relates to this source line:

https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);


But a full backtrace is probably still needed by the maintainer.
You could probably collect one by installing systemd-coredump.
Then journalctl should contain a more detailed information on
which functions are involved.

Kind regards,
Bernhard



https://wiki.debian.org/HowToGetABacktrace
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4 == 0b100
 *   bit 0 ==0: no page found   
 *   bit 1 ==0: read access 
 *   bit 2 ==1: user-mode access
.




[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 
8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 
08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



echo -n "find /b ..., ..., 0x" && \
echo "18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 
8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d 
de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'
#





apt install gdb tracker-miner-fs tracker-miner-fs-dbgsym 
libtracker-sparql-3.0-0-dbgsym



gdb -q --args /usr/libexec/tracker-miner-fs-3

set width 0
set pagination off
tb main
run

pipe info share | grep libtracker-sparql-3.0

find /b 0x77b4e120,  0x77bb49f2, 0x18, 0x64, 0x48, 0x2b, 0x04, 
0x25, 0x28, 0x00, 0x00, 0x00, 0x75, 0x35, 0x48, 0x83, 0xc4, 0x20, 0x5b, 0xc3, 
0x48, 0x8b, 0x44, 0x24, 0x10, 0x48, 0x8d, 0x15, 0x84, 0xdd, 0x04, 0x00, 0xbe, 
0x08, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x3d, 0xfd, 0x77, 0x04, 0x00, 0x48, 0x8b, 
0x48, 0x08, 0x31, 0xc0, 0xe8, 0x5d, 0xde, 0xfd, 0xff, 0x48, 0x8b, 0x7c, 0x24, 
0x10, 0xe8, 0x03, 0xda, 0xfd, 0xff, 0xeb

b * (0x77b6dbee + 42)

(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77b6dc18 in setup_interface_cb at 
../src/libtracker-sparql/core/tracker-data-manager.c:4050
(gdb) disassemble /r 0x77b6dbee, 0x77b6dbee + 62
Dump of assembler code from 0x77b6dbee to 0x77b6dc2c:
   0x77b6dbee :  18 64 48 2b sbb
%ah,0x2b(%rax,%rcx,2)
   0x77b6dbf2 :  04 25   add
$0x25,%al
   0x77b6dbf4 :  28 00   sub
%al,(%rax)
   0x77b6dbf6 :  00 00   add
%al,(%rax)
   0x77b6dbf8 :  75 35   jne
0x77b6dc2f 
   0x77b6dbfa :  48 83 c4 20 add
$0x20,%rsp
   0x77b6dbfe :  5b  pop
%rbx
   0x77b6dbff :  c3  ret
   0x77b6dc00 :  48 8b 44 24 10  mov
0x10(%rsp),%rax
   0x77b6dc05 : 48 8d 15 84 dd 04 00lea
0x4dd84(%rip),%rdx# 0x77bbb990
   0x77b6dc0c : be 08 00 00 00  mov
$0x8,%esi
   0x77b6dc11 : 48 8d 3d fd 77 04 00lea
0x477fd(%rip),%rdi# 0x77bb5415
>>>0x77b6dc18 : 48 8b 48 08 mov
>>>0x8(%rax),%rcx
   0x77b6dc1c : 31 c0   xor
%eax,%eax
   0x77b6dc1e : e8 5d de fd ff  call   
0x77b4ba80 
   0x77b6dc23 : 48 8b 7c 24 10  mov
0x10(%rsp),%rdi
   0x77b6dc28 : e8 03 da fd ff  call   
0x77b4b630 
End of assembler dump.


https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);

Bug#1032708: please drop transitional package libtinfo-dev from src:ncurses

[Sven Joachim]

Control: tags -1 - moreinfo

On 2023-03-12 14:44 +, Holger Levsen wrote:

> On Sun, Mar 12, 2023 at 03:36:33PM +0100, Sven Joachim wrote:
>> After taking a closer look, this seems to be all red herring.  Sbuild
>> uses apt for resolving the build dependencies, and while apt prefers
>> virtual packages over real ones, it has no problem to use the virtual
>> one (libncurses-dev in this case) in case the real one is uninstallable
>> or insufficient.
>>
>> I guess I'll drop the transitional packages in an upload to experimental
>> and see what happens with the pseudo-excuses[1].
>
> cool!

Everything went well, and the transitional packages are no longer in
testing. :-)

>> Filing bugs against reverse (build-)dependencies would be doable for
>> libtinfo-dev, but for libncursesw5-dev (#1032740) and libncurses5-dev
>> (for which you did not file a bug, for whatever reason) this is a
>
> I did: #1032741

Err, of course.  Somehow I managed to overlook that bug.

>> non-starter due to the large number of them.
>
> bug filing can be scripted ;)

Surely, but filing 300+ bugs to get rid of three empty packages is still
a very bad ratio and causes a lot of busy work which is not really
necessary.  Rather, I filed _one_ bug against ftp.debian.org[1] to remove
the cruft packages from unstable where they currently remain.

FWIW, what I did looks like a good strategy for other transitional
packages with lots of reverse (build-)dependencies, maybe you would like
to inform their maintainers of it.

Cheers,
   Sven


1. https://bugs.debian.org/1040983

Bug#1030955: golang-github-hhatto-gorst: autopkgtest failure

[Pirate Praveen]

On Thu, 13 Jul 2023 21:24:53 +0530 Nilesh Patra  
wrote:

> Control: tags -1 patch
>
> On Thu, Jul 13, 2023 at 03:10:40PM +0530, Pirate Praveen wrote:
> > On Fri, 10 Feb 2023 00:07:51 +0200 Adrian Bunk  
wrote:
> > > The Ubuntu diff contains a patch that looks like a workaround 
(untested).

> >
> > This patch says data directory is reserved for golang autopkgtest 
in Ubuntu.
> > Is this the same on debian too? If yes, that looks like a bad idea 
to me.

>
> AFAIK, it uses the standard AUTOPKGTEST_TMP directory which is the
> standard across debian. I got the same impression on skimming through
> dh-golang code.
>
> As far as fix for your package is concerned, it is as simple as 
avoiding
> to remove entire data directory (which is just 28K in size). I'm 
able to get

> autopkgtests passing locally. Patch pasted
> inline.

Thanks. I guess I was over enthusiastic to suppress

I: golang-github-hhatto-gorst-dev: 
package-contains-documentation-outside-usr-share-doc 
[usr/share/gocode/src/github.com/hhatto/gorst/data/autopep8.readme.rst]


and did not notice the autopkgtest failure then.

I'm uploading the fix you suggested.

Bug#1040956: systemd: Internal USB devices disconnected when `udevadm settle` run in early boot

[Michael Biebl]

Am 13.07.23 um 06:14 schrieb Undef:

Package: systemd
Version: 253.5-1
Severity: important
X-Debbugs-Cc: debian@undef.tools

Dear Maintainer,

On upgrade to systemd 253.5-1 the USB modem on my Librem5 stopped
working. This also occurs on 252.11-1 (testing) but not on 252.6-1
(stable) or 253-3 (previously available in unstable.

This only seems to happen in a very specific configuration:
   * Librem5
   * Booting from eMMC
   * Using full disk encryption
   * Using an on-screen keyboard such as osk-sdl to unlock the device.

Digging into the issue, it seems I can trigger it by adding an initramfs
script which will run `udevadm settle` in the initramfs. This itself
doesn't remove the USB device, but later in the boot the device will
disappear.


Since this is hardware specific, my recommendation would be, that you 
run a git bisect (between 252.6 and 252.11) to find the commit which is 
causing this issue for you.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040991: gcc-13: consider stripping lto1 / cc1 / cc1plus

[Matthias Klose]

On 13.07.23 20:15, Mateusz Łukasik wrote:

Source: gcc-13
Version: 13.1.0-8
Severity: minor


Dear Maintainer,

Like it was before in #783876 #894014 #1015185 gcc-13 package in contain 
unstripped debug

info.


we will do that after a while

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work

[Jeremy Davis]

FWIW it appears that this bug is essentially a duplicate of #770171:

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

On 7/7/23 19:04, José Miguel Gonçalves wrote:

As Debian opted by systemd journal as the default logging mechanism for 
bookworm, maybe a better option would be to change the default 
configuration in '/etc/fail2ban/jail.conf' to select journal as the 
logging source, i.e., instead of setting 'backend = auto', set 'backend 
= systemd'.


That seems like a sensible suggestion to me.

Can you confirm that the current default bookworm fail2ban config/regex 
works with sshd with just this change (to 'backend' in 
/etc/fail2ban/jail.conf)? Or are further adjustments required?


Regards,
Jeremy


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012859: Info received (Syslog)

[Nicholas D Steeves]

Dear Leslie,

I'm sorry no one noticed your bug.  Reply follows inline:

Jeremy, thank you for following up on this bug!  This brought the bug to
my attention :)

Leslie Rhorer  writes:

> On 7/13/2023 5:18 PM, Jeremy Davis wrote:
>> [Just a random passer-by that might have an idea?]
>>
>> It looks to me like you are missing the firmware-realtek[1][2] 
>> (non-free) package?!
>
>      No, I am not missing it.  The package is broken in Bullseye. The 
> firmware is there, but does not work.  It worked just fine in Buster, 
> but when I upgraded to Bullseye, the 10G NIC completely quit working.  
> It's been over a year, so I don't recall everything I did, but I spent 
> many, many hours trying to get the new firmware working, and many more 
> hours trying to extract the firmware from the oldstable package, and 
> then quite a few more hours trying  to compile from source, but nothing 
> worked.  I could not even get the source code to compile.

Given your intention to upgrade from buster to bullseye, here is what
you can try (please read to the end of this email first, because an
alternative method is a better use of your time):

1a. Enable bullseye-backports (non-free), and 'apt install -t
bullseye-backports firmware-linux firmware-misc-nonfree' which is
currently 20230210-4~bpo11+1

2a. Reboot

3a. If both your NICs work, then it's a firmware bug.  If this is the
case, please report a bug against firmware-linux-nonfree 20210315-3.

--

1b. If the steps above are insufficient, 'apt install -t
bullseye-backports linux-image-amd64' which is currently
6.1.20-2~bpo11+1

2b. Reboot.  GRUB should automatically choose the backports kernel.

3b. Your NICs should work at this point.  If they do, and you'd like to
report a bug against the linux-image-amd64 version in bullseye, then
please go ahead and do so, but please make sure that you've tested
5.10.178-3 before doing so:)

>      The bottom line is the firmware from the Buster non-free distro 
> works perfectly well, but noone has come forth with a fix for Bullseye, 
> and I have no reason to believe the firmware from Bookworm will work.  
> The NIC is an Asus PEB-10G/57811-1S 10GbE SFP+ Network Adapter which 
> employs a BCM 57811S controller.

Maybe nobody knows that this specific hardware is broken?  It may be
that the Asus PEB-10G/57811-1S has some hardware quirks that Broadcom
doesn't know about.  In your original bug log you'll notice this snippet

 RTL8211E Gigabit Ethernet

which is the Realtek one, Gibabit, RJ45 copper.  I wonder if this one is
a completely different NIC built into your motherboard.  ie: the
historically very buggy Realtek 8111E?

Alternatively, if the 10GbE SFP+ PCIe adapter NIC uses a Realtek for
gigabit PHY, then the nature of the bug could be that both both Realtek
and Broadcom broke your NIC (either in the firmware on in the driver, or
both).

>> If you haven't already tried, I'd suggest that you try a clean 
>> bookworm install from ISO. FWIW bookworm now includes a separate 
>> "non-free-firmware" repo that is enabled by default. So the official 
>> installer should "just work".
>      I can try, but I really would not be well advised to do so until I 
> can get the dead system working again.

Jeremy is right about how bookworm includes non-free-firmware by
default, and also that the state of your hardware with bookworm should
be tested first.

The best use of your time will be to test with live media (USB or DVD).
If you'd like to have a GUI for your test, please choose a variant you
recognise and are comfortable with.  The "standard" flavour is CLI only,
which--alternatively--might be what you want (it's a smaller download ).

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

If the problem still exists in bookworm, then it needs to be fixed in
bookworm before the fix can be backported to buster, and the live media
is the fastest way to test this.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1026118: thunderbird: please add support for riscv64

[Bo YU]

Source: thunderbird
Version: 1:115.0~b6-1
Followup-For: Bug #1026118

Dear Maintainer,

I have updated the patch that supported riscv64 target. And I think it
should work because we got firefox package now[0].

This time I rebased on 115.0~b6 on experimentail.
Could you give a try when you upload it next time?
Please let me know any issues.
TIA.


[0]: https://buildd.debian.org/status/logs.php?pkg=firefox=riscv64

-- 
Regards,
--
  Bo YU

diff -Nru thunderbird-115.0~b6/debian/changelog 
thunderbird-115.0~b6/debian/changelog
--- thunderbird-115.0~b6/debian/changelog   2023-06-30 02:13:46.0 
+0800
+++ thunderbird-115.0~b6/debian/changelog   2023-07-14 09:29:49.0 
+0800
@@ -1,3 +1,10 @@
+thunderbird (1:115.0~b6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support riscv64. (Closes: #1026118)
+
+ -- Bo YU   Fri, 14 Jul 2023 09:29:49 +0800
+
 thunderbird (1:115.0~b6-1) experimental; urgency=medium
 
   * [1d7c51d] New upstream version 115.0~b6
diff -Nru thunderbird-115.0~b6/debian/control 
thunderbird-115.0~b6/debian/control
--- thunderbird-115.0~b6/debian/control 2023-06-23 04:02:03.0 +0800
+++ thunderbird-115.0~b6/debian/control 2023-07-13 21:53:37.0 +0800
@@ -62,7 +62,7 @@
 Standards-Version: 4.6.2
 
 Package: thunderbird
-Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64
+Architecture: amd64 arm64 i386 mips64el ppc64el s390x ppc64 riscv64
 Depends:
  debianutils (>= 1.16),
  fontconfig,
diff -Nru thunderbird-115.0~b6/debian/rules thunderbird-115.0~b6/debian/rules
--- thunderbird-115.0~b6/debian/rules   2023-06-23 04:02:03.0 +0800
+++ thunderbird-115.0~b6/debian/rules   2023-07-13 21:56:03.0 +0800
@@ -108,6 +108,9 @@
 ifeq (32,$(DEB_BUILD_ARCH_BITS))
echo 'ac_add_options --disable-debug-symbols' >> mozconfig.default
 endif
+ifeq (riscv64,$(DEB_BUILD_ARCH))
+   echo 'ac_add_options --disable-debug-symbols' >> mozconfig.default
+endif
echo 'mk_add_options MOZ_OBJDIR=$(CURDIR)/obj-thunderbird' >> 
mozconfig.thunderbird
echo 'ac_add_options --prefix=$(CURDIR)/debian/tmp/usr' >> 
mozconfig.default
# configure the various build settings for thunderbird


signature.asc
Description: PGP signature

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*

An interesting data point (here on a bullseye/amd64 system):

$ /usr/lib/klibc/bin/fstype --help
--help: No such file or directory
$ /lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so  /usr/lib/klibc/bin/fstype --help
Segmentation fault (core dumped)

So running the interpreter directly is already not supported.
I’m guessing that that is what qemu-user tries, though.

Wild shoot into the blue but maybe it helps…

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1041003: clang-15: Crash in PowerPC DAG->DAG Pattern Instruction Selection

[Sylvestre Ledru]

Hello,

Le 13/07/2023 à 22:21, Cordell Bloor a écrit :

Package: clang-15
Version: 1:15.0.7-6
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

On ppc64el, the clang compiler crashed on buildd [1] during the
compilation of test_block_sort.cpp in the rocprim package. We're only
compiling HIP programs for ppc64el on a best-effort basis, as it is not
an officially supported architecture upstream. Nevertheless, a compiler
crash seemed to be worth reporting. I've reproduced this problem on my
local machine in a QEMU VM.

There were also linking errors related to half-floats in the build log
(__truncdfhf2), but that is unrelated. I fixed that bug in rocm-hipamd
locally before reproducing the crash.

The full log is linked below, but I'll include a snippet inline:

Stack dump:
0.  Program arguments: /usr/lib/llvm-15/bin/clang -cc1
-triple powerpc64le-unknown-linux-gnu -aux-triple amdgcn-amd-amdhsa
<>
/<>/test/rocprim/test_block_sort.cpp
1.   parser at end of file
2.  Code generation
3.  Running pass 'Function Pass Manager' on module 
'/<>/test/rocprim/test_block_sort.cpp'.
4.  Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on 
function
'@_ZN53RocprimBlockSortTestsFloating_CustomSortKeyValue_TestI12block_paramsI6__halfS1_Lj64EEE8TestBodyEv'

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=rocprim=ppc64el=5.3.3-6=1689203881=0


Does it happen with clang-16 ?

could you please try to provide a testcase with creduce ?

thanks

S

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work

[José Miguel Gonçalves]

Hi Jeremy,

On 13/07/23 23:01, Jeremy Davis wrote:
Can you confirm that the current default bookworm fail2ban 
config/regex works with sshd with just this change (to 'backend' in 
/etc/fail2ban/jail.conf)? Or are further adjustments required? 


Yes, I can confirm that fail2ban sshd jail works fine using the default 
config and just changing the 'backend' to 'systemd'.


Best regards,
José Gonçalves

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Thorsten Glaser]

retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks

venkata.p...@toshiba-tsip.com dixit:

>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
>qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>Segmentation fault
>```

Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
against klibc :/

My guess here is that it’s, as usual, the fault of qemu-user,
which has multiple outstanding emulation bugs, some of which
affecting klibc-built binaries especially, though this, since
a statically linked mksh works, is probably an issue with how
qemu-user handles .interp *shrug*

Since your one-stage debootstrap succeeds, can you not do the
remaining steps booting into the image-under-preparation and
run them there? Here, qemu-system-armhf should probably suffice.
I know, it’s just as a workaround, until the people in question
figure out why this happens.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Helge Deller]

Can you check if this patch fixes the problem:
https://patchew.org/QEMU/mvmpm55qnno@suse.de/
(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
Schwab)
 Ursprüngliche Nachricht Von: Thorsten Glaser  
Datum: 14.07.23  00:48  (GMT+01:00) An: venkata.p...@toshiba-tsip.com, 
1040...@bugs.debian.org, pkg-qemu-de...@lists.alioth.debian.org Cc: 
dinesh.ku...@toshiba-tsip.com Betreff: Bug#1040981: klibc-utils: Segmentation 
fault while executin klibc binaries in armhf architecture under qemu-user 
retitle 1040981 klibc-utils: segfault executing armhf binaries under 
qemu-userthanksvenkata.p...@toshiba-tsip.com dixit:>Follow below steps to 
reproduce this issue>```>$ sudo debootstrap --arch=arm bookworm 
arm-bookworm-rootfs/ http://deb.debian.org/debian/>$ sudo chroot arm-bookworm/ 
apt-update && apt install -y klibc-utils>$ sudo chroot arm-bookworm/ 
/usr/lib/klibc/bin/fstype --help>qemu: uncaught target signal 11 (Segmentation 
fault) - core dumped>Segmentation fault>```Same when just copying 
klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so outof libklibc_2.0.12-1_armhf.deb into 
/lib/ and extracting fstypefrom klibc-utils_2.0.12-1_armhf.deb… however it 
works both on areal-metal ARM box (amdahl.d.o) and a statically(!) linked 
mkshagainst klibc :/My guess here is that it’s, as usual, the fault of 
qemu-user,which has multiple outstanding emulation bugs, some of whichaffecting 
klibc-built binaries especially, though this, sincea statically linked mksh 
works, is probably an issue with howqemu-user handles .interp *shrug*Since your 
one-stage debootstrap succeeds, can you not do theremaining steps booting into 
the image-under-preparation andrun them there? Here, qemu-system-armhf should 
probably suffice.I know, it’s just as a workaround, until the people in 
questionfigure out why this happens.bye,//mirabilos-- Solange man keine 
schmutzigen Tricks macht, und ich meine *wirklich*schmutzige Tricks, wie bei 
einer doppelt verketteten Liste beidePointer XORen und in nur einem Word 
speichern, funktioniert Boehm ganzhervorragend.   -- Andreas Bogk über 
boehm-gc in d.a.s.r

Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures

[Pirate Praveen]

Control: fixed -1 4.3.0+git20221007.a3a1cc6-3

On Thu, 13 Jul 2023 23:49:56 +0800 Shengjing Zhu  
wrote:

> You look at the wrong log, it's golang-github-hhatto-gorst, not
> golang-github-go-enry-go-license-detector.
> It FTBFS on buildd currently.

After increasing the timeout to 150m, the build is now succeeding on 
armel and mipsel.


https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=armel=4.3.0%2Bgit20221007.a3a1cc6-3=1689278197=0

https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-3=1689281650=0

Bug#993849: RE. authenticator

[Matthias Geiger]

I uploaded the rust-gtk stack into debian which was the major missing 
chunk. If my tracking spreadsheet is correct (rust) authenticator is 
still missing five crates:


scrypt, search-provider, libadwaita, gst-plugin-gtk4 and aes-gcm. Some 
of them have more reverse dependencies. I haven't looked into it further 
and I'm a bit busy atm.


If bug #1017905 gets resolved libadwaita can enter debian; this is being 
worked on by myself and jbicha. The rest of the dependencies look 
straightforward to tackle.



If someone wants to help, feel contribute in the debian-rust team. The 
"new" application should go under the gnome teams' umbrella imho.



regards,


Matthias Geiger





OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029502: ftp.debian.org: changelog of libreoffice is unavailable

[Vincent Lefevre]

This is occurring again (after an "apt update"):

zira:~> apt changelog libreoffice
Err:1 https://metadata.ftp-master.debian.org libreoffice 4:7.5.5~rc1-5 Changelog
  Changelog unavailable for libreoffice=4:7.5.5~rc1-5 (404  Not Found [IP: 
2a04:4e42:6a::644 443])
E: Failed to fetch 
https://metadata.ftp-master.debian.org/changelogs/main/libr/libreoffice/libreoffice_7.5.5%7erc1-5_changelog
  Changelog unavailable for libreoffice=4:7.5.5~rc1-5 (404  Not Found [IP: 
2a04:4e42:6a::644 443])

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

Bug#1041014: systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: Permission dienied

[Al Ma]

Package: systemd-timesyncd
Version: 252.6-1
`systemctl restart systemd-timesyncd` says that the control process exited with 
error code. Status says, "Failed at step EXEC spawning 
/lib/systemd/systemd-timesyncd: Permission denied".
In the `output of journal  -xeu systemd-timesyncd.service` we see
systemd-timesyncd.service: Failed to execute /lib/systemd/systemd-timesyncd: 
Permission dienied
systemd-timesyncd.service: Failed at step EXEC spawning 
/lib/systemd/systemd-timesyncd: Permission dienied
…
The error number returned by this process is ERRNO.
However,
-rwxr-xr-x 1 root root 55520 28. Feb 12:15 /lib/systemd/system-timesyncd
The error appeared after upgrading from Debian 11 to Debian 12.

Bug#1040836: [Pkg-utopia-maintainers] Bug#1040836: udisks2: new udisks (auto-)mounts/unmounts fs?

[Christoph Anton Mitterer]

Control: tags -1 - moreinfo

On Tue, 2023-07-11 at 14:20 +0200, Michael Biebl wrote:
> Please provide a debug log of udisksd (run it with --debug) which
> shows 
> the mount/unmount.

Did the following just after the upgrade to 2.10.0-3:

In the unit file:
ExecStart=/usr/libexec/udisks2/udisksd --debug

# systemctl daemon-reload
# systemctl restart udisks2.service

# ps ax | grep udisksd
 505610 ?Ssl0:00 /usr/libexec/udisks2/udisksd --debug



Right after restarting it (every time) the kernel shows me:
Jul 14 05:26:00 heisenberg kernel: BTRFS: device label system-meta devid 1 
transid 16 /dev/nvme0n1p3 scanned by udisksd (505610)
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using crc32c 
(crc32c-intel) checksum algorithm
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): using free 
space tree
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): enabling ssd 
optimizations
Jul 14 05:26:00 heisenberg kernel: BTRFS info (device nvme0n1p3): auto enabling 
async discard


journalctl _SYSTEMD_UNIT=udisks2.service -f gives:
Jul 14 05:25:59 heisenberg udisksd[505215]: udisks daemon version 2.10.0 exiting
Jul 14 05:25:59 heisenberg udisksd[505610]: udisks daemon version 2.10.0 
starting
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: 
Failed to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: 
Failed to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: 
Failed to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop3' information: 
Failed to get status of the device loop3: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop4' information: 
Failed to get status of the device loop4: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop5' information: 
Failed to get status of the device loop5: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: 
Failed to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: 
Failed to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: 
Failed to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: 
Failed to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: 
Failed to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop3' information: 
Failed to get status of the device loop3: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop4' information: 
Failed to get status of the device loop4: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop5' information: 
Failed to get status of the device loop5: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: 
Failed to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: 
Failed to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop6' information: 
Failed to get status of the device loop6: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop0' information: 
Failed to get status of the device loop0: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop7' information: 
Failed to get status of the device loop7: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop1' information: 
Failed to get status of the device loop1: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: Error getting 'loop2' information: 
Failed to get status of the device loop2: No such device or address 
(g-bd-loop-error-quark, 1)
Jul 14 05:26:00 heisenberg udisksd[505610]: 

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Helge Deller]

On 7/14/23 01:56, Thorsten Glaser wrote:

Dixi quod…


My guess here is that it’s, as usual, the fault of qemu-user,


Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)


what does this show?:
QEMU_STRACE=1 qemu-arm-static -d cpu ./fstype --help

I still believe, that the problem is that qemu's brk(NULL) doesn't return
a page-aligned address, which will have lots of other side-effects.
(see Andreas' RISC-V crash here: 
https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg00645.html)

Helge

Bug#1041015: Drivers for Dell Wireless 380 Bluetooth Card wanted

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.37-1
In the journal I see red lines
firmware_class: See https://wiki.debian.org/Firmware 
https://wiki.debian.org/Firmware for information about missing firmware
bluetooth hci0: firmware: failed to load brcm/BCM20702A1-413c-8197.hcd (-2)
bluetooth hci0: firmware: failed to load brcm/BCM-413c-8197.hcd (-2)
bluetooth hci0: firmware: failed to load brcm/BCM-413c-8197.hcd (-2)
Bluetooth: hci0: BCM: firmware Patch file not found, tried:
Bluetooth: hci0: BCM: 'brcm/BCM20702A1-413c-8197.hcd'
Bluetooth: hci0: BCM: 'brcm/BCM-413c-8197.hcd'
More errors/warnings concerning bluetooth follow later. The card is a built-in 
“Dell Wireless 380 Bluetooth Card” on a Dell Mobile Precision M6700. I failed 
to find the requested files myself. Any help/remedy/fix?
(As opposed to #1013895, no USB dongles are plugged into our machine; all the 
USB ports are free.)
Gratefully,
AlMa

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Arnaud Rebillout]

Tentative fix, for what it's worth:

https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19

--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1041016: RM: pkg-mozilla-archive-keyring -- ROM; Outdated and useless

[Mike Hommey]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

As per the RC bug against the package, the key it contains is expired,
and the repository that was signed by the key has not been in use
for years. It's time to retire the package completely.

Mike

Bug#1039566: "Uncaught exception" on crypto.getRandomValues(new Uint32Array(32))

[Philipp Marek]

With the update to 115.0.2 it works again - even in the profile that was 
broken before.


Thanks!

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,

Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

And:

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/qemu-arm-static...
Downloading separate debug info for /usr/bin/qemu-arm-static...
Reading symbols from 
/home/tglase/.cache/debuginfod_client/5a14d0155c981c94a528d6468ded2c203f1e1908/debuginfo...
(gdb) r
Starting program: /usr/bin/qemu-arm-static ./fstype --help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x77ff8700 (LWP 27273)]

Thread 1 "qemu-arm-static" received signal SIGSEGV, Segmentation fault.
0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) at 
./include/qemu/bswap.h:329
Download failed: Invalid argument.  Continuing without source file 
./b/user-static/./include/qemu/bswap.h.
329 ./include/qemu/bswap.h: No such file or directory.
(gdb) bt
#0  0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) 
at ./include/qemu/bswap.h:329
#1  0x0045c9ac in translator_lduw_swap (do_swap=false, pc=, env=0xcbed30)
at ./include/exec/translator.h:178
#2  arm_lduw_code (sctlr_b=false, addr=, env=0xcbed30) at 
../../target/arm/arm_ldst.h:44
#3  thumb_tr_translate_insn (dcbase=0x7fffdd50, cpu=) at 
../../target/arm/translate.c:9054
#4  0x004bc1e9 in translator_loop (ops=0xa7f180 , 
db=db@entry=0x7fffdd50,
cpu=cpu@entry=0xcb6a60, tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../accel/tcg/translator.c:103
#5  0x00463eb3 in gen_intermediate_code (cpu=cpu@entry=0xcb6a60,
tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../target/arm/translate.c:9283
#6  0x00512d75 in tb_gen_code (cpu=cpu@entry=0xcb6a60, pc=3670264, 
cs_base=0, flags=1196288,
cflags=-16777216, cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
#7  0x004b4734 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, 
cpu=0xcb6a60)
at ../../accel/tcg/cpu-exec.c:414
#8  cpu_exec (cpu=cpu@entry=0xcb6a60) at ../../accel/tcg/cpu-exec.c:770
#9  0x00422608 in cpu_loop (env=env@entry=0xcbed30) at 
../../linux-user/arm/cpu_loop.c:237
#10 0x00402949 in main (argc=, argv=0x7fffe230, 
envp=)
at ../../linux-user/main.c:882
(gdb) info r
rax0x40d94000  1087979520
rbx0x7fffdd50  140737488346448
rcx0xd9a72814264104
rdx0xc64d6012995936
rsi0x3800f83670264
rdi0xcbed3013364528
rbp0x0 0x0
rsp0x7fffdc48  0x7fffdc48
r8 0xc64d6012995936
r9 0xc656e812998376
r100x0 0
r110x0 0
r120xcbed3013364528
r130x0 0
r140x0 0
r150x7fffdd50  140737488346448
rip0x4c5cb60x4c5cb6 
eflags 0x10246 [ PF ZF IF RF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) disas
Dump of assembler code for function cpu_lduw_code:
   0x004c5ca0 <+0>: movQWORD PTR fs:0xff58,0x1
   0x004c5cad <+13>:movesi,esi
   0x004c5caf <+15>:movrax,QWORD PTR [rip+0x79efa2]# 
0xc64c58 
=> 0x004c5cb6 <+22>:movzx  eax,WORD PTR [rax+rsi*1]
   0x004c5cba <+26>:movQWORD PTR fs:0xff58,0x0
   0x004c5cc7 <+39>:ret
End of assembler dump.


The content of rax (guest_base) looks legit:

$ cat /proc/27269/maps
0040-00401000 r--p  fd:00 2624234
/usr/bin/qemu-arm-static
00401000-0071e000 r-xp 1000 fd:00 2624234