Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Daniel Kahn Gillmor]

On Sat 2024-04-06 11:40:14 +0800, Sean Whitton wrote:
> On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote:
>
>> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
>>> Thanks, but can you sign this off?  Ty!
>>
>> Sure, attached.  Let me know if you need anything different.
>
> Thanks.  Unfortunately, it doesn't seem to fix the FTBFS, on sid.

Here is a replacement patch, tested now against mypy 1.9.0-4.  It also
updates the typechecking for imap-dl for the same version of mypy.

 --dkg

From 6d27aa566d64a3e8cbc6afa4e61f5f8178edb14e Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 30 Jan 2024 15:40:58 -0500
Subject: [PATCH] email-print-mime-structure, imap-dl: clean types with mypy
 1.9.0

(and, update copyright years)

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 22 ++
 imap-dl| 14 +-
 2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index b7646e0..3263da9 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -2,7 +2,7 @@
 # PYTHON_ARGCOMPLETE_OK
 # -*- coding: utf-8 -*-
 
-# Copyright (C) 2019 Daniel Kahn Gillmor
+# Copyright (C) 2019-2024 Daniel Kahn Gillmor
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -39,6 +39,7 @@ import subprocess
 
 from argparse import ArgumentParser, Namespace
 from typing import Optional, Union, List, Tuple, Any
+from types import ModuleType
 from email.charset import Charset
 from email.message import Message
 
@@ -47,8 +48,9 @@ try:
 except ImportError:
 pgpy = None
 
+argcomplete:Optional[ModuleType]
 try:
-import argcomplete #type: ignore
+import argcomplete
 except ImportError:
 argcomplete = None
 
@@ -74,7 +76,7 @@ class MimePrinter(object):
 # FIXME: it looks like we are counting chars here, not bytes:
 nbytes = len(z.as_string())
 else:
-payload:Union[List[Message], str, bytes, None] = z.get_payload()
+payload = z.get_payload()
 if not isinstance(payload, (str,bytes)):
 raise TypeError(f'expected payload to be either str or bytes, got {type(payload)}')
 # FIXME: it looks like we are counting chars here, not bytes:
@@ -106,7 +108,7 @@ class MimePrinter(object):
 else:
 if z.get_content_type().lower() == 'application/pkcs7-mime' and \
str(z.get_param('smime-type')).lower() == 'signed-data':
-bodypart:Union[List[Message],str,bytes,None] = z.get_payload(decode=True)
+bodypart = z.get_payload(decode=True)
 if isinstance(bodypart, bytes):
 unwrapped = self.pipe_transform(bodypart, ['certtool', '--p7-show-data', '--p7-info', '--inder'])
 if unwrapped:
@@ -118,7 +120,7 @@ class MimePrinter(object):
 
 
 def decrypt_part(self, msg:Message, flavor:EncType) -> Optional[Message]:
-ciphertext:Union[List[Message],str,bytes,None] = msg.get_payload(decode=True)
+ciphertext = msg.get_payload(decode=True)
 cryptopayload:Optional[Message] = None
 if not isinstance(ciphertext, bytes):
 logging.warning('encrypted part was not a leaf mime part somehow')
@@ -178,14 +180,18 @@ class MimePrinter(object):
 prefix = prefix.rpartition('└')[0] + ' '
 if prefix.endswith('├'):
 prefix = prefix.rpartition('├')[0] + '│'
-parts:Union[List[Message], str, bytes, None] = z.get_payload()
+parts = z.get_payload()
 if not isinstance(parts, list):
 raise TypeError(f'parts was {type(parts)}, expected List[Message]')
 i = 0
 while (i < len(parts)-1):
-self.print_tree(parts[i], prefix + '├', z, i+1)
+msg = parts[i]
+if isinstance(msg, Message):
+self.print_tree(msg, prefix + '├', z, i+1)
 i += 1
-self.print_tree(parts[i], prefix + '└', z, i+1)
+msg = parts[i]
+if isinstance(msg, Message):
+self.print_tree(msg, prefix + '└', z, i+1)
 # FIXME: show epilogue?
 else:
 self.print_part(z, prefix+'─╴', parent, num)
diff --git a/imap-dl b/imap-dl
index fac7487..824c21d 100755
--- a/imap-dl
+++ b/imap-dl
@@ -2,7 +2,7 @@
 # PYTHON_ARGCOMPLETE_OK
 # -*- coding: utf-8 -*-
 
-# Copyright (C) 2019-2020 Daniel Kahn Gillmor
+# Copyright (C) 2019-2024 Daniel Kahn Gillmor
 # Copyright (C) 2020  Red Hat, Inc.
 #
 # This program is free software: you can redistribute it and/or modify
@@ -52,14 +52,17 @@ import statistics
 import configparser
 
 from typing import Dict, List, Optional, Tuple, Union
+from types import ModuleType
 
+argcomplete:Optional[ModuleType]
 

Bug#1068342: RFP: valkey -- Persistent key-value database with network interface (Redis fork)

[Antoine Beaupré]

FWIW, valkey just entered FreeBSD ports as well:

https://www.freshports.org/databases/valkey/
-- 
For once you have tasted flight,
You will walk the earth with your eyes turned skyward;
For there you have been,
And there you long to return.
- Leonardo da Vinci

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Alexandre Detiste]

control: tag -1 +moreinfo

Thank you for your report.

systemd-cron attempts to be the shallowest possible
wrapper around systemd.

Can you please try to reproduce the problem without systemd-cron involved;
by copying the .timer / .service / .sh triplet from /run/systemd/generator
into /etc/systemd/system and see what happens when
you do manually what cron-update.service would do.

It does:
 - systemctl daemon-reload
 - systemctl restart .timer  (via cron.target)
 - systemctl reset-failed .timer
(hint: systemctl cat cron-update.service)

If the same problem persists; then the bug is definitively in systemd itself.

Greetings

Le ven. 5 avr. 2024 à 11:15, Maximilian Stein  a écrit :
> Today I noticed that a run of cron-update.service apparently causes
> some past cron jobs to re-run.
>
> I was able to reproduce the behavior with other timers, too. It seems
> that the generated cron services are executed by cron-update.service
> if they are within a certain time limit in the past.

Bug#1068490: netperf: Netserver remove /dev/null in some cases, breaking many things

[Jean Tourrilhes]

Package: netperf
Version: 2.7.0-0.2
Severity: critical
Tags: patch upstream
Justification: breaks unrelated software
X-Debbugs-Cc: tourrilhes@gmail.com

This bug is hard to reproduce, as the condition that lead to
Netserver deleting /dev/null are quite mysterious. I was getting my
/dev/null removed over the years at very rare occurences, until
I managed to track it down to Netserver.

The issue is not present in the tarball for version 2.7.0. It
was introduced in patch :
02018-02-07T17:21:57-08:00~5380b1f.patch
In particular, this line :
+FileName = NETPERF_NULL;
This patch is part of the Netperf GitHub, which is why I added
the upstream tag.
I will report this bug upstream, unfortunately I don't expect
much action :-(

A quick look at the source code show that the code is wrong in
very obvious way. The fix is quite simple and obvious, and I provide
a patch (included below).
Note that my patch replace
11_no_change_perms_on_dev-null.patch, so please remove that patch
before applying mine.
Thanks in advance !

Jean


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

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

Versions of packages netperf depends on:
ii  libc6  2.31-13+deb11u8

netperf recommends no packages.

netperf suggests no packages.

-- no debconf information

diff --git a/src/netserver.c b/src/netserver.c
index 2e6b567..ae4ad61 100644
--- a/src/netserver.c
+++ b/src/netserver.c
@@ -220,7 +220,7 @@ unlink_empty_debug_file() {
 #if !defined(WIN32)
   struct stat buf;
 
-  if (stat(FileName,)== 0) {
+  if ( (! suppress_debug) && (stat(FileName,)== 0) ) {
 
 if (buf.st_size == 0)
   unlink(FileName);
@@ -239,6 +239,7 @@ open_debug_file()
   if (where != NULL) fflush(where);
   if (suppress_debug) {
 strncpy(FileName, NETPERF_NULL, sizeof(FileName));
+FileName[sizeof(FileName) - 1] = '\0';
 where = fopen(FileName, "w");
   } else {
 int fd;
@@ -260,7 +261,8 @@ open_debug_file()
 
 #if !defined(WIN32)
 
-  chmod(FileName,0644);
+  if (! suppress_debug)
+chmod(FileName,0644);
 
   /* redirect stdin to "/dev/null" */
   rd_null_fp = fopen(NETPERF_NULL,"r");
diff --git a/src/netserver.c b/src/netserver.c
index 2e6b567..ae4ad61 100644
--- a/src/netserver.c
+++ b/src/netserver.c
@@ -220,7 +220,7 @@ unlink_empty_debug_file() {
 #if !defined(WIN32)
   struct stat buf;
 
-  if (stat(FileName,)== 0) {
+  if ( (! suppress_debug) && (stat(FileName,)== 0) ) {
 
 if (buf.st_size == 0)
   unlink(FileName);
@@ -239,6 +239,7 @@ open_debug_file()
   if (where != NULL) fflush(where);
   if (suppress_debug) {
 strncpy(FileName, NETPERF_NULL, sizeof(FileName));
+FileName[sizeof(FileName) - 1] = '\0';
 where = fopen(FileName, "w");
   } else {
 int fd;
@@ -260,7 +261,8 @@ open_debug_file()
 
 #if !defined(WIN32)
 
-  chmod(FileName,0644);
+  if (! suppress_debug)
+chmod(FileName,0644);
 
   /* redirect stdin to "/dev/null" */
   rd_null_fp = fopen(NETPERF_NULL,"r");
diff --git a/src/netserver.c b/src/netserver.c
index 2e6b567..ae4ad61 100644
--- a/src/netserver.c
+++ b/src/netserver.c
@@ -220,7 +220,7 @@ unlink_empty_debug_file() {
 #if !defined(WIN32)
   struct stat buf;
 
-  if (stat(FileName,)== 0) {
+  if ( (! suppress_debug) && (stat(FileName,)== 0) ) {
 
 if (buf.st_size == 0)
   unlink(FileName);
@@ -239,6 +239,7 @@ open_debug_file()
   if (where != NULL) fflush(where);
   if (suppress_debug) {
 strncpy(FileName, NETPERF_NULL, sizeof(FileName));
+FileName[sizeof(FileName) - 1] = '\0';
 where = fopen(FileName, "w");
   } else {
 int fd;
@@ -260,7 +261,8 @@ open_debug_file()
 
 #if !defined(WIN32)
 
-  chmod(FileName,0644);
+  if (! suppress_debug)
+chmod(FileName,0644);
 
   /* redirect stdin to "/dev/null" */
   rd_null_fp = fopen(NETPERF_NULL,"r");

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Sean Whitton]

Hello,

On Sat 06 Apr 2024 at 12:15pm +08, Sean Whitton wrote:

> Hi Russ,
>
> We have two seconded solutions, so you and I should perhaps break the
> tie.  I prefer the Bill's 'Autobuild: no' solution as the more
> conservative change: we only have data about packages that are currently
> autobuilt, not those that aren't, so we might be making those buggy if
> we just ban network access for all non-free packages.  How about you?

(It's not actually a tie in terms of number of seconds, but we don't do
this quantatively.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Sean Whitton]

Hi Russ,

We have two seconded solutions, so you and I should perhaps break the
tie.  I prefer the Bill's 'Autobuild: no' solution as the more
conservative change: we only have data about packages that are currently
autobuilt, not those that aren't, so we might be making those buggy if
we just ban network access for all non-free packages.  How about you?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068022: Document the Testsuite-Triggers field

[Sean Whitton]

Hello,

On Fri 05 Apr 2024 at 11:30am +02, Christian Kastner wrote:

> Hi again,
>
> On 2024-03-29 20:30, Christian Kastner wrote:
>> Policy 5.6.30 lists the Testsuite field, but it doesn't list the
>> Testsuite-Triggers field that seems to be part of Sources files and is
>> generated by dpkg-source >= 1.18.8.
>>
>> This field is quite useful, as given my package src:foo, I can find out
>> which packages have autopkgtests that depend on it, and are thus in the
>> set of reverse dependencies that I could check for breakage.
>
> I've read up on the change process [1], and I guess my proposal to
> submit a patch was too far into the process.
>
> Thus, I take a step back, and seek discussion first.
>
> In addition to what I've said above, I think documenting this field
> would not only enhance discoverability, but give more weight to it for
> tooling that makes use of these fields.
>
> For discussion context, I'd like to quote dsc(5) on this field:
>> Testsuite-Triggers: package-list
>>
>> This field declares the comma-separated union of all test dependencies
>> (Depends fields in debian/tests/control file), with all restrictions
>> removed, and OR dependencies flattened (that is, converted to separate AND
>> relationships), except for binaries generated by this source package and its
>> meta-dependency equivalent @.
>>
>> Rationale: this field is needed because otherwise to be able to get the test
>> dependencies, each source package would need to be unpacked.

Sounds good to me.  If you'd like to propose wording, there's some more
guidance in our README.md.  Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1068489: O: clamassassin -- email virus filter wrapper for ClamAV

[Robert Edmonds]

Package: wnpp
Severity: normal
X-Debbugs-Cc: clamassas...@packages.debian.org
Control: affects -1 + src:clamassassin

I intend to orphan the clamassassin package. I no longer use this package, and
I'm not sure if upstream is still maintaining it (I could not find a current
location distributing this software). Nowadays I think there are plugins for
rspamd and spamassassin that can do this kind of scanning.

The package description is:
 clamassassin is a simple virus filter wrapper for ClamAV for use in procmail
 filters and similar applications. clamassassin's interface is similar to
 that of spamassassin, making it easy to implement for those familiar with that
 tool. clamassassin is designed with an emphasis on security, robustness and
 simplicity.

Bug#1064593: issue with Debian-style html theme for sphinx-based documents

[Sean Whitton]

Hello,

On Fri 05 Apr 2024 at 02:07pm +02, Holger Wansing wrote:

> Hi,
>
> Holger Wansing  wrote (Tue, 2 Apr 2024 14:47:12 +0200):
>> We need a separate copy of 3 packages in our www build tree on
>> wolkenstein and all www static mirrors (simply let DSA install those
>> packages on the machines will not work).
>> And every sphinx-based manual needs relative symlinks in its tree, pointing
>> to the above packages' content.
>> The 1ftpfiles and 7doc scripts, which need to be adapted for that, and
>> also the situation on the www mirrors is getting more complex, so I'm unsure
>> if we want this.
>> See my patch.
>>
>> On the other side, I don't see any other solution apart from developing
>> a new theme.
>
> Since there were no objections, I pushed that yesterday (+ one additional
> change was needed), and that works now.

Thank you very much again.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1063711: mumble: autopkgtest fixes

[Chris Knadle]

Hello Diederik.

Thanks for working on the autopkg test failure and including patches -- 
I'm about to try to incorporate them.


I also pushed the Mumble 1.5.517 release from my local Git to Salsa; 
sorry I missed that.


I wasn't in the Debian VoIP Packaging Team mailing list, so that's how I 
missed these bugs for a couple of months.


I'm under heavy life burden right now but I hope I'm turning the corner 
and will be able to free up some time in a few weeks.


Thanks

   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1060254: mumble: please make the build reproducible

[Chris Knadle]

Hello Chris and Diederik

I missed that a couple of bugs came in for Mumble because it turns out 
up to now I had not signed up for the Debian VoIP Packaging Team mailing 
list. *sigh* It's going to take me some time to figure out the correct 
'sieve' rules to get the Mumble bug messages to show up in my 
'Debian-Bugs' mail folder so that I'll be able to quickly catch new bugs 
coming in.


It's going to take a few weeks before I will be able to start work on 
packaging Mumble v.1.5.613, but I hope I can do an upload with the 
patches for reproducibility and fixing the autopkgtest 'smoke' test.


Thanks for working on reproducibility in the Mumble package.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1068488: RFP: iterable-io -- Adapt generators and other iterables to a file-like interface

[Antoine Beaupre]

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

* Package name: iterable-io
  Version : 1.0.0
  Upstream Contact: Carey Metcalfe 
* URL : https://pypi.org/project/iterable-io/
* License : LGPLv3
  Programming Lang: Python
  Description : Adapt generators and other iterables to a file-like 
interface

iterable-io is a small Python library that provides an adapter so that
it's possible to read from iterable objects in the same way as
file-like objects.

It is primarily useful as "glue" between two incompatible
interfaces. As an example, in the case where one interface expects a
file-like object to call .read() on, and the other only provides a
generator of bytes.

One way to solve this issue would be to write all the bytes in the
generator to a temporary file, then provide that file instead, but if
the generator produces a large amount of data then this is both slow
to start, and resource-intensive.

This library allows streaming data between these two incompatible
interfaces so as data is requested by .read(), it's pulled from the
iterable. This keeps resource usage low and removes the startup delay.



this is a new dependency introduced by magic-wormhole 0.14

Bug#1066594: octave-iso2mesh: FTBFS: nl_single_file.c:2505:26: error: implicit declaration of function ‘lsame_’ [-Werror=implicit-function-declaration]

[Qianqian Fang]

On 4/2/24 04:49, Rafael Laboissière wrote:


Thanks for the link. The package is fixed and version 1.9.6+ds-10 of 
the package has been uploaded to unstable.



terrific! thank you so much!


You are still a member of the octave-iso2mesh project at Salsa.d.o, 
with login fangq.



let me try again, I might need to update my ssh key.


Qianqian

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Sean Whitton]

Hello,

On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote:

> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
>> Thanks, but can you sign this off?  Ty!
>
> Sure, attached.  Let me know if you need anything different.

Thanks.  Unfortunately, it doesn't seem to fix the FTBFS, on sid.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067650: davmail: O365Interactive fails with "superclass access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame"

[Louis-Philippe Véronneau]

On 2024-04-05 3 h 04 a.m., Alexandre Rossi wrote:

Hi,


Exception in thread "AWT-EventQueue-0" java.lang.IllegalAccessError: superclass 
access check failed: class davmail.exchange.auth.O365InteractiveAuthenticatorFrame$2 (in 
unnamed module @0x112d0a71) cannot access class sun.net.www.protocol.https.Handler (in 
module java.base) because module java.base does not export sun.net.www.protocol.https to 
unnamed module @0x112d0a71


Upstream points out that davmail should be launched with:

$ /usr/bin/java \
  -Xmx512M -Dsun.net.inetaddr.ttl=60 \
  --add-exports java.base/sun.net.www.protocol.https=ALL-UNNAMED \
  -jar /usr/share/davmail/davmail.jar

Do you confirm this fixes the problem?


Hi,

Thanks for the follow up.

Yes, that does fix the issue!

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068487: man-db: Failed to get unit file state for man-db.service: Transport endpoint is not connected

[Bo YU]

Package: man-db
Version: 2.12.1-1
Severity: important

Dear Maintainer,

Today upgraded my riscv64 sid , I got:

```
Setting up man-db (2.12.1-1) ...
Updating database of manual pages ...
Reload daemon failed: Transport endpoint is not connected

Failed to get unit file state for man-db.service: Transport endpoint is not 
connected
Failed to retrieve unit state: Transport endpoint is not connected
man-db.service is a disabled or a static unit not running, not starting it.
Failed to get unit file state for man-db.timer: Transport endpoint is not 
connected
Failed to retrieve unit state: Transport endpoint is not connected
man-db.timer is a disabled or a static unit not running, not starting it.
...
Setting up openssh-sftp-server (1:9.7p1-4) ...
Setting up openssh-server (1:9.7p1-4) ...
Reload daemon failed: Transport endpoint is not connected
Failed to get properties: Transport endpoint is not connected
Reload daemon failed: Transport endpoint is not connected
Failed to get unit file state for ssh.service: Transport endpoint is not 
connected
Failed to retrieve unit state: Transport endpoint is not connected
ssh.service is a disabled or a static unit not running, not starting it.
^B^[[5~Reload daemon failed: Transport endpoint is not connected
Failed to get unit file state for ssh.socket: Transport endpoint is not 
connected
Failed to retrieve unit state: Transport endpoint is not connected
...
```

And this process is very time-consuming also.


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1068486: vendors versioneer.py

[Antoine Beaupre]

Source: magic-wormhole-mailbox-server
Version: 0.4.1-2
Severity: normal

I hadn't noticed this before (or didn't care) but this package vendors
versioneer.py. This cause at least one RC / FTBFS bug (#1058173),
which has been fixed upstream, but not part of a release.

We should really repack the source to avoid this.


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

Kernel: Linux 6.6.13+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Rich Felker]

On Fri, Apr 05, 2024 at 05:04:37AM +, Thorsten Glaser wrote:
> Markus Wichmann dixit:
> 
> >can check with readelf -r what the relocation types are. If they are not
> >relative, they will not be processed.
> 
> Gotcha! They are all R_390_RELATIVE except for:
> 
> 00045ff0  00110016 R_390_64  00042c58 u_ops + 70
> 00045ff8  00110016 R_390_64  00042c58 u_ops + 0
> 00047020  00110016 R_390_64  00042c58 u_ops + 80
> 00047088  00110016 R_390_64  00042c58 u_ops + 80
> 000470a8  00110016 R_390_64  00042c58 u_ops + b8
> 00047220  00110016 R_390_64  00042c58 u_ops + 80
> 00046900  00260016 R_390_64  00015af8 c_command + 0
> 00046940  00070016 R_390_64  00017238 c_exec + 0
> 00046ab0  00200016 R_390_64  00016a80 c_trap + 0
> 00047090  00250016 R_390_64  000430ac initvsn + 0
> 00047278  00550016 R_390_64  00047438 null_string + 2
> 
> That’s our missing strings.

Is there anything weird about how these objects were declared that
might have caused ld not to resolve them statically like it should? It
seems odd that these data symbols, but not any other ones, would be
left as symbolic relocations.

Rich

Bug#1068250: dracut: Consider switching to the fork dracut-ng

[Laszlo]

Released (tagged as 100).

https://github.com/dracut-ng/dracut-ng/releases/tag/100

Thanks Thomas !

Bug#1068485: RFS: libhinoko/1.0.2-1 -- I/O library for IEEE 1394 isochronous communication

[Takashi Sakamoto]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : libhinoko
   Version  : 1.0.2-1
   Upstream contact : Takashi Sakamoto 
 * URL  : 
https://git.kernel.org/pub/scm/libs/ieee1394/libhinoko.git/
 * License  : LGPL-2.1+
 * Vcs  : https://salsa.debian.org/debian/libhinoko/
   Section  : libs

The source builds the following binary packages:

  libhinoko1 - I/O library for IEEE 1394 isochronous communication
  gir1.2-hinoko-1.0 - GObject introspection data for libhinoko1
  libhinoko-dev - I/O library for IEEE 1394 isochronous communication 
(development files)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libh/libhinoko/libhinoko_1.0.2-1.dsc

Changes since the last upload:

 libhinoko (1.0.2-1) unstable; urgency=medium
 .
   * New upstream release.

Regards,
-- 
  Takashi Sakamoto

Bug#1058552: [Pkg-javascript-devel] Bug#1058552: science.js: FTBFS: SyntaxError: Error parsing /<>/package.json: Unexpected end of JSON input

[James Valleroy]

On Thu, 04 Apr 2024 19:01:58 +0200 Jonas Smedegaard  wrote:

Quoting James Valleroy (2024-04-04 16:13:07)
> On 3/28/24 4:08 AM, Petter Reinholdtsen wrote:
> > [James Valleroy 2024-02-12]
> >> Here is a patch that fixes the build:
> > 
> > Btw, did you mean TEMPFILE=$(shell mktemp) to get a random temp file

> > name?
> > 
> 
> I'm not sure. It may also work, but there is a difference in when a 
> shell command runs. Some people recommend not to use shell in a 
> makefile: https://stackoverflow.com/a/76121578


Each make target (i.e. each line indended by a tab) is executed within a
shell.  The point in the SO answer you reference is that calling the
make function $(shell ...) *inside* a make target effectively spawns a
shell within another shell, and *that* you rarely really want.

What Petter is talking about above is that "TEMPFILE=mktemp", because it
is a make target (i.e. on a TAB-indented line) is passed to a shell,
which will *not* set TEMPFILE to the output of the shell command mktemp,
but simply set TEMPFILE to the _string_ "mktemp" which is unlikely that
you want.


I see, thanks for pointing that out. I think there isn't a need to use 
mktemp here, so the patch can be simplified to this:



diff --git a/Makefile b/Makefile
index c9e03c2..f5a954b 100644
--- a/Makefile
+++ b/Makefile
@@ -77,7 +77,8 @@ install:

 package.json: src/package.js
@rm -f $@
-   node src/package.js > $@
+   node src/package.js > package.json.temp
+   mv package.json.temp $@
@chmod a-w $@

 clean:


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068484: juce-modules-source: Depends: libwebkit2gtk-4.0-dev but it is no longer built

[Jeremy Bícha]

Source: juce
Version: 7.0.5+ds-1
Severity: serious
Tags: trixie sid
User: pkg-webkit-maintain...@lists.alioth.debian.org
Usertags: webkit-4.0

Debian's webkit2gtk no longer builds the 4.0 API. The 4.1 API is the
same as the 4.0 API except that it uses libsoup3 instead of
libsoup2.4. Since juce does not use libsoup directly, it should be
possible to change all references to webkit2gtk-4.0 to webkit2gtk-4.1
in both the upstream code (with a patch) and in debian/control to fix
this issue.

Please let me know if you intend to fix this bug soon or I will likely
NMU this next week.

Thank you,
Jeremy Bícha

Bug#1068483: dpkg-genbuildinfo: Should buildinfo files copy the hash of the source package?

[Guillem Jover]

Hi!

On Sat, 2024-04-06 at 02:56:02 +0300, Adrian Bunk wrote:
> Package: dpkg-dev
> Version: 1.22.6
> Severity: normal
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

> A thought I already wrote in a recent debian-devel discussion:
> 
> In theory source package filenames should be eternally and globally
> unique, but in practice there are cornercases where this assumption
> might break like for example:
> - *stable-security does not currently have a copy of the sources
>   in the main archive, one always have to upload the source archive
>   there and this might accidentally be a different orig.tar
> - dak does not keep an eternal history of everything it ever knew,
>   e.g. RM and later re-NEW of a source version might have a different
>   source .orig.tar or even different sources for a Debian revision
> - Debian and Ubuntu might have different orig.tar for the same version,
>   if Ubuntu updated a package before Debian did, or with packages
>   were development is completely independent in Debian and Ubuntu
>   (e.g. OpenStack, KDE)
> 
> The reason for different files might be as trivial as "git archive"
> not always producing the same output when running in different
> environments, e.g. the autogenerated tarball for a git tag on Github
> might have different checksums depending on whether it is downloaded
> today or next year despite identical contents due to slightly
> different gzip compression.
> 
> Should buildinfo files contain the hashes of the source package,
> to clearly define what sources have been used?

Ideally? Yes, and I think we considered that at the time when we
introduced the .buildinfo files. Although a ref to the .dsc does get
included if the build is also creating the source package.

The problem is that when dpkg-buildpackage is not building the source
package, there is no guarantee the source package is going to be
present, or that if it is present it matches what is currently being
built from the working directory.

Thanks,
Guillem

Bug#400046: closed by Gioele Barabucci (Re: Bug#400046: bash: man page tells me "typeset +r" will undo a "typeset -r" but it doesn't)

[Chris Moore]

Thanks for getting back to me. :)

Bug#1068474: yforth segfaults immediately on launching

[Bdale Garbee]

Sudip Mukherjee  writes:

> yforth is causing a segfault immediately on startup.

Thanks for the bug report.  I haven't had reason to use yforth in many
years, (the package was last updated on 11 October 2012), so I hadn't
noticed! 

My guess is that this is a simple 64-bit system incompatibility, as a
quick rebuild of the package on my current 64-bit laptop yields a large
number of warnings about casts of pointer from integer of different size...

Honestly, I'm not sure this is worth fixing?  The upstream site has
disappeared entirely.  If someone wants to step through the source and
fix all the cast issues, I'd be happy to have a patch.  But given the
availability of gforth and pforth in Debian, just removing yforth from
Debian might be the best plan.

Bdale


signature.asc
Description: PGP signature

Bug#1068483: dpkg-genbuildinfo: Should buildinfo files copy the hash of the source package?

[Adrian Bunk]

Package: dpkg-dev
Version: 1.22.6
Severity: normal
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

A thought I already wrote in a recent debian-devel discussion:

In theory source package filenames should be eternally and globally
unique, but in practice there are cornercases where this assumption
might break like for example:
- *stable-security does not currently have a copy of the sources
  in the main archive, one always have to upload the source archive
  there and this might accidentally be a different orig.tar
- dak does not keep an eternal history of everything it ever knew,
  e.g. RM and later re-NEW of a source version might have a different
  source .orig.tar or even different sources for a Debian revision
- Debian and Ubuntu might have different orig.tar for the same version,
  if Ubuntu updated a package before Debian did, or with packages
  were development is completely independent in Debian and Ubuntu
  (e.g. OpenStack, KDE)

The reason for different files might be as trivial as "git archive"
not always producing the same output when running in different
environments, e.g. the autogenerated tarball for a git tag on Github
might have different checksums depending on whether it is downloaded
today or next year despite identical contents due to slightly
different gzip compression.

Should buildinfo files contain the hashes of the source package,
to clearly define what sources have been used?

Bug#1067087: dpkg-buildflags: Enable frame pointers by default

[Guillem Jover]

Control: tags -1 moreinfo
Control: retitle -1 dpkg-buildflags: Enable frame pointers by default

Hi!

On Mon, 2024-03-18 at 09:56:38 +0100, Kurt Roeckx wrote:
> Source: gcc-14
> Severity: wishlist

> Please consider enabling frame pointers on 64 bit arches.
> See: 
> https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html

On Sat, 2024-03-30 at 11:59:24 +0100, Matthias Klose wrote:
> Make sure, that you contact porters on which architectures that should be
> enabled, and e.g. don't do that on 32bit architectures at all.

Please see this entry in the dpkg FAQ:

  
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F

and if you are interested in pursuing this, then start the process,
while I don't see any issue with enabling this, I'm not going to drive
this myself.

Thanks,
Guillem

Bug#1068482: RFS: linux-firewire-utils/0.5.1-1 -- Linux FireWire utilities

[Takashi Sakamoto]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "linux-firewire-utils":

 * Package name : linux-firewire-utils
   Version  : 0.5.1-1
   Upstream contact : Takashi Sakamoto 
 * URL  : 
https://git.kernel.org/pub/scm/utils/ieee1394/linux-firewire-utils.git/
 * License  : GPL-2
 * Vcs  : https://salsa.debian.org/debian/linux-firewire-utils/
   Section  : utils

The source builds the following binary packages:

  linux-firewire-utils - Linux FireWire utilities

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

  https://mentors.debian.net/package/linux-firewire-utils/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/linux-firewire-utils/linux-firewire-utils_0.5.1-1.dsc

Changes since the last upload:

 linux-firewire-utils (0.5.1-1) unstable; urgency=medium
 .
   * New upstream release.

Regards,
-- 
  Takashi Sakamoto

Bug#1068481: gstreamer1.0-plugins-bad:amd64: Frequency spectrum scope freezes on the first frame

[Huey Chen]

Package: gstreamer1.0-plugins-bad
Version: 1.24.1-4
Severity: normal
X-Debbugs-Cc: hueyche...@outlook.com

Dear Maintainer,
When using the frequency spectrum scope (spectroscope) to render the audio, it 
freezes on the first frame and does not work.  
This bug was found using the Parole multimedia player as it uses gstreamer's 
bad plugins where the audio visualization is found. 
Before version 1.24, the audio visualization worked on all modes at version 
1.21. Now it crashes on some of the modes like the object detection overlay.

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

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

Versions of packages gstreamer1.0-plugins-bad:amd64 depends on:
ii  gstreamer1.0-plugins-base   1.24.1-1
ii  gstreamer1.0-plugins-good   1.24.1-2
ii  libaom3 3.8.2-2
ii  libass9 1:0.17.1-2
ii  libavtp00.2.0-1+b1
ii  libbs2b03.1.0+dfsg-8
ii  libbz2-1.0  1.0.8-5.1
ii  libc6   2.37-15.1
ii  libcairo2   1.18.0-3
ii  libchromaprint1 1.5.1-5
ii  libcurl3t64-gnutls  8.7.1-2
ii  libdc1394-252.2.6-4
ii  libdca0 0.0.7-2
ii  libde265-0  1.0.15-1+b1
ii  libdirectfb-1.7-7t641.7.7-13
ii  libdrm2 2.4.120-2
ii  libdvdnav4  6.1.1-3
ii  libdvdread8t64  6.1.3-1.1
ii  libfaad22.11.1-1+b1
ii  libflite1   2.2-6+b2
ii  libfluidsynth3  2.3.4-1+b3
ii  libfreeaptx00.1.1-2
ii  libgcc-s1   14-20240330-1
ii  libglib2.0-0t64 2.78.4-6
ii  libgme0 0.6.3-7+b1
ii  libgsm1 1.0.22-1
ii  libgstreamer-gl1.0-01.24.1-1
ii  libgstreamer-plugins-bad1.0-0   1.24.1-4
ii  libgstreamer-plugins-base1.0-0  1.24.1-1
ii  libgstreamer1.0-0   1.24.1-1
ii  libgtk-3-0t64   3.24.41-4
ii  libgudev-1.0-0  238-5
ii  libimath-3-1-29t64  3.1.9-3.1+b1
ii  libjson-glib-1.0-0  1.8.0-2+b1
ii  liblc3-11.0.4-3
ii  liblcms2-2  2.14-2+b1
ii  libldacbt-enc2  2.0.2.3+git20200429+ed310a0-4
ii  liblilv-0-0 0.24.24-2
ii  liblrdf00.6.1-4
ii  libltc111.3.2-1
ii  libmfx1 22.5.4-1
ii  libmjpegutils-2.1-0t64  1:2.1.0+debian-8.1
ii  libmodplug1 1:0.8.9.0-3
ii  libmpcdec6  2:0.1~r495-2
ii  libmpeg2encpp-2.1-0t64  1:2.1.0+debian-8.1
ii  libmplex2-2.1-0t64  1:2.1.0+debian-8.1
ii  libneon27t640.33.0-1.1+b1
ii  libnettle8t64   3.9.1-2.2
ii  libopenal1  1:1.23.1-4+b1
ii  libopenexr-3-1-30   3.1.5-5.1+b2
ii  libopenh264-7   2.4.1+dfsg-1
ii  libopenjp2-72.5.0-2+b3
ii  libopenmpt0t64  0.7.6-1
ii  libopenni2-02.2.0.33+dfsg-18
ii  libopus01.4-1+b1
ii  liborc-0.4-0t64 1:0.4.38-1
ii  libpango-1.0-0  1.52.1+ds-1
ii  libpangocairo-1.0-0 1.52.1+ds-1
ii  libqrencode44.1.1-1+b2
ii  librsvg2-2  2.58.0+dfsg-1
ii  librtmp12.4+20151223.gitfa8646d.1-2+b3
ii  libsbc1 2.0-1+b1
ii  libsndfile1 1.2.2-1+b1
ii  libsoundtouch1  2.3.2+ds1-1+b1
ii  libspandsp2t64  0.0.6+dfsg-2.1
ii  libsrt1.5-gnutls1.5.3-1+b2
ii  libsrtp2-1  2.5.0-3
ii  libssl3t64  3.2.1-3
ii  libstdc++6  14-20240330-1
ii  libsvtav1enc1d1 1.7.0+dfsg-2+b1
ii  libusb-1.0-02:1.0.27-1
ii  libva2  2.20.0-2
ii  libvo-aacenc0   0.1.3-2+b1
ii  libvo-amrwbenc0 0.1.3-2+b1
ii  libvulkan1  1.3.275.0-1
ii  libwayland-client0  1.22.0-2.1+b1
ii  libwebp71.3.2-0.4+b1
ii  libwebpmux3 1.3.2-0.4+b1
ii  libwildmidi20.4.3-1+b2
ii  libx11-62:1.8.7-1
ii  libx265-199 3.5-2+b1
ii  libxml2 2.9.14+dfsg-1.3+b2
ii  libzbar0t64 0.23.93-4+b1
ii  libzvbi0t64  

Bug#1068480: RFS: streamlink/6.7.2-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.7.2.

  * Package name: streamlink
Version : 6.7.2-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.7.2-1.dsc


Changes since the last upload to unstable:
streamlink (6.7.2-1) unstable; urgency=medium

  * New upstream version 6.7.2
  * d/patches: remove trio 0.22 fix which is now also fixed upstream
  * d/patches: fix tests on testing

 -- Alexis Murzeau   Fri, 05 Apr 2024 23:37:30 +0200

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#724461: bash: ulimit -T documented but doesn't work

[Gioele Barabucci]

Control: found -1 4.3-11+b1
Control: found -1 5.2.21-2

On Mon, 23 Sep 2013 18:58:20 -0700 Russ Allbery  wrote:

bash(1) under ulimit in shell built-ins claims:

  -T The maximum number of threads

However, bash itself appears to disagree:

wanderer:~$ ulimit -T
bash: ulimit: -T: invalid option
ulimit: usage: ulimit [-SHacdefilmnpqrstuvx] [limit]


Bash 5.2.21-2 still fails, but at least the error message now mentions -T:

$ ulimit -T
-bash: ulimit: -T: invalid option
ulimit: usage: ulimit [-SHabcdefiklmnpqrstuvxPRT] [limit]

Regards,

--
Gioele Barabucci

Bug#1042262: cumin: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Antoine Beaupré]

On 2023-07-27 13:04:22, Riccardo Coccioli wrote:
> I've checked the issue and opened a bug upstream to pyparsing [1] as this
> is indeed a regression.
> Running CI on cumin I've also found that pylint is reporting new issues
> related to pyparsing code, for which I've opened a separate bug upstream
> [2].
>
> [1] https://github.com/pyparsing/pyparsing/issues/502
> [2] https://github.com/pyparsing/pyparsing/issues/501

Hi!

Thanks for this! It looks like those are fixed upstream, do we need to
update pyparsing to 3.1.2 to fix this bug or what's the next step?

(upstream 502 is fixed in 3.1.1, in unstable, but 501 is only in
3.1.2...)

a.

-- 
Sous le projecteur, on ne voit pas les autres.
- Félix Leclerc

Bug#1068479: libreoffice-writer: space between paragraphs missing in spacing and indentation

[José Luis González]

Package: libreoffice-writer
Version: 4:7.4.7-1+deb12u1
Severity: serious

The setting for spacing between paragraphs is missing in the spacing
and indentation tab of the paragraph dialog.

Serious severity because the bug has a major effect on the usability of
the package, without rendering it completely unusable, considering
paragraphs are a key feature in a word processor, and spacing is
something very very basic for them and incredibly necessary.

Bug#1068478: dovecot-core: Wildcard !include statements fail if nothing matches

[Einhard Leichtfuß]

Package: dovecot-core
Version: 1:2.3.21+dfsg1-3+b1
Severity: normal

Dear Maintainer,

when the Dovecot configuration contains an `!include` statement with a
wildcard that does not match anything, dovecot prints an error and
terminates.

Expected behaviour: Dovecot processes the configuration as if the
`!include` statement was not present.

The upstream on-line documentation [0] says on `!include`:
> It’s not an error if wildcards don’t result in any matching files.

[0] 


Steps to reproduce:

  mkdir dir
  printf '%s\n' '!include dir/*.conf' > dovecot.conf
  dovecot -Fc dovecot.conf
  doveconf -c dovecot.conf

Output of `dovecot -Fc doveconf.conf`:

  doveconf: Fatal: Error in configuration file dovecot.conf line 1: No matches

Output of `doveconf -c dovecot.conf`:

  # 2.3.21 (47349e2482): dovecot.conf
  # Pigeonhole version 0.5.21 (f6cd4b8e)
  doveconf: Fatal: Error in configuration file dovecot.conf line 1: No matches

Workaround 1:
 * Create an empty dummy configuration file in `dir/`.

Workaround 2:
 * Use `!include_try` instead.
   * Unlike `!include`, this also silently ignores read errors.

Possibly related upstream mailing list thread:
 * 

 * 


-- Package-specific info:

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

Kernel: Linux 6.7.9-amd64 (SMP w/2 CPU threads; PREEMPT)
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 dovecot-core depends on:
ii  adduser  3.137
ii  init-system-helpers  1.66
ii  libapparmor1 3.0.13-2
ii  libbz2-1.0   1.0.8-5.1
ii  libc62.37-15.1
ii  libcap2  1:2.66-5
ii  libcrypt11:4.4.36-4
ii  libexttextcat-2.0-0  3.4.7-1
ii  libicu72 72.1-4+b1
ii  liblua5.4-0  5.4.6-3+b1
ii  liblz4-1 1.9.4-2
ii  liblzma5 5.6.1+really5.4.5-1
ii  libpam-runtime   1.5.3-6
ii  libpam0g 1.5.3-6
ii  libsodium23  1.0.18-1
ii  libssl3t64   3.2.1-3
ii  libstemmer0d 2.2.0-4+b1
ii  libsystemd0  255.4-1+b1
ii  libtirpc3t64 1.3.4+ds-1.2
ii  libunwind8   1.6.2-3
ii  libwrap0 7.6.q-33
ii  libzstd1 1.5.5+dfsg2-2
ii  openssl  3.2.1-3
ii  ssl-cert 1.1.2
ii  ucf  3.0043+nmu1
ii  zlib1g   1:1.3.dfsg-3.1

dovecot-core recommends no packages.

Versions of packages dovecot-core suggests:
pn  dovecot-gssapi
pn  dovecot-imapd 
pn  dovecot-ldap  
pn  dovecot-lmtpd 
pn  dovecot-managesieved  
pn  dovecot-mysql 
pn  dovecot-pgsql 
pn  dovecot-pop3d 
pn  dovecot-sieve 
pn  dovecot-solr  
pn  dovecot-sqlite
pn  dovecot-submissiond   
pn  ntp   

Versions of packages dovecot-core is related to:
ii  dovecot-core [dovecot-common]  1:2.3.21+dfsg1-3+b1
pn  dovecot-dev
pn  dovecot-gssapi 
pn  dovecot-imapd  
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
pn  dovecot-sieve  
pn  dovecot-sqlite 

-- no debconf information

Bug#379696: ~/bin handled incorrectly in .bashrc and .bash_profile

[Gioele Barabucci]

Control: found -1 5.2.21-2
Control: tags -1 patch

Bug #904930 contains a patch to fix this issue.

[1] https://bugs.debian.org/904930

Bug#1067691: FTBFS: double free or corruption

[Bastian Germann]

Control: forwarded -1 https://github.com/alexkay/spek/issues/308

Bug#1068416: ssh-agent: improve systemd user session integration

[Daniel Kahn Gillmor]

On Thu 2024-04-04 15:28:34 -0400, Daniel Kahn Gillmor wrote:
> ssh-agent is a critical piece of infrastructure for my workflow, and i
> want it better integrated with my user session, which is managed by
> systemd's per-user login manager (`systemd --user`).

I'm attaching an updated set of patches.  These replace the earlier set
of patches. In particular, it irons out the following bugs:

- the systemd socket-activation now sets up the systemd activation
   environment, but doesn't try to use
   dbus-update-activation-environment, as i found that trying to talk to
   dbus during early login wasn't reliable.

- the socket is set up with mode 0600

- the socket is actually installed with the debian package

- properly initialize `sock` variable in ssh-agent to -1, so that
  "ssh-agent " works properly again.

I'd be happy to hear some feedback if anyone else wants to try it.

  --dkg

From b3051efa59b6a3802f2b10048f35640cf8d2011c Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 4 Apr 2024 13:09:10 -0400
Subject: [PATCH 1/2] ssh-agent: automatically detect when socket-activated via
 systemd

Socket activation for the ssh-agent is useful for several reasons:

- the systemd user session can choose and reserve the socket before
  the session has fully started.

- systemd can inject SSH_AUTH_SOCK directly into the dbus and systemd
  environment, even before the agent is started.

- the agent will be started lazily, on-demand.  This consumes no
  system resources (not even a pid) if the user never tries to talk to
  the agent, and the agent will inherit the systemd service activation
  environment when it is first accessed (for example, if it is first
  accessed from a Wayland session, $WAYLAND_DISPLAY will be set; if it
  is first accessed from an X11 session, $DISPLAY will be set).

We only enter this mode if the following conditions are true:

 - One of the -D or -d flags are given, and no command arguments are
   present (ssh-agent when supervised by systemd must be run in the
   foreground and not as a subprocess), and

 - The environment variable conditions described in
   sd_listen_fds(3) are met, and only a single socket is provided.
---
 ssh-agent.1 |  8 
 ssh-agent.c | 57 ++---
 2 files changed, 45 insertions(+), 20 deletions(-)

diff --git a/ssh-agent.1 b/ssh-agent.1
index 1ab7d729d..0ce0cd781 100644
--- a/ssh-agent.1
+++ b/ssh-agent.1
@@ -247,6 +247,14 @@ starts, it creates a
 socket and stores its pathname in this variable.
 It is accessible only to the current user,
 but is easily abused by root or another instance of the same user.
+.It Ev SD_LISTEN_FDS
+When
+.Nm
+starts, if no socket path has been specified, but this variable and the
+accompanying SD_LISTEN_PID are set as described in
+.Xr sd_listen_fds 3 ,
+.Nm
+uses the socket passed in by the systemd supervisor.
 .El
 .Pp
 In Debian,
diff --git a/ssh-agent.c b/ssh-agent.c
index d35741a86..54a8978cc 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -2193,8 +2193,8 @@ int
 main(int ac, char **av)
 {
 	int c_flag = 0, d_flag = 0, D_flag = 0, k_flag = 0, s_flag = 0;
-	int sock, ch, result, saved_errno;
-	char *shell, *format, *pidstr, *agentsocket = NULL;
+	int sock = -1, ch, result, saved_errno;
+	char *shell, *format, *pidstr, *listen, *agentsocket = NULL;
 #ifdef HAVE_SETRLIMIT
 	struct rlimit rlim;
 #endif
@@ -2339,14 +2339,27 @@ main(int ac, char **av)
 	parent_pid = getpid();
 
 	if (agentsocket == NULL) {
-		/* Create private directory for agent socket */
-		mktemp_proto(socket_dir, sizeof(socket_dir));
-		if (mkdtemp(socket_dir) == NULL) {
-			perror("mkdtemp: private socket dir");
-			exit(1);
+		/* Check if we are socket-activated with a single socket, as
+		 * described in sd_listen_fds(3) */
+		if ((D_flag || d_flag) &&
+			(listen = getenv("LISTEN_PID")) &&
+			strtol(listen, NULL, 10) == (long)parent_pid &&
+			(listen = getenv("LISTEN_FDS")) &&
+			strcmp(listen, "1") == 0) {
+			socket_name[0] = '\0';
+			socket_dir[0] = '\0';
+			/* this is SD_LISTEN_FDS_START */
+			sock = 3;
+		} else {
+			/* Create private directory for agent socket */
+			mktemp_proto(socket_dir, sizeof(socket_dir));
+			if (mkdtemp(socket_dir) == NULL) {
+perror("mkdtemp: private socket dir");
+exit(1);
+			}
+			snprintf(socket_name, sizeof socket_name, "%s/agent.%ld", socket_dir,
+	 (long)parent_pid);
 		}
-		snprintf(socket_name, sizeof socket_name, "%s/agent.%ld", socket_dir,
-		(long)parent_pid);
 	} else {
 		/* Try to use specified agent socket */
 		socket_dir[0] = '\0';
@@ -2357,14 +2370,16 @@ main(int ac, char **av)
 	 * Create socket early so it will exist before command gets run from
 	 * the parent.
 	 */
-	prev_mask = umask(0177);
-	sock = unix_listener(socket_name, SSH_LISTEN_BACKLOG, 0);
 	if (sock < 0) {
-		/* XXX - unix_listener() calls error() not perror() */
-		*socket_name = '\0'; /* Don't unlink any existing file */
-		cleanup_exit(1);
+		prev_mask = 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Sam Hartman]

> "Aurelien" == Aurelien Jarno  writes:

Aurelien> If we go that route, here is a proposed alternative patch:

Aurelien> --- a/policy/ch-source.rst
Aurelien> +++ b/policy/ch-source.rst
Aurelien> @@ -338,7 +338,8 @@
Aurelien>  For example, the build target should pass 
``--disable-silent-rules``
Aurelien>  to any configure scripts.  See also :ref:`s-binaries`.
 
Aurelien> -For packages in the main archive, required targets must not 
attempt
Aurelien> +Except for packages in the non-free archive with the 
``Autobuild``
Aurelien> +control field unset or set to ``no``, required targets must not 
attempt
Aurelien>  network access, except, via the loopback interface, to services 
on the
Aurelien>  build host that have been started by the build.

Seconded.


signature.asc
Description: PGP signature

Bug#1068477: RFS: emacs-corfu/1.3-1 [Team] -- Completion Overlay Region FUnction in Emacs

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "emacs-corfu":

 * Package name : emacs-corfu
   Version  : 1.3-1
   Upstream contact : Daniel Mendler 
 * URL  : https://github.com/minad/corfu/
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-corfu
   Section  : editors

The source builds the following binary packages:

  elpa-corfu - Completion Overlay Region FUnction in Emacs

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

  https://mentors.debian.net/package/emacs-corfu/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-corfu/emacs-corfu_1.3-1.dsc

Changes since the last upload:

 emacs-corfu (1.3-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream release
   * Drop file name from lintian overrides so that it works either
 compressed or not

Regards,
-- 
Xiyue Deng

Bug#1068476: RM: rlog -- leaf package

[Bastian Germann]

Source: rlog
Version: 1.4-4.2
Severity: wishlist

clamfs has just lost its dependency on rlog and therefore, rlog is now a leaf 
package.
The last upstream release was 15 years ago, so now would be the perfect time to 
remove it.
Please consider filing a RM bug on ftp.debian.org.

Bug#1066783: streamlink: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Alexis Murzeau]

Hi,

Just found that the autopkgtest that run tests also has this issue and is
blocking the migration to testing.

Will look into this.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1068475: dunst: dunst systemd --user session has noisy errors when logging in from tty

[Daniel Kahn Gillmor]

Package: dunst
Version: 1.9.2-1
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

the dunst system --user service works well whenever i'm in a graphical
environment, but it produces a lot of noisy warnings, errors, and
complaints, especially when i log in from a tty instead of a graphical
display manager.  It would be great if unimportant warnings and errors
were minimized so that i could focus 

When i log in from a tty, systemd's user session manager tries to start
dunst, and dunst fails because there is no graphical environment
(it actually gives warnings and errors about a missing X11).

after i've started a graphical environment (Wayland, not X11), if some
tool sends a desktop notification, dunst will succeed in starting up.

But in the meantime, "systemctl --user status" will show that the
session is "degraded" because dunst failed to launch.

This "degraded" state masks when other user services have failed -- if i
just assume that my user session will always be degraded until i've
started a graphical environment and a desktop notification was sent,
then i won't notice if other user services are broken.

The logs created by dunst are pretty noisy too, even when it's working:

$ journalctl -b --user-unit dunst
Apr 05 14:26:09 alice systemd[2598]: Starting dunst.service - Dunst 
notification daemon...
Apr 05 14:26:09 alice dunst[2615]: WARNING: Cannot open X11 display.
Apr 05 14:26:09 alice dunst[2615]: ERROR: [  get_x11_output:0065] Couldn't 
initialize X11 output. Aborting...
Apr 05 14:26:09 alice systemd[2598]: dunst.service: Main process exited, 
code=killed, status=5/TRAP
Apr 05 14:26:09 alice systemd[2598]: dunst.service: Failed with result 'signal'.
Apr 05 14:26:09 alice systemd[2598]: Failed to start dunst.service - Dunst 
notification daemon.
Apr 05 14:32:13 alice systemd[2915]: Starting dunst.service - Dunst 
notification daemon...
Apr 05 14:32:13 alice dunst[2934]: WARNING: Cannot open X11 display.
Apr 05 14:32:13 alice dunst[2934]: ERROR: [  get_x11_output:0065] Couldn't 
initialize X11 output. Aborting...
Apr 05 14:32:13 alice systemd[2915]: dunst.service: Main process exited, 
code=killed, status=5/TRAP
Apr 05 14:32:13 alice systemd[2915]: dunst.service: Failed with result 'signal'.
Apr 05 14:32:13 alice systemd[2915]: Failed to start dunst.service - Dunst 
notification daemon.
Apr 05 15:13:49 alice systemd[2915]: Starting dunst.service - Dunst 
notification daemon...
Apr 05 15:13:49 alice dunst[166154]: CRITICAL: 
g_water_wayland_source_get_display: assertion 'self != NULL' failed
Apr 05 15:13:49 alice dunst[166154]: CRITICAL: 
g_water_wayland_source_set_error_callback: assertion 'self != NULL' failed
Apr 05 15:13:49 alice dunst[166154]: WARNING: failed to create display
Apr 05 15:13:49 alice dunst[166154]: WARNING: Couldn't initialize wayland 
output. Falling back to X11 output.
Apr 05 15:13:49 alice dunst[166154]: CRITICAL: g_water_wayland_source_free: 
assertion 'self != NULL' failed
Apr 05 15:13:49 alice systemd[2915]: Started dunst.service - Dunst notification 
daemon.
Apr 05 15:14:24 alice dunst[166154]: X connection to :0 broken (explicit kill 
or server shutdown).
Apr 05 15:14:24 alice systemd[2915]: dunst.service: Main process exited, 
code=exited, status=1/FAILURE
Apr 05 15:14:24 alice systemd[2915]: dunst.service: Failed with result 
'exit-code'.
Apr 05 16:09:18 alice systemd[398192]: Starting dunst.service - Dunst 
notification daemon...
Apr 05 16:09:18 alice dunst[398211]: WARNING: Cannot open X11 display.
Apr 05 16:09:18 alice dunst[398211]: ERROR: [  get_x11_output:0065] Couldn't 
initialize X11 output. Aborting...
Apr 05 16:09:18 alice systemd[398192]: dunst.service: Main process exited, 
code=killed, status=5/TRAP
Apr 05 16:09:18 alice systemd[398192]: dunst.service: Failed with result 
'signal'.
Apr 05 16:09:18 alice systemd[398192]: Failed to start dunst.service - Dunst 
notification daemon.
Apr 05 16:25:42 alice systemd[398192]: Starting dunst.service - Dunst 
notification daemon...
Apr 05 16:25:42 alice systemd[398192]: Started dunst.service - Dunst 
notification daemon.
Apr 05 16:26:00 alice dunst[399160]: CRITICAL: Source ID 16 was not found when 
attempting to remove it
Apr 05 16:26:48 alice dunst[399160]: CRITICAL: Source ID 23 was not found when 
attempting to remove it
$


It could be that the answer is "don't use dunst if you log in from the
tty and are bothered by spurious errors and warnings", but i quite like
dunst's minimalism otherwise, and would prefer to keep using it.

--dkg


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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 

Bug#306043: bash executable completion doesn't work if there is a space in the executable path

[Gioele Barabucci]

Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-b...@gnu.org

On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton  wrote:

Bash executable completion doesn't work if there is a space in the
executable path.


This issue is still partially present in current version of Bash.

The most basic case has been fixed:

$ touch "cmd with spaces"
$ chmod +x "cmd with spaces"
$ PATH=$PWD:$PATH
$ cmd
$ cmd\ with\ spaces

However there seems to be a linger issue that appears when multiple 
commands with spaces match a given prefix:


$ touch "myfoo "{a,b,c}" command"
$ chmod +x "myfoo "{a,b,c}" command"
$ ls myfo*
'myfoo a command'  'myfoo b command'  'myfoo c command'
$ PATH=$PWD:$PATH
$ myf
$ myfoo\ 
$ myfoo\

No suggestions are shown after the double tab. Instead, double tabbing 
should show all available commands matching the "myfoo " prefix:


$ myfoo\ 
myfoo a command  myfoo b command  myfoo c command

Regards,

--
Gioele Barabucci

Bug#1068342: RFP: valkey -- Persistent key-value database with network interface (Redis fork)

[Guillem Jover]

Hi!

On Wed, 2024-04-03 at 12:29:44 -0400, Antoine Beaupre wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-Cc: Guillem Jover , "Chris Lamb" 
> 
> 
> * Package name: valkey
>   Version : 7.2.4
>   Upstream Contact: https://github.com/valkey-io
> * URL : https://github.com/valkey-io/valkey
> * License : BSD-3
>   Programming Lang: C
>   Description : Persistent key-value database with network interface 
> (Redis fork)
> 
> Valkey is a high-performance data structure server that primarily
> serves key/value workloads. It supports a wide range of native
> structures and an extensible plugin system for adding new data
> structures and access patterns.
> 
> 
> 
> "This project was forked from the open source Redis project right
> before the transition to their new source available licenses."
> 
> Valkey is one of many Redis forks out there, but it seems to me to be
> the most promising one, at least after reading this LWN article:
> 
> https://lwn.net/SubscriberLink/966631/4b4104ce85bf92f7/

Yes, I initially had doubts about it because at the time it did not
even have a name, and thought that Redict might be the only viable
direct option. But before the article came up, and after checking a
bit more the context, my impression swapped, and I agree that this
feels more like the spiritual successor for Redis.

> For me, the plus sides:
> 
>  1. unchanged licence (while redict changed to LGPL)

I agree that license continuity is a plus for a project with an
established user base and ecosystem, and that the LGPL change could
be rather disruptive here.

>  2. has the backing of the Linux foundation

  2.1 apparently including Snapchat, so KeyDB might perhaps
  eventually be abandoned for this one (?)

>  3. exact same feature set as Redis before the fork (while KeyDB is
> lagging behind)

Although I'd qualify this, as it does not seem so clear cut, KeyDB has
a different set of features currently missing in Redis/Valkey, such
as active-active replication support (which we require at work), and
multi-threading (for a nice performance boost). It has indeed not
integrated the changes from Redis 7 (which we have not missed).

   4. has many of the old contributors, including previous core team
  members

> We use Redis at the Tor Project internnally, and we're looking for a
> smooth transition, drop-in replacement.

For a smooth migration from Redis 7, Valkey seems like the obvious
candidate indeed.

Thanks,
Guillem

Bug#1064589: marked as done (RFS: photodedupe/1.0.1 [ITP] -- a utility for identifying duplicate images)

[Joachim Zobel]

Am Freitag, dem 05.04.2024 um 19:18 + schrieb Debian Bug Tracking
System:
> You need to provide a proper source package, not a dpkg-deb artifact.

Learning about debcargo might be helpful.

Sincerely,
Joachim

https://salsa.debian.org/rust-team/debcargo/

-- 
Papier ist gebundenes CO2. Bitte drucken Sie diese EMail aus und
archivieren Sie sie.

Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing

[Martin Dosch]

Dear Andrey,

thank you for the valuable feedback. I hope it is all properly settled 
now. I just uploaded a new build to mentors and pushed the changes to 
the repo.


Thank you very much,
Martin


signature.asc
Description: PGP signature

Bug#1051402: emacspeak fails byte-compile during install or upgrade since emacs 29

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Michiel, le ven. 05 avril 2024 21:11:34 +0100, a ecrit:
> I believe this specific issue (emacspeak-proced.el:156:4: Error: Misplaced t
> or ‘otherwise’ clause) is fixed upstream by this commit:
> 
> https://github.com/tvraman/emacspeak/commit/806c044b08ccf8c53ce744a1578103037c622048
> 
> Hope this helps in some way,

It does fix things up indeed, thanks!

Samuel

Bug#1064763: proposed fix

[Bastian Germann]

I am sponsoring Daniel's NMU. The debdiff is attached.diff -Nru cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/changelog 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/changelog
--- cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/changelog 
2023-08-28 11:54:37.0 +
+++ cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/changelog 
2024-03-29 20:49:33.0 +
@@ -1,3 +1,10 @@
+cairo-dock-plug-ins (3.4.1+git20201022.a0d3415c-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Use Python setuptools instead of distutils (Closes: #1064763)
+ 
+ -- Daniel Kondor   Fri, 29 Mar 2024 21:49:33 +0100
+
 cairo-dock-plug-ins (3.4.1+git20201022.a0d3415c-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/control 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/control
--- cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/control   
2023-08-28 11:54:29.0 +
+++ cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/control   
2024-03-29 20:49:33.0 +
@@ -37,6 +37,7 @@
  libxxf86vm-dev,
  libzeitgeist-2.0-dev,
  python3,
+ python3-setuptools,
  ruby,
  ruby-dev,
  valac,
diff -Nru 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/0011-Dbus-do-not-use-deprecated-distutils-Python-module.patch
 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/0011-Dbus-do-not-use-deprecated-distutils-Python-module.patch
--- 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/0011-Dbus-do-not-use-deprecated-distutils-Python-module.patch
 1970-01-01 00:00:00.0 +
+++ 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/0011-Dbus-do-not-use-deprecated-distutils-Python-module.patch
 2024-03-29 20:49:33.0 +
@@ -0,0 +1,36 @@
+From 1aaf4b9d5c10167c1c14394ad940684c7aef65ec Mon Sep 17 00:00:00 2001
+From: Daniel Kondor 
+Date: Thu, 7 Mar 2024 22:39:19 +0100
+Subject: Dbus: do not use deprecated distutils Python module
+
+---
+ Dbus/interfaces/bash/setup.py   | 2 +-
+ Dbus/interfaces/python/setup.py | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/Dbus/interfaces/bash/setup.py b/Dbus/interfaces/bash/setup.py
+index 80aa9d418..756bf3474 100644
+--- a/Dbus/interfaces/bash/setup.py
 b/Dbus/interfaces/bash/setup.py
+@@ -13,7 +13,7 @@
+ # GNU General Public License for more details.
+ # http://www.gnu.org/licenses/licenses.html#GPL
+ 
+-from distutils.core import setup
++from setuptools import setup
+ setup(name='CDBashApplet',
+   version='1.0',
+   license='GPL-3',
+diff --git a/Dbus/interfaces/python/setup.py b/Dbus/interfaces/python/setup.py
+index af33b73bd..04525688f 100644
+--- a/Dbus/interfaces/python/setup.py
 b/Dbus/interfaces/python/setup.py
+@@ -13,7 +13,7 @@
+ # GNU General Public License for more details.
+ # http://www.gnu.org/licenses/licenses.html#GPL
+ 
+-from distutils.core import setup
++from setuptools import setup
+ setup(name='CDApplet',
+   version='1.0',
+   license='GPL-3',
diff -Nru cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/series 
cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/series
--- cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/series
2021-01-02 15:32:07.0 +
+++ cairo-dock-plug-ins-3.4.1+git20201022.a0d3415c/debian/patches/series
2024-03-29 20:47:41.0 +
@@ -8,3 +8,4 @@
 0008-weather-Use-unsigned-int.patch
 0009-Swith-use-libido3-0.1-to-libayatana-ido3-0.4.patch
 0010-Change-pkg-config-from-indicator3-0.4-to-ayatana-ind.patch
+0011-Dbus-do-not-use-deprecated-distutils-Python-module.patch

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Carlos Henrique Lima Melara]

Hi,

On Fri, Apr 05, 2024 at 09:28:02PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> > Meanwhile, I pinged upstream to ask for their opinion about
> > that to make sure we are not going to break stuff.
> 
> launcher-libseat has an higher priority than launcher-logind,
> that means enabling launcher-libseat will change the default
> behavior for all users. Although this should be harmless
> because libseat should contact logind, it doesn't work for
> whatever reason. I just tested with a VM without a
> graphical login. I can launch weston 10.0.1-1, but
> it fails with 10.0.1-1+deb12u1. So, I guess it would
> require more changes unsuitable for bookworm :-(

That's unfortunate! Is it ok for you if I poke around next week to
try to understand the problem? If there isn't a solution that keeps it
completely compatible for bookworm users, we can close this bug.

> Best,
> Dylan

Cheers,
Charles


signature.asc
Description: PGP signature

Bug#1065222: Adopting pychm (Was: Packaging multivolumefile?)

[Andreas Tille]

Hi Hiroshi,

Am Sat, Apr 06, 2024 at 02:51:51AM +0900 schrieb yokota:
> Thanks a lot for your detailed document.

You are welcome.

> I will try to fixup other packages.

Just ping me once done.

> PS:
> If py7zr is done, I will also try package pychm to use for Debian
> Calibre package.
> Please sponsor me for pychm package if you have time.

I'll try in any case.  It should be some change of maintainer
+ close bug and - as I'd recommend - some

routine-update -f

away.

Just let me know once you are ready

  Andreas.

> > O: pychm -- Python binding for CHMLIB - Python 3
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065222
> 
> --
> YOKOTA Hiroshi
> 

-- 
https://fam-tille.de

Bug#1051402: emacspeak fails byte-compile during install or upgrade since emacs 29

[Michiel]

I believe this specific issue (emacspeak-proced.el:156:4: Error: 
Misplaced t or ‘otherwise’ clause) is fixed upstream by this commit:


https://github.com/tvraman/emacspeak/commit/806c044b08ccf8c53ce744a1578103037c622048

Hope this helps in some way,

Michiel

Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system

[Aurelien Jarno]

On 2024-04-05 21:59, Michael Tokarev wrote:
> Control: title -1 nscd caches "wrong" name for accounts with the same uid
> Control: found -1 2.37-15
> 
> Rehashing this 17-years old bug which biten me today quite hard.
> 
> On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko  
> wrote:
> > 
> > Today, after unsucsessful attempt to login as sashroot, I've got somewhat
> > broken system -- all processes running under uid=0 were reported
> > belonging to sashroot. Due to lack of knowledge of nss internals I
> > inquired on -devel mailing list and it seems that multiple accounts
> > sharing uid=0 might be considered a bad practice. For more details see
> > http://lists.debian.org/debian-devel/2007/02/msg00323.html
> > thread.
> > 
> > If you can prove that it is 'documented feature of nss' to resolve in
> > some deterministic way a uid whenever multiple ones are possible, then
> > probably this bug has to be reassigned against libc6 to which
> > libnss_files belongs.
> > 
> > Since this bug might drive whole system broken, I am assigning it
> > important priority, since a big proportion of sash users probably use
> > sashroot account feature.
> 
> The problem here is that nscd caches both username and uid on each
> lookup, instead of caching just the lookup which has been asked,
> and doing the other lookup the normal way as would be done by
> getpwnam/getpwuid (and similar for getgrnam/getgrgid etc).
> 
> For very long time we relied on multiple special accounts having
> the same uid, exactly like this very sashroot case.  We had this
> for a few system/special accounts.  Each name has its own password
> and/or ssh keys (when in use), and each does start/manage its
> subsystem with the right permissions.
> 
> Now, with normal getpwuid(), it will return the first entry with
> the given uid.  But in case of nscd, it returns last looked up
> entry with this uid instead.  Eg, we have root and r_mjt, -
> when I run getpwnam(root), getpwuid(0) will return the same
> entry.  But once I looked up getpwname(r_mjt), getpwuid(0)
> will return r_mjt instead of root from now on.
> 
> Here's another incarnation of the very same theme:
> 
> https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/
> 
> I guess they use oracle rdbms, and for this one it is also very
> helpful to have 2-3 accounts with the same uid, for managing
> purposes.  And it breaks badly with nscd too.
> 
> Why this bug is marked 'wontfix'?

Having multiple users with the same uid in not something supported, and
therefore you just encountered an undefined behaviour. Please see this
message which tagged the bug as wontfix:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411059;msg=15

That said, please feel free to work with upstream to provide a patch.

Regards
Aurelien

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

Bug#1068474: yforth segfaults immediately on launching

[Sudip Mukherjee]

Source: yforth
Version: 0.2.1-1
Severity: important
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

yforth is causing a segfault immediately on startup.

$ yforth 
yForth? v0.2  Copyright (C) 2012  Luca Padovani
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see LICENSE for details.
error(17): segmentation fault.
Segmentation fault

Though "yforth -h" works and shows the help message.


-- 
Regards
Sudip

Bug#1068473: icinga2: crashes on startup on ppc64el

[Aurelien Jarno]

Source: icinga2
Version: 2.13.6-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: d...@debian.org
Control: fixed -1 icinga2/2.14.2-1

Dear maintainer,

DSA has issues running icinga2 on ppc64el on Bookworm, it fails with a
segmentation fault just after startup:

| × icinga2.service - Icinga host/service/network monitoring system
|  Loaded: loaded (/lib/systemd/system/icinga2.service; enabled; preset: 
enabled)
|  Active: failed (Result: exit-code) since Thu 2024-04-04 20:55:13 UTC; 
3min 57s ago
|Duration: 1.209s
|Docs: https://icinga.com/docs/icinga2/latest/
| Process: 356368 ExecStartPre=/usr/lib/icinga2/prepare-dirs 
/usr/lib/icinga2/icinga2 (code=exited, status=0/SUCCESS)
| Process: 356373 ExecStart=/usr/sbin/icinga2 daemon --close-stdio -e 
${ICINGA2_ERROR_LOG} (code=exited, status=139)
|Main PID: 356373 (code=exited, status=139)
|  Status: "Startup finished."
| CPU: 473ms
| 
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +] 
information/ConfigItem: Instantiated 1 IcingaApplication.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +] 
information/ConfigItem: Instantiated 2 Endpoints.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +] 
information/ConfigItem: Instantiated 1 FileLogger.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +] 
information/ConfigItem: Instantiated 249 CheckCommands.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +] 
information/ConfigItem: Instantiated 1 ApiListener.
| Apr 04 20:55:12 platti icinga2[356415]: [2024-04-04 20:55:12 +] 
information/ScriptGlobal: Dumping variables to file 
'/var/cache/icinga2/icinga2.vars'
| Apr 04 20:55:12 platti systemd[1]: Started icinga2.service - Icinga 
host/service/network monitoring system.
| Apr 04 20:55:12 platti icinga2[356373]: [2024-04-04 20:55:12 +] 
information/cli: Closing console log.
| Apr 04 20:55:13 platti systemd[1]: icinga2.service: Main process exited, 
code=exited, status=139/n/a
| Apr 04 20:55:13 platti systemd[1]: icinga2.service: Failed with result 
'exit-code'.

I have been able to obtain a backtrace:

| (gdb) bt full
| #0  0x000127d44850 in icinga::JsonRpcConnection::CheckLiveness 
(this=this@entry=0x0, yc=...) at ./lib/remote/jsonrpcconnection.cpp:344
| ec = {val_ = 0, failed_ = false, cat_ = 0x0}
| #1  0x000127d44f04 in operator() (__closure=0x7fff7c002620, yc=...) at 
./lib/remote/jsonrpcconnection.cpp:58
| keepAlive = {px = 0x0}
| this = 0x0
| keepAlive = 
| this = 
| #2  operator() (__closure=__closure@entry=0x7fff7c002620, yc=...) at 
./lib/base/io-engine.hpp:106
| f = {__this = 0x0, __keepAlive = {px = 0x0}}
| #3  0x000127d521bc in 
boost::asio::detail::coro_entry_point, 
icinga::IoEngine::SpawnCoroutine 
>(boost::asio::io_context::strand&, 
icinga::JsonRpcConnection::Start()::)::
 >::operator() (
| ca=..., this=) at 
/usr/include/boost/asio/impl/spawn.hpp:355
| data = 
| yield = {coro_ = 
std::weak_ptr> (use count 1, weak count 
5) = {get() = 0x7fff7c0c3640}, ca_ = @0x7fff7c103488,
|   handler_ = {> = {}, 
> = {}, > = {}, > = {executor_ = {service_ = 
@0x7fff94003150,
| impl_ = 0x7fff7c002040}, target_ = 0x127d70760 
}, }, ec_ = 0x0}
| data = 
| yield = 
| #4  
boost::coroutines::detail::push_coroutine_object,
 void, boost::asio::detail::coro_entry_point, 
icinga::IoEngine::SpawnCoroutine 
>(boost::asio::io_context::strand&, 
icinga::JsonRpcConnection::Start()::)::
 >&, 
boost::coroutines::basic_standard_stack_allocator
 >::run (this=0x7fff7c1035c0)
| at /usr/include/boost/coroutine/detail/push_coroutine_object.hpp:302
| b = {> = 
{ = { = {}, },
| _vptr.pull_coroutine_impl = 0x12884b938 +16>, flags_ = 0, 
except_ = {ptr_ = {px = 0x0, pn = {pi_ = 0x0}}}, caller_ = 0x7fff7c103618,
| callee_ = 0x7fff7c1035f0}, }
| push_coro = {impl_ = 0x7fff7c103490}
| to = {do_unwind = 64, coro = 0x7fff7c103670}
| __PRETTY_FUNCTION__ = 
| b = 
| push_coro = 
| to = 
| #5  
boost::coroutines::detail::trampoline_push_void,
 void, boost::asio::detail::coro_entry_point, 
icinga::IoEngine::SpawnCoroutine 
>(boost::asio::io_context::strand&, 
icinga::JsonRpcConnection::Start()::)::
 >&, 
boost::coroutines::basic_standard_stack_allocator
 > >(boost::context::detail::transfer_t) (t=...) at 
/usr/include/boost/coroutine/detail/trampoline_push.hpp:70
| __PRETTY_FUNCTION__ = "void 
boost::coroutines::detail::trampoline_push_void(boost::context::detail::transfer_t)
 [with Coro = push_coroutine_object, 
void, boost::asio::detail::coro_ent"...
| data = 
| param = 
| coro = 0x7fff7c1035c0
| #6  0x7fffa9670f0c in make_fcontext () from 
/lib/powerpc64le-linux-gnu/libboost_context.so.1.74.0
| No symbol table info available.

It is not exactly 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Aurelien Jarno]

On 2024-04-04 22:38, Bill Allombert wrote:
> On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote:
> > I'm not sure what I think about that.  We have a general escape hatch
> > already for non-free packages in Policy 2.2.3 that says they may not fully
> > comply with Policy, which may be sufficient. 
> 
> But precisely, we _do_ want non-free packages that are built on the 
> autobuilders
> to comply with this requirement. So we do not want 2.2.3 to apply in that
> specific case. It seems cleaner to say that the requirement only apply if
> Autobuild: yes is declared.

If we go that route, here is a proposed alternative patch:

--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -338,7 +338,8 @@
 For example, the build target should pass ``--disable-silent-rules``
 to any configure scripts.  See also :ref:`s-binaries`.
 
-For packages in the main archive, required targets must not attempt
+Except for packages in the non-free archive with the ``Autobuild``
+control field unset or set to ``no``, required targets must not attempt
 network access, except, via the loopback interface, to services on the
 build host that have been started by the build.

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

Bug#1067569: RFS: libsmb2/4.0.0-1 [ITP]-- SMB2/3 client library

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

You should provide a separate -dev package, currently the development
files are shipped in the library package.
There is a hardcoded Depends: libkrb5-3, why is this needed?
There are unused files in debian/, such as libsmb2-dev.* and libsmb21.*.
You should remove the .la file instead of fixing it, unless something
needs it.
You shouldn't call dh_installexamples in override_dh_install.

Please remove the moreinfo tag after these are addressed.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1066112: weston: Enable support to libseat launcher in weston 10

[Dylan Aïssi]

Hi,

Le ven. 5 avr. 2024 à 16:00, Dylan Aïssi  a écrit :
> Meanwhile, I pinged upstream to ask for their opinion about
> that to make sure we are not going to break stuff.

launcher-libseat has an higher priority than launcher-logind,
that means enabling launcher-libseat will change the default
behavior for all users. Although this should be harmless
because libseat should contact logind, it doesn't work for
whatever reason. I just tested with a VM without a
graphical login. I can launch weston 10.0.1-1, but
it fails with 10.0.1-1+deb12u1. So, I guess it would
require more changes unsuitable for bookworm :-(

Best,
Dylan

Bug#1066870: RFS: libudis86/0~20221013-1 [ITP] -- Disassembler for x86 and x86-64 class ISA

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

The package FTBFS: /bin/bash: line 1: /usr/bin/python3: No such file or 
directory
Also, debian/watch is empty but present and I'm not sure about
__AUTO_PERMISSIVE__ and __UNKNOWN__ in debian/copyright.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1056156: varnish: CVE-2023-44487: VSV00013 Varnish HTTP/2 Rapid Reset Attack

[Salvatore Bonaccorso]

Hi Marco,

On Thu, Apr 04, 2024 at 11:05:03AM +0200, Marco d'Itri wrote:
> On Apr 04, Salvatore Bonaccorso  wrote:
> 
> > While I do agree (and it was filled with this severity), the bug
> > severity would not be RC, varnish currently seem to lack active
> > maintainership. 
> Not anymore: https://salsa.debian.org/md/varnish/ .

Ok that are good news, thank you for taking care of it.

For CVE-2023-44487 and CVE-2024-30156 Moritz did already mark then as
"ignored" (as beeing as well too intrusive for backporting) for
bullseye and bookworm.

Regards,
Salvatore

Bug#1064975: RFS: k3conf/0.3-1 [ITP] -- Powerful Diagnostic Tool for Texas Instruments K3 based Processors

[Andrey Rakhmatullin]

I have several suggestions for this:
- Can you provide debian/watch? It should be possible.
- debian/k3conf.1 has a *roff warning, lintian also catches it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068472: RM: onedrivesdk -- ROM; deprecated upstream; RC-buggy; leaf package

[Bastian Germann]

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

Upstream has given up on the package and it doe not work with current Python 
versions, see #1025016.
Please remove it from the archive.

Bug#1053245: fluidsynth: Fluidsynth starts at boot and blocks the sound device, no obvious way to disable it

[Patrice Duroux]

Package: fluidsynth
Version: 2.3.4-1+b3
Followup-For: Bug #1053245

Hi,

I am also having trouble with its systemd service.

1. it seems to fail when opening my user session:
avril 05 19:48:44 kos-moceratops systemd[2775]: Listening on pipewire-
pulse.socket - PipeWire PulseAudio.
avril 05 19:48:44 kos-moceratops systemd[2775]: Listening on pipewire.socket -
PipeWire Multimedia System Sockets.
avril 05 19:48:44 kos-moceratops systemd[2775]: Started pipewire.service -
PipeWire Multimedia Service.
avril 05 19:48:44 kos-moceratops systemd[2775]: Starting fluidsynth.service -
FluidSynth Daemon...
avril 05 19:48:44 kos-moceratops systemd[2775]: Started pipewire-pulse.service
- PipeWire PulseAudio.
avril 05 19:48:44 kos-moceratops (uidsynth)[2811]: fluidsynth.service:
Referenced but unset environment variable evaluates to an empty string:
OTHER_OPTS
avril 05 19:48:44 kos-moceratops pipewire[2810]: mod.jackdbus-detect: Failed to
receive jackdbus reply: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.jackaudio.service was not provided by any .service files
avril 05 19:48:45 kos-moceratops fluidsynth[2811]: Failed to create secure
directory (/run/user/1001/pulse): Read-only file system
avril 05 19:48:45 kos-moceratops fluidsynth[2811]: fluidsynth: error: Failed to
bind server socket: 98
avril 05 19:48:45 kos-moceratops fluidsynth[2811]: Failed to create the server.
avril 05 19:48:45 kos-moceratops fluidsynth[2811]: Continuing without it.
avril 05 19:48:45 kos-moceratops fluidsynth[2811]: fluidsynth: warning: Failed
to set thread to high priority
avril 05 19:48:50 kos-moceratops pipewire[2810]: [0:00:55.151408076] [2810]
WARN IPAManager ipa_manager.cpp:154 No IPA found in '/usr/lib/x86_64-linux-
gnu/libcamera'
avril 05 19:48:50 kos-moceratops pipewire[2810]: [0:00:55.151454434] [2810]
INFO Camera camera_manager.cpp:284 libcamera v0.2.0
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: fluidsynth: warning: Audio
device hardware configuration failed
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: fluidsynth: warning: Audio
device hardware configuration failed
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: fluidsynth: error: Failed to
find an audio format supported by alsa
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: Failed to create the audio
driver. Giving up.
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: FluidSynth runtime version
2.3.4
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: Copyright (C) 2000-2023
Peter Hanappe and others.
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: Distributed under the LGPL
license.
avril 05 19:48:50 kos-moceratops fluidsynth[2811]: SoundFont(R) is a registered
trademark of Creative Technology Ltd.
avril 05 19:48:50 kos-moceratops systemd[2775]: fluidsynth.service: Main
process exited, code=exited, status=255/EXCEPTION
avril 05 19:48:50 kos-moceratops systemd[2775]: fluidsynth.service: Failed with
result 'exit-code'.
avril 05 19:48:50 kos-moceratops systemd[2775]: Failed to start
fluidsynth.service - FluidSynth Daemon.
avril 05 19:48:53 kos-moceratops pipewire-pulse[2815]: default:
snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap
audio permissions won't be honored.
avril 05 19:48:56 kos-moceratops pipewire-pulse[2815]: default:
snap_get_audio_permissions: kernel lacks 'fine grained unix mediation'; snap
audio permissions won't be honored.
avril 05 19:49:08 kos-moceratops systemd[1271]: Stopping fluidsynth.service -
FluidSynth Daemon...


2. then starting it «by hand» works:

$ fluidsynth -is /usr/share/sounds/sf3/default-GM.sf3
FluidSynth runtime version 2.3.4
Copyright (C) 2000-2023 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of Creative Technology Ltd.

fluidsynth: warning: Failed to set thread to high priority
fluidsynth: warning: Failed to set thread to high priority
(wait)

3. its service is unreachable from my session nor is listed by systemd:

$ sudo systemctl list-units | grep -i fluid
(nothing)

$ systemctl status fluidsynth.service
Unit fluidsynth.service could not be found.

$ ls -l /usr/lib/systemd/user/fluidsynth.service
-rw-r--r-- 1 root root 735 24 mars  11:09
/usr/lib/systemd/user/fluidsynth.service

I have purged and installed again the package and no change.

Regards,
Patrice


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

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

Versions of packages fluidsynth depends on:
ii  init-system-helpers   1.66
ii  libc6 2.37-15.1
ii  

Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system

[Michael Tokarev]

Control: title -1 nscd caches "wrong" name for accounts with the same uid
Control: found -1 2.37-15

Rehashing this 17-years old bug which biten me today quite hard.

On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko  
wrote:


Today, after unsucsessful attempt to login as sashroot, I've got somewhat
broken system -- all processes running under uid=0 were reported
belonging to sashroot. Due to lack of knowledge of nss internals I
inquired on -devel mailing list and it seems that multiple accounts
sharing uid=0 might be considered a bad practice. For more details see
http://lists.debian.org/debian-devel/2007/02/msg00323.html
thread.

If you can prove that it is 'documented feature of nss' to resolve in
some deterministic way a uid whenever multiple ones are possible, then
probably this bug has to be reassigned against libc6 to which
libnss_files belongs.

Since this bug might drive whole system broken, I am assigning it
important priority, since a big proportion of sash users probably use
sashroot account feature.


The problem here is that nscd caches both username and uid on each
lookup, instead of caching just the lookup which has been asked,
and doing the other lookup the normal way as would be done by
getpwnam/getpwuid (and similar for getgrnam/getgrgid etc).

For very long time we relied on multiple special accounts having
the same uid, exactly like this very sashroot case.  We had this
for a few system/special accounts.  Each name has its own password
and/or ssh keys (when in use), and each does start/manage its
subsystem with the right permissions.

Now, with normal getpwuid(), it will return the first entry with
the given uid.  But in case of nscd, it returns last looked up
entry with this uid instead.  Eg, we have root and r_mjt, -
when I run getpwnam(root), getpwuid(0) will return the same
entry.  But once I looked up getpwname(r_mjt), getpwuid(0)
will return r_mjt instead of root from now on.

Here's another incarnation of the very same theme:

https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/

I guess they use oracle rdbms, and for this one it is also very
helpful to have 2-3 accounts with the same uid, for managing
purposes.  And it breaks badly with nscd too.

Why this bug is marked 'wontfix'?

Thanks,

/mjt

Bug#1068412: [ftpmas...@ftp-master.debian.org: Accepted apache2 2.4.59-1 (source) into unstable]

[Salvatore Bonaccorso]

Source: apache2
Source-Version: 2.4.59-1

- Forwarded message from Debian FTP Masters 
 -

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 05 Apr 2024 08:08:11 +0400
Source: apache2
Built-For-Profiles: nocheck
Architecture: source
Version: 2.4.59-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Apache Maintainers 
Changed-By: Yadd 
Closes: 1032628 1054564
Changes:
 apache2 (2.4.59-1) unstable; urgency=medium
 .
   [ Stefan Fritsch ]
   * Remove old transitional packages libapache2-mod-md and
 libapache2-mod-proxy-uwsgi. Closes: #1032628
 .
   [ Yadd ]
   * mod_proxy_connect: disable AllowCONNECT by default (Closes: #1054564)
   * Refresh patches
   * New upstream version 2.4.59
   * Refresh patches
   * Update patches
   * Update test framework
Checksums-Sha1: 
 f1cf18103ca23c57beaa2985bbbe4eee1e8dff87 3334 apache2_2.4.59-1.dsc
 7a118baaed0f2131e482f93f5057038ca6c021be 9843252 apache2_2.4.59.orig.tar.gz
 837cdf46898d962c4c05642745566249fc91e52b 833 apache2_2.4.59.orig.tar.gz.asc
 3e1cad5ee1fc66d350465c1e81d7e0f88221bc01 820300 apache2_2.4.59-1.debian.tar.xz
Checksums-Sha256: 
 25e6990e65cb685f3172143648806ab0fd263a18cd412155f0d14d7ef9987428 3334 
apache2_2.4.59-1.dsc
 e4ec4ce12c6c8f5a794dc2263d126cb1d6ef667f034c4678ec945d61286e8b0f 9843252 
apache2_2.4.59.orig.tar.gz
 0ad3f670b944ebf08c81544bc82fae9496e88d96840cd0612d8cdeaa073eb06d 833 
apache2_2.4.59.orig.tar.gz.asc
 1e869a5024215a2a9b69603daf1395840774640f7b2701ca4b7971452a0641d1 820300 
apache2_2.4.59-1.debian.tar.xz
Files: 
 3f3ee286b583f22ec5cb3efc1f0a5016 3334 httpd optional apache2_2.4.59-1.dsc
 c39d28e0777bc95631cb49958fdb6601 9843252 httpd optional 
apache2_2.4.59.orig.tar.gz
 3c342b3dcc0fe227a1fffdf9997987d0 833 httpd optional 
apache2_2.4.59.orig.tar.gz.asc
 4da024370ede9c5a75a0df725be0cdc5 820300 httpd optional 
apache2_2.4.59-1.debian.tar.xz

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEAN/li4tVV3nRAF7J9tdMp8mZ7ukFAmYPec8ACgkQ9tdMp8mZ
7umCiw//TB1rIA1czwHsUrdeOIT3HG9qERzBJsmsP8nyg+cIrytiGfhlt2eOmLYO
X+Wo19J98VuCmTbJClb6opAfSpvJG2AmNUl/PYAqOBzvDgR+QlEMmVXVgxUp9+Tv
0e0P2H+8U0pO3dE51VIXqYtCLTLQnLaci763ewB0oRlSWuzoVNDDahUS3iJ5e58o
btwUQQwq+2F+RBclRhuXca3dOI93UBZDsv56mxR+p2o0vpo+pQRZjHDv8tzT3bOq
/PyWusXKPDf9MXYZqwY2TgYx8v/YdDVYqzgr6Tj/VXgXEKC22pudzSv9/J5iGfHh
VHmf02Gh+0wNWmxajqK2KlxjMON/Qn6kyoAok9w5vv4HtOXBZimzdq0kDsc8EjJl
QuaBcwIAy+0EATBhjaVY7sHtM9SydJNr1f4DBBD9kEB2DKEE9n7/iFxcFfSMd52Y
xwJ4fPk1fe1ki7k/qn0VULpzf1iM3JDQE19uXyE29cSW4eJhiWvH1v+NZzzxNo+t
NtDhSIEEnUkGZSsYyg2qg5NH3e3PJMadc1nTRY6hVNzGpJlsUrCKnMOZbJsBQM6S
cNCY48ux8ziQmJNowvBVbXf6/+SH9h2+CYFRw9GZagaNe1yfErNglbn78KZqJUHw
YcXIFc96qeznRJ9zRhPdHGGeqa+nETH1lWBp6eitihkKhDjCF48=
=dQDE
-END PGP SIGNATURE-




- End forwarded message -

Bug#1068471: winff: shell injection

[Jakub Wilk]

Package: winff
Version: 1.6.3+dfsg-2
Tags: security

As a follow-up to #1053373, WinFF still doesn't correctly escape 
filenames it passes to shell.


To reproduce, try converting the file created by this command:

   touch '\"; cowsay pwned >&2 #.mp3'


-- System Information:
Architecture: i386

Versions of packages winff depends on:
ii  winff-qt  1.6.3+dfsg-2

--
Jakub Wilk

Bug#1068155: lmms: FTBFS on i386: dh_install: warning: Cannot find (any matches for) "usr/lib/*/lmms/libvestige.so" (tried in ., debian/tmp)

[Dmitry Shachnev]

Control: reassign -1 libwine-dev 9.0~repack-4
Control: affects -1 + src:lmms

Hi all,

On Tue, Apr 02, 2024 at 12:16:09PM +0200, Andreas Beckmann wrote:
> Comparing bookworm and sid buildlogs shows the following relevant
> differences during cmake:
> 
> -Setting up libwine-dev:i386 (8.0~repack-4) ...^M
> +Setting up libwine-dev:i386 (9.0~repack-4+b1) ...^M
> 
> --- Found Wine: /usr/lib/i386-linux-gnu/wine/libwine.so
> +CMake Warning (dev) at cmake/modules/FindWine.cmake:20 (EXEC_PROGRAM):
> +  Policy CMP0153 is not set: The exec_program command should not be called.
> +  Run "cmake --help-policy CMP0153" for policy details.  Use the cmake_policy
> +  command to set the policy and suppress this warning.
> +
> +  Use execute_process() instead.
> +Call Stack (most recent call first):
> +  CMakeLists.txt:462 (FIND_PACKAGE)
> +This warning is for project developers.  Use -Wno-dev to suppress it.
> +
> +-- Could NOT find Wine (missing: WINE_LIBRARIES)
> 
> -* VST-instrument hoster   : OK, with workaround linking 
> /usr/lib/i386-linux-gnu/wine/i386-unix/libwinecrt0.a/
> -* VST-effect hoster   : OK, with workaround linking 
> /usr/lib/i386-linux-gnu/wine/i386-unix/libwinecrt0.a/
> +* VST-instrument hoster   : not found, please install (lib)wine-dev (or 
> similar) - 64 bit systems additionally need gcc-multilib and g++-multilib
> +* VST-effect hoster   : not found, please install (lib)wine-dev (or 
> similar) - 64 bit systems additionally need gcc-multilib and g++-multilib

This is actually a bug in libwine-dev: libwine.so is a broken symlink:

  # ls -l /usr/lib/i386-linux-gnu/wine/libwine.so
  lrwxrwxrwx 1 root root 22 Mar 12 18:22 
/usr/lib/i386-linux-gnu/wine/libwine.so -> i386-unix/libwine.so.1
  # ls -l $(realpath /usr/lib/i386-linux-gnu/wine/libwine.so)
  ls: cannot access '/usr/lib/i386-linux-gnu/wine/i386-unix/libwine.so.1': No 
such file or directory

The problem is not specific to i386, the same thing is on amd64:

  # ls -l $(realpath /usr/lib/x86_64-linux-gnu/wine/libwine.so)
  ls: cannot access '/usr/lib/x86_64-linux-gnu/wine/x86_64-unix/libwine.so.1': 
No such file or directory

It's just lmms uses wine only on i386.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1062025: RFS: mistserver/3.3-1 [ITP] -- Streaming media toolkit

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

The shared libraries don't have versioned SONAMEs and so shouldn't be
packaged as such until/unless the upstream fixes that or, if the upstream
cannot or doesn't want to keep ABI stable, they should be packaged in the
way that ensures that the dependencies track this ABI correctly.

Note that lintian reports this.

PLease remove the moreinfo tag after this is addressed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068117: dieharder: dab_monobit2 crashes with ntuple > 17

[Dirk Eddelbuettel]

Hi Lucas,

On 30 March 2024 at 22:47, Lucas Thode wrote:
| Package: dieharder
| Version: 3.31.1.4-1.1
| Severity: normal
| X-Debbugs-Cc: thode...@gmail.com
| 
| Dear Maintainer,
| 
| `dieharder -d 209 -n $nvalue` crashes for $nvalue>17:
| 
| $ dieharder -d 209
| 
#=#
| #dieharder version 3.31.1 Copyright 2003 Robert G. Brown  
#
| 
#=#
|rng_name|rands/second|   Seed   |
| mt19937|  1.55e+08  |2819069712|
| 
#=#
| test_name   |ntup| tsamples |psamples|  p-value |Assessment
| 
#=#
| dab_monobit2|  12|  6500|   1|0.40510331|  PASSED
| $ dieharder -d 209 -n 12
| 
#=#
| #dieharder version 3.31.1 Copyright 2003 Robert G. Brown  
#
| 
#=#
|rng_name|rands/second|   Seed   |
| mt19937|  2.54e+08  | 152376536|
| 
#=#
| test_name   |ntup| tsamples |psamples|  p-value |Assessment
| 
#=#
| dab_monobit2|  12|  6500|   1|0.10580971|  PASSED
| $ dieharder -d 209 -n 17
| 
#=#
| #dieharder version 3.31.1 Copyright 2003 Robert G. Brown  
#
| 
#=#
|rng_name|rands/second|   Seed   |
| mt19937|  2.29e+08  |2998370165|
| 
#=#
| test_name   |ntup| tsamples |psamples|  p-value |Assessment
| 
#=#
| dab_monobit2|  17|  6500|   1|1.|  FAILED
| $ dieharder -d 209 -n 18
| *** stack smashing detected ***: terminated
| Aborted
| $ dieharder -d 209 -n 27
| *** stack smashing detected ***: terminated
| Aborted
| $ dieharder -d 209 -n 28
| Segmentation fault
| 
| P.S. There are more issues with this test not liking non-standard n values, as
| can be seen from it failing miserably on mt19937 with -n 17, but the crash is
| the most glaring problem.

Good stuff.

dieharder is a little 'dormant' upstream and via my maintenance of the Debian
package I have somewhat inherited upstream.  Can you take a look please if
this was take care of already at the (somewhat active) shadow repo of mine at

   https://github.com/eddelbuettel/dieharder

I will also CC Milan who has been very attentive with a few other fixes, and
may have seen this one too.  We are trying to get hold of Robert but no luck
yet.

Cheers, Dirk

PS Apologies also for replying late. I usually get to bug reports within a
day but it's a teaching term plus being busy at my 'real job' puts some
stress on my response times.  :-/   I think I reply quicker to GH issues as I
am on GH all day anyway...

 
| -- System Information:
| Debian Release: trixie/sid
|   APT prefers testing
|   APT policy: (500, 'testing')
| Architecture: amd64 (x86_64)
| Foreign Architectures: i386
| 
| Kernel: Linux 6.3.0-1-amd64 (SMP w/12 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 dieharder depends on:
| ii  libc6 2.37-15
| ii  libdieharder3t64  3.31.1.4-1.1
| ii  libgsl27  2.7.1+dfsg-6+b1
| 
| dieharder recommends no packages.
| 
| dieharder suggests no packages.
| 
| -- no debconf information

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

Bug#1013361: Fwd: future of rwhod/rwho/ruptime, and a shell implementation of it called ruptime

[Gürkan Myczko]

just to keep all information together…

Begin forwarded message:

> From: Gürkan Myczko 
> Date: May 24, 2023 at 20:43:49 GMT+2
> To: debian-de...@lists.debian.org
> Subject: future of rwhod/rwho/ruptime, and a shell implementation of it 
> called ruptime
> 
> hello
> 
> i've always liked the ruptime command, it was so useful to see your machines 
> up or down, and for long and with what load,
> but then came multiprocessor machines, and gpus. and it was all clear text 
> sent over the network, and only in one network.
> so i started to try to do something about and out came: 
> https://github.com/alexmyczko/ruptime/tree/debian (or on salsa:
> https://salsa.debian.org/debian/ruptime). i have tried to make it useful for 
> where i use it, you can read the why on the webpage
> or salsa page. (using it on x86_64, and raspberry pies)
> 
> rwho was not implemented, but it would be easy to do so. and it's also easy 
> to extend it for any sort of data that you want to
> be easily accessible.
> 
> since there's that older implementation in C:
> netkit-rwho is orphaned, https://bugs.debian.org/1020628
> build time limit for NUSERS (1000): https://bugs.debian.org/489787
> build time option for alarm period: https://bugs.debian.org/360884
> 
> these are all much easier in the script, but it is much less efficient.
> 
> any feedback if this is a good idea, or wishes? according popcon there's some 
> users:
> https://qa.debian.org/popcon.php?package=netkit-rwho
> (glad i'm not alone)
> 
> best
> tar

Bug#1061087: RFS: bash-unit/2.1.0-1 [RFP] -- bash_unit - bash unit testing

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo
Control: retitle -1 RFS: bash-unit/2.1.0-1 [ITP] -- bash_unit - bash unit 
testing

Some issues found after a quick review:

- The package should be arch:all and shouldn't use ${shlibs:Depends}.
- The GPL-3 snippet in d/copyright looks wrong.
- The upstream docs should be installed, especially the manpage.
- The manpage should be rebuilt at the package build time.
- The package has autopkgtests but no build-time tests, it should have
  both if that's possible (and it should be possible in this case).

Please remove the moreinfo tag after these are addressed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068470: xorg-server: double free in fix for CVE-2024-31083

[Julien Cristau]

Source: xorg-server
Version: 2:21.1.11-3
Severity: grave
Tags: security upstream patch
Justification: user security hole
X-Debbugs-Cc: jcris...@debian.org, Debian Security Team 


The latest security fixes introduced a regression, apparently replacing
use-after-free with double-free in some circumstances:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1659
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1476

Cheers,
Julien

Bug#1068469: O: gtksheet -- Gtk spreadsheet widget

[Bastian Germann]

Package: wnpp

I am hereby orphaning gtksheet. I have packaged it to get lepton-eda building with gtk3 but do not have any longer-term 
interest in the package. Please consider adopting.

Bug#1061051: RFS: notes-tree/1.2-1 -- a note taking app, which organizes notes in a hierarchical structure

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

There are quite a lot of issues reported by lintian so you should fix at
least those before looking for sponsorship. The biggest problem is
debian/changelog.

Please remove the moreinfo tag after these are addressed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068468: tracker: failing autopkgtest

[Jeremy Bícha]

Source: tracker
Version: 3.7.1-1
Severity: serious
Forwarded: https://gitlab.gnome.org/GNOME/tracker/-/issues/434

tracker's autopkgtest began failing after the update from 3.7.0 to
3.7.1. This is preventing tracker from being eligible for migration to
Testing.

I have reported the issue upstream.

Thank you,
Jeremy Bícha

Bug#1059643: RFS: wstroke/2.1-1 [ITP] -- Mouse gesture plugin for Wayfire.

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

Some issues found after a quick review:

- There are many issues listed by lintian such as outdated compat level,
  outdated Standards-Version, an issue with the short description, missing
  Rules-Requires-Root.
- There should be only one changelog entry, and in general changelog
  entries shouldn't list upstream changes.
- Why is the package directed to experimental?
- debian/copyright includes the same license texts several times instead
  of using common separate sections for them.
- debian/patches/series is empty but present.

Please remove the moreinfo tag after these are addressed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1065221: Packaging multivolumefile?

[yokota]

Hi Andreas,

Thanks a lot for your detailed document.
I will try to fixup other packages.

PS:
If py7zr is done, I will also try package pychm to use for Debian
Calibre package.
Please sponsor me for pychm package if you have time.
> O: pychm -- Python binding for CHMLIB - Python 3
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065222

--
YOKOTA Hiroshi

Bug#1058016: RFS: wasix-libc/0.0~git20230922.d0362cb-1 [ITP] -- wasix libc implementation for WebAssembly

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

Some issues found after a quick review:

- It should have only one changelog entry.
- Pre-built libclang_rt.builtins-wasm32.a should be removed from the
  orig.tar, assuming it's not used in the build process.
- debian/rules hardcodes llvm-*-16 and clang-16 but B-D are llvm and
  clang, those should use versioned names too.
- You should follow the comments in debian/rules and debian/watch.
- An explicit build target looks unnecessary.

Please remove the moreinfo tag after these are addressed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068467: libgl1-mesa-dri: GPU hangs and resets while playing 3D games on Framework Laptop 13, AMD Ryzen 7640U

[Ivan Stanton]

Package: libgl1-mesa-dri
Version: 23.3.5-1
Severity: important

Dear Maintainer,

I and some others have been unable to play 3D games or run GPU-intensive
software on the Framework Laptop 13 AMD 7040 Edition due to GPU resets
occurring while doing so. I've previously reported this to the Framework
Community forums:

https://community.frame.work/t/solved-debian-12-on-laptop-13-ryzen-7640u-gpu-hangs-in-some-games/

And others have reported similar issues:

https://community.frame.work/t/vram-is-lost-due-to-gpu-reset-followed-by-a-crash/

   * What led up to the situation? I attempted to play the Steam version of
Garry's Mod. This also occurred with The Stanley Parable: Ultra Deluxe 
(Steam),
DSDA Doom (from the Debian repo) and Xonotic (from flathub). All 3D games seem
to be affected, and possibly other GPU-intensive applications.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? I first encountered this bug on bookworm, with mesa
22.3.6-1+deb12u1. Upgrading linux-firmware, both from upstream and from
testing, had no effect. Upgrading the kernel from backports had no effect.
Upgrading mesa, using the packages from trixie, made the crashes less frequent
but did not resolve the issue. After some A/B testing, the crash seems to be
resolved only by both upgrading mesa and setting the kernel parameter
amdgpu.sg_display=0, which judging by the kernel documentation, I should not
have to set unless there is a bug. It would also be nice to get this fixed for
Debian Stable users, if possible.
   * What was the outcome of this action? A few seconds into the game, the
display froze (though audio kept playing). After a few seconds, it flickered
and the graphics became partially corrupted. About a minute later, I was 
kicked to the login screen.
   * What outcome did you expect instead? Game continues playing without any
graphical glitches or freezes.

I'm not an expert on the GNU/Linux graphics stack and I haven't reported a bug 
to Debian in a while, so apologies if I got something wrong.

Here's an extract of dmesg from one occurrence of the bug:

[   62.824231] amdgpu :c1:00.0: amdgpu: [gfxhub] page fault (src_id:0
ring:24 vmid:6 pasid:32787, for process dsda-doom pid 2910 thread dsda-
doom:cs0
pid 2926)
[   62.824267] amdgpu :c1:00.0: amdgpu:   in page starting at address
0x00409b40c000 from client 10
[   62.824285] amdgpu :c1:00.0: amdgpu:
GCVM_L2_PROTECTION_FAULT_STATUS:0x00601030
[   62.824297] amdgpu :c1:00.0: amdgpu:  Faulty UTCL2 client ID: TCP
(0x8)
[   62.824310] amdgpu :c1:00.0: amdgpu:  MORE_FAULTS: 0x0
[   62.824321] amdgpu :c1:00.0: amdgpu:  WALKER_ERROR: 0x0
[   62.824331] amdgpu :c1:00.0: amdgpu:  PERMISSION_FAULTS: 0x3
[   62.824340] amdgpu :c1:00.0: amdgpu:  MAPPING_ERROR: 0x0
[   62.824349] amdgpu :c1:00.0: amdgpu:  RW: 0x0
[   72.941268] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0
timeout, but soft recovered
[   83.446602] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0
timeout, signaled seq=7073, emitted seq=7075
[   83.447891] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process dsda-doom pid 2910 thread dsda-doom:cs0 pid 2926
[   83.448887] amdgpu :c1:00.0: amdgpu: GPU reset begin!
[   83.729405] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   83.730483] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   83.949833] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   83.950689] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   84.169971] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   84.170799] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   84.390063] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   84.390888] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   84.610016] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   84.610932] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   84.828847] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   84.830204] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   85.048322] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   85.049271] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to
unmap legacy queue
[   85.267011] [drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0
[amdgpu]] *ERROR* MES failed to response msg=3
[   85.268422] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] 

Bug#1064672: virt-manager: FTBFS: AssertionError: Command was: ./virt-xml test-for-virtxml --add-device --host-device 0x04b3:0x4485 --update --confirm --debug --connect __virtinst_test__test:///<

[Fabio Fantoni]

libvirt 10.1.0 uploaded some days after my patch introduced new issue, I 
gave a fast look to upstream git but I didn't found a possible fix and I 
don't have enough time to check better and try to fix




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058766: RFS: rdiffweb/2.8.7.dev41+g849af0c+dfsg-1 [ITP] -- web interface to rdiff-backup repositories

[Andrey Rakhmatullin]

Control: tags -1 + moreinfo

On Fri, Dec 15, 2023 at 03:36:19PM -0500, Patrik Dufresne wrote:
>   dget -x 
> https://mentors.debian.net/debian/pool/main/r/rdiffweb/rdiffweb_2.8.7.dev41+g849af0c+dfsg-1.dsc
> 
> Changes for the initial release:
> 
>  rdiffweb (2.8.7.dev41+g849af0c+dfsg-1) unstable; urgency=medium
>  .
>* Automated build
Some problems I noticed after a short review:

- The package FTBFS: "E: pybuild pybuild:389: test: plugin distutils
  failed with: exit code=5: cd
  /<>/.pybuild/cpython3_3.11/build; python3.11 -m pytest".
- You should only have one changelog entry (also "Automated build" looks
  very suspicious there).
- Versioned (build-)depends on gzip and coreutils are satisfiable even in
  oldoldstable so they shouldn't be versioned.
- Standards-Version is outdated.
- rdw.conf going into both examples and /etc looks incorrect.
- Symlink stuff in postinst/postrm looks strange.
- /etc/rdiffweb seems to be created both during the package build and in
  postinst.

Note that some of these are detected by lintian and even shown on the
mentors page.
Please remove the moreinfo tag when these are addressed.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1068466: libvirt-daemon: libvirt-guests.sh cant connect to default on shutdown/reboot

[invra]

Package: libvirt-daemon
Version: 9.0.0-4
Severity: important
X-Debbugs-Cc: ix1kg8...@mozmail.com

Dear Maintainer,

It seems like there is some problem with the /usr/lib/libvirt/libvirt-guests.sh
script. When rebooting/shutting down the system this message will appear:

"libvirt-guests.sh cant connect to default"

To reproduce enable the libvirtd.service and reboot the system.

The error does not seem to cause any package breackage, just a delay in
reboots/shutdowns.


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

Kernel: Linux 6.1.0-18-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 libvirt-daemon depends on:
ii  libacl1 2.3.1-3
ii  libblkid1   2.38.1-5+deb12u1
ii  libc6   2.36-9+deb12u4
ii  libdevmapper1.02.1  2:1.02.185-2
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libparted2  3.5-3
ii  libpcap0.8  1.10.3-1
ii  libpciaccess0   0.17-2
ii  libselinux1 3.4-1+b6
ii  libtirpc3   1.3.3+ds-1
ii  libudev1252.22-1~deb12u1
ii  libvirt-daemon-driver-qemu  9.0.0-4
ii  libvirt09.0.0-4
ii  libxml2 2.9.14+dfsg-1.3~deb12u1

Versions of packages libvirt-daemon recommends:
ii  libvirt-daemon-driver-lxc   9.0.0-4
ii  libvirt-daemon-driver-vbox  9.0.0-4
ii  libvirt-daemon-driver-xen   9.0.0-4
ii  libxml2-utils   2.9.14+dfsg-1.3~deb12u1
ii  lvm22.03.16-2
ii  mount   2.38.1-5+deb12u1
ii  netcat-openbsd  1.219-1
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-7+deb12u5

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   9.0.0-4
pn  numad   

-- no debconf information

Bug#1067453: gnat: Ada.Calendar.Clock crashes on time_t64 architectures

[Nicolas Boulenguez]

Source: gcc-13
Followup-For: Bug #1067453

Hello.

In case anyone tries to build attempt3 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
in Debian, please:
 * disable debian/patches/libgnat-time64.diff in debian/rules.patch
 * adapt the current ada-lib-info-source-date-epoch.diff

--- a/debian/patches/ada-lib-info-source-date-epoch.diff
+++ b/debian/patches/ada-lib-info-source-date-epoch.diff
@@ -62,24 +62,26 @@ Author: Nicolas Boulenguez 
 end File_Stamp;
  
 function File_Stamp (Name : Path_Name_Type) return Time_Stamp_Type is
-@@ -3261,4 +3276,28 @@ begin
+@@ -3261,4 +3276,30 @@ begin
Osint.Initialize;
 end Initialization;
  
 +   Set_Source_Date_Epoch : declare
++  --  See comments in OS_Time_To_GNAT_Time.
++  use type CRTL.int64;
++  function To_Ada is new Ada.Unchecked_Conversion (CRTL.int64, OS_Time);
 +  Env_Var : String_Access := Getenv ("SOURCE_DATE_EPOCH");
-+  Epoch   : time_t range 0 .. time_t'Last := 0;
-+  Digit   : time_t range 0 .. 9;
++  Epoch   : CRTL.int64 range 0 .. CRTL.int64'Last := 0;
++  Digit   : CRTL.int64 range 0 .. 9;
 +   begin
 +  if 0 < Env_Var.all'Length then
 + --  Calling System.Val_LLI breaks the bootstrap sequence.
-+ --  First convert to time_t because OS_Time is private.
 + for C of Env_Var.all loop
 +if C not in '0' .. '9' then
 +   goto Finally;
 +end if;
-+Digit := time_t (Character'Pos (C) - Character'Pos ('0'));
-+if (time_t'Last - Digit) / 10 < Epoch then
++Digit := CRTL.int64 (Character'Pos (C) - Character'Pos ('0'));
++if (CRTL.int64'Last - Digit) / 10 < Epoch then
 +   goto Finally;
 +end if;
 +Epoch := Epoch * 10 + Digit;

Bug#1068465: plugin thunderbird_labels and keyboard_shortcuts causing traces

[Christian Schwamborn]

Package: roundcube-plugins-extra
Version: 1.4.10+1-4

I got an error like this, trying to set a message Flag:

[05-Apr-2024 15:16:54 UTC] PHP Warning:  Undefined property:
rcmail::$imap in
/usr/share/roundcube/plugins/thunderbird_labels/thunderbird_labels.php
on line 318
[05-Apr-2024 15:16:54 UTC] PHP Fatal error:  Uncaught TypeError:
array_merge(): Argument #1 must be of type array, null given in
/usr/share/roundcube/plugins/thunderbird_labels/thunderbird_labels.php:327

I think the issue is in function set_flags, around line 318 is a
definition '$imap = $this->rc->imap;'.
The object $this->rc->imap seems to be renamed to $this->rc->storage.
Changing this one line fixed the issue for me.

The same issue can be found in keyboard_shortcuts.
Replacing '$rcmail->imap' with '$rcmail->storage' between lines 104 and
109 fixes the issue there.

Bug#783011: Skip /etc/awstats/awstats.conf if it's not configured

[Christian Weiske]

I created several awstats.mydomain.conf files which all include the
default awstats.conf file as base config.

I'd prefer that awstats.conf is skipped once domain config files exist.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

Bug#1065221: Packaging multivolumefile?

[Andreas Tille]

Hi Yokota,

Am Tue, Apr 02, 2024 at 08:39:36PM +0200 schrieb Andreas Tille:
> > Nevermind, YOKOTA Hiroshi already has done this and more and is looking
> > for sponsors.
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065221#17
> 
> Thanks a lot for your packaging work.  My very personal sponsoring
> policy is that I sponsor only team maintained packages.  If you move
> your packages to DPT I'll happily sponsor your work. 

Thanks a lot for all your work on the said pre-requisites and moving
them to DPT.  For the moment I've picked python-multivolumefile and
python-bcj and uploaded them to New queue.  My sponsoring style is to do
additional commits trying to be as verbose as possible to tell the
sponsee what to change and why.  I hope you like this.  When looking
at these two packages I've noticed a pattern of changes that were needed
to fix lintian info messages.  Please make sure to run

   lintian -I PACKAGE_VERSION_amd64.changes

to learn about what changes might be sensible to silence lintian.
Some of them where cosmetic but I try to fix these to make sure the
lintian output is not too noisy and I might miss something that
might really need fixing.  I'd also recommend:

$ grep -v ^# ~/.lintianrc 
color=always
display-info=yes

I hope my commits are sensible to you - if not please ask back.

As a general remark:  In those teams I'm more involved we have the
tradition that sponsees leave the distribution in d/changelog to
UNRELEASED while the sponsor changes this to unstable before the final
upload.  This helps team members to immediately know about the status.
I'd be happy if you would follow this as well.

Please verify that your other packages are fixing the things I
commited to the two example packages.  If time permits I'd happily
sponsor you other packages (if nobody else in the team will beat
me in doing so).

Thanks again for all your work
   Andreas.

-- 
https://fam-tille.de

Bug#1068464: deal.ii: FTBFS: libgmp not linked, libdeal.ii.g.so.9.5.1: error: undefined reference to '__gmpn_neg'

[Drew Parsons]

Source: deal.ii
Version: 9.5.1-2
Severity: normal
Tags: ftbfs

I'm getting an error running deal.ii tests building against petsc 3.20
(from experimental)

[100%] Built target dealii_release
make  -f tests/CMakeFiles/test.dir/build.make tests/CMakeFiles/test.dir/depend
make[5]: Entering directory 
'/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu'
cd /home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu && 
/usr/bin/cmake -E cmake_depends "Unix Makefiles" 
/home/drew/projects/misc/build/deal.ii-9.5.1 
/home/drew/projects/misc/build/deal.ii-9.5.1/tests 
/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu 
/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu/tests 
/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu/tests/CMakeFiles/test.dir/DependInfo.cmake
 "--color="
make[5]: Leaving directory 
'/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu'
make  -f tests/CMakeFiles/test.dir/build.make tests/CMakeFiles/test.dir/build
make[5]: Entering directory 
'/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu'
[100%] Running quicktests...
/usr/bin/cmake -DCMAKE_BUILD_TYPE=DEBUG -P 
/home/drew/projects/misc/build/deal.ii-9.5.1/tests/run_quick_tests.cmake
-- Running quick_tests in DEBUG mode with -j8:
Test project /home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu
  Start 19: test_dependency/quick_tests.mpi.debug.executable
  Start 23: test_dependency/quick_tests.p4est.debug.executable
  Start 29: test_dependency/quick_tests.step-metis.debug.executable
  Start  1: quick_tests/adolc.debug
  Start  3: quick_tests/affinity.debug
  Start  4: quick_tests/affinity.release
  Start  5: quick_tests/assimp.debug
  Start  7: quick_tests/boost_zlib.debug
 1/25 Test  #1: quick_tests/adolc.debug 
...***Failed9.33 sec
/home/drew/projects/misc/build/deal.ii-9.5.1/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/libdeal.ii.g.so.9.5.1:
 error: undefined reference to '__gmpn_neg'
collect2: error: ld returned 1 exit status
gmake[9]: *** [CMakeFiles/quick_tests.adolc.debug.dir/build.make:299: 
adolc.debug/adolc.debug] Error 1
gmake[8]: *** [CMakeFiles/Makefile2:261: 
CMakeFiles/quick_tests.adolc.debug.dir/all] Error 2
gmake[7]: *** [CMakeFiles/Makefile2:294: 
CMakeFiles/quick_tests.adolc.debug.test.dir/rule] Error 2
gmake[6]: *** [Makefile:173: quick_tests.adolc.debug.test] Error 2

Likewise undefined __gmpn_com with quick_tests/affinity.release,
quick_tests/step.release.  All 25 tests fail with either undefined
__gmpn_neg or __gmpn_com.


__gmp* is provided by libgmp, which suggests build configuration for
gmp is not getting through, not setting -lgmp for linking.

deal.ii recently built successfully in unstable (for time_t), so it's
not time to mark this bug severity: serious.  I get it when trying to
rebuild against petsc 3.20 from experimental. But it's not obvious to
me that petsc 3.20 itself would be triggering the problem.  Perhaps
it's a local issue on my system with the experimental petsc builds
that might resolve itself after we upload petsc 3.20 to unstable,
which I've requested in transition Bug#1067064.

Filing this bug to keep track, or see if anyone else is experiencing
the same problem.


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

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

Bug#1068463: procyon: Untrusted code execution via cwd in classpath

[Tomas Tintera]

Package: procyon-decompiler
Version: 0.6.0-1
Tags: security
Severity: grave

In the default configuration, procyon prepends current working directory
to the java classpath.
This is done in the shell script /usr/bin/procyon, which sets, apparently
by mistake, CLASSPATH=$CLASSPATH:..., where $CLASSPATH is a usually
empty environment variable - and empty string in this context is
interpreted as a current working directory by java.

This is potentially dangerous, especially with a decompiler, which is
supposed to deal with untrusted code. In a possible bad scenario, a user
(without CLASSPATH environment variable, which is the debian default)
might try to decompile an untrusted malicious jar:

wget ".../bad.jar"
jar xf bad.jar
procyon ...

Regardless of what command line arguments are given to procyon,
if the extracted jar contained e.g. the jcommander class, then
it will get executed.

Bug#1068462: gpac: CVE-2024-28318 CVE-2024-28319 CVE-2023-46426 CVE-2023-46427 CVE-2024-24265 CVE-2024-24266 CVE-2024-24267

[Moritz Mühlenhoff]

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

Hi,

The following vulnerabilities were published for gpac.

CVE-2024-28318[0]:
| gpac 2.3-DEV-rev921-g422b78ecf-master was discovered to contain a
| out of boundary write vulnerability via swf_get_string at
| scene_manager/swf_parse.c:325

https://github.com/gpac/gpac/issues/2764
https://github.com/gpac/gpac/commit/ae831621a08a64e3325ce532f8b78811a1581716

CVE-2024-28319[1]:
| gpac 2.3-DEV-rev921-g422b78ecf-master was discovered to contain an
| out of boundary read vulnerability via gf_dash_setup_period
| media_tools/dash_client.c:6374

https://github.com/gpac/gpac/issues/2763
https://github.com/gpac/gpac/commit/cb3c29809bddfa32686e3deb231a76af67b68e1e

CVE-2023-46426[2]:
| Heap-based Buffer Overflow vulnerability in gpac version 2.3-DEV-
| rev588-g7edc40fee-master, allows remote attackers to execute
| arbitrary code and cause a denial of service (DoS) via gf_fwrite
| component in at utils/os_file.c.

https://github.com/gpac/gpac/issues/2642
https://github.com/gpac/gpac/commit/14ec709a1ffae23ad777c37320290caa0a754341

CVE-2023-46427[3]:
| An issue was discovered in gpac version 2.3-DEV-rev588-g7edc40fee-
| master, allows remote attackers to execute arbitrary code, cause a
| denial of service (DoS), and obtain sensitive information via null
| pointer deference in gf_dash_setup_period component in
| media_tools/dash_client.c.

https://github.com/gpac/gpac/issues/2641
https://github.com/gpac/gpac/commit/ed8424300fc4a1f5231ecd1d47f502ddd3621d1a

CVE-2024-24265[4]:
| gpac v2.2.1 was discovered to contain a memory leak via the
| dst_props variable in the gf_filter_pid_merge_properties_internal
| function.

https://github.com/yinluming13579/gpac_defects/blob/main/gpac_1.md

CVE-2024-24266[5]:
| gpac v2.2.1 was discovered to contain a Use-After-Free (UAF)
| vulnerability via the dasher_configure_pid function at
| /src/filters/dasher.c.

https://github.com/yinluming13579/gpac_defects/blob/main/gpac_2.md

CVE-2024-24267[6]:
| gpac v2.2.1 was discovered to contain a memory leak via the
| gfio_blob variable in the gf_fileio_from_blob function.

https://github.com/yinluming13579/gpac_defects/blob/main/gpac_3.md

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-28318
https://www.cve.org/CVERecord?id=CVE-2024-28318
[1] https://security-tracker.debian.org/tracker/CVE-2024-28319
https://www.cve.org/CVERecord?id=CVE-2024-28319
[2] https://security-tracker.debian.org/tracker/CVE-2023-46426
https://www.cve.org/CVERecord?id=CVE-2023-46426
[3] https://security-tracker.debian.org/tracker/CVE-2023-46427
https://www.cve.org/CVERecord?id=CVE-2023-46427
[4] https://security-tracker.debian.org/tracker/CVE-2024-24265
https://www.cve.org/CVERecord?id=CVE-2024-24265
[5] https://security-tracker.debian.org/tracker/CVE-2024-24266
https://www.cve.org/CVERecord?id=CVE-2024-24266
[6] https://security-tracker.debian.org/tracker/CVE-2024-24267
https://www.cve.org/CVERecord?id=CVE-2024-24267

Please adjust the affected versions in the BTS as needed.

Bug#1068461: freeimage: CVE-2024-28562 CVE-2024-28563 CVE-2024-28564 CVE-2024-28565 CVE-2024-28566 CVE-2024-28567 CVE-2024-28568 CVE-2024-28569 CVE-2024-28570 CVE-2024-28571 CVE-2024-28572 CVE-2024-28

[Moritz Mühlenhoff]

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

Hi,

The following vulnerabilities were published for freeimage. They are all
only published at 
https://github.com/Ruanxingzhi/vul-report/tree/master/freeimage-r1909
and don't appear to be forwarded upstream yet.

CVE-2024-28562[0]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to execute arbitrary code via the
| Imf_2_2::copyIntoFrameBuffer() component when reading images in EXR
| format.


CVE-2024-28563[1]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the Imf_2_2::DwaCompressor::Classifier::Classifier() function
| when reading images in EXR format.


CVE-2024-28564[2]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the Imf_2_2::CharPtrIO::readChars() function when reading images
| in EXR format.


CVE-2024-28565[3]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the psdParser::ReadImageData() function when reading images in
| PSD format.


CVE-2024-28566[4]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to execute arbitrary code via the
| AssignPixel() function when reading images in TIFF format.


CVE-2024-28567[5]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the FreeImage_CreateICCProfile() function when reading images in
| TIFF format.


CVE-2024-28568[6]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the read_iptc_profile() function when reading images in TIFF
| format.


CVE-2024-28569[7]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to execute arbitrary code via the
| Imf_2_2::Xdr::read() function when reading images in EXR format.


CVE-2024-28570[8]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the processMakerNote() function when reading images in JPEG
| format.


CVE-2024-28571[9]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the fill_input_buffer() function when reading images in JPEG
| format.


CVE-2024-28572[10]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the FreeImage_SetTagValue() function when reading images in JPEG
| format.


CVE-2024-28573[11]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the jpeg_read_exif_profile() function when reading images in
| JPEG format.


CVE-2024-28574[12]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the opj_j2k_copy_default_tcp_and_create_tcd() function when
| reading images in J2K format.


CVE-2024-28574[13]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the opj_j2k_copy_default_tcp_and_create_tcd() function when
| reading images in J2K format.


CVE-2024-28575[14]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the opj_j2k_read_mct() function when reading images in J2K
| format.


CVE-2024-28576[15]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the opj_j2k_tcp_destroy() function when reading images in J2K
| format.


CVE-2024-28577[16]:
| Null Pointer Dereference vulnerability in open source FreeImage
| v.3.19.0 [r1909] allows a local attacker to cause a denial of
| service (DoS) via the jpeg_read_exif_profile_raw() function when
| reading images in JPEG format.


CVE-2024-28578[17]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to execute arbitrary code via the
| Load() function when reading images in RAS format.


CVE-2024-28579[18]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to cause a denial of service (DoS)
| via the FreeImage_Unload() function when reading images in HDR
| format.


CVE-2024-28580[19]:
| Buffer Overflow vulnerability in open source FreeImage v.3.19.0
| [r1909] allows a local attacker to execute arbitrary code via the
| ReadData() function when 

Bug#974750: imagemagick-6.q16: Convert to .tga (Targa) now flips image upside-down

[Matija Nalis]

related graphicsmagick bugreport:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016653

-- 
Opinions above are GNU-copylefted.

Bug#1068460: docker.io: CVE-2024-29018

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for docker.io.

CVE-2024-29018[0]:
| Moby is an open source container framework that is a key component
| of Docker Engine, Docker Desktop, and other distributions of
| container tooling or runtimes. Moby's networking implementation
| allows for many networks, each with their own IP address range and
| gateway, to be defined. This feature is frequently referred to as
| custom networks, as each network can have a different driver, set of
| parameters and thus behaviors. When creating a network, the
| `--internal` flag is used to designate a network as _internal_. The
| `internal` attribute in a docker-compose.yml file may also be used
| to mark a network _internal_, and other API clients may specify the
| `internal` parameter as well.  When containers with networking are
| created, they are assigned unique network interfaces and IP
| addresses. The host serves as a router for non-internal networks,
| with a gateway IP that provides SNAT/DNAT to/from container IPs.
| Containers on an internal network may communicate between each
| other, but are precluded from communicating with any networks the
| host has access to (LAN or WAN) as no default route is configured,
| and firewall rules are set up to drop all outgoing traffic.
| Communication with the gateway IP address (and thus appropriately
| configured host services) is possible, and the host may communicate
| with any container IP directly.  In addition to configuring the
| Linux kernel's various networking features to enable container
| networking, `dockerd` directly provides some services to container
| networks. Principal among these is serving as a resolver, enabling
| service discovery, and resolution of names from an upstream
| resolver.  When a DNS request for a name that does not correspond to
| a container is received, the request is forwarded to the configured
| upstream resolver. This request is made from the container's network
| namespace: the level of access and routing of traffic is the same as
| if the request was made by the container itself.  As a consequence
| of this design, containers solely attached to an internal network
| will be unable to resolve names using the upstream resolver, as the
| container itself is unable to communicate with that nameserver. Only
| the names of containers also attached to the internal network are
| able to be resolved.  Many systems run a local forwarding DNS
| resolver. As the host and any containers have separate loopback
| devices, a consequence of the design described above is that
| containers are unable to resolve names from the host's configured
| resolver, as they cannot reach these addresses on the host loopback
| device. To bridge this gap, and to allow containers to properly
| resolve names even when a local forwarding resolver is used on a
| loopback address, `dockerd` detects this scenario and instead
| forward DNS requests from the host namework namespace. The loopback
| resolver then forwards the requests to its configured upstream
| resolvers, as expected.  Because `dockerd` forwards DNS requests to
| the host loopback device, bypassing the container network
| namespace's normal routing semantics entirely, internal networks can
| unexpectedly forward DNS requests to an external nameserver. By
| registering a domain for which they control the authoritative
| nameservers, an attacker could arrange for a compromised container
| to exfiltrate data by encoding it in DNS queries that will
| eventually be answered by their nameservers.  Docker Desktop is not
| affected, as Docker Desktop always runs an internal resolver on a
| RFC 1918 address.  Moby releases 26.0.0, 25.0.4, and 23.0.11 are
| patched to prevent forwarding any DNS requests from internal
| networks. As a workaround, run containers intended to be solely
| attached to internal networks with a custom upstream address, which
| will force all upstream DNS queries to be resolved from the
| container's network namespace.

https://github.com/moby/moby/security/advisories/GHSA-mq39-4gv4-mvpx
https://github.com/moby/moby/pull/46609


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1068458: netdata: build and ship netdata-plugin-systemd-journal

[Didier 'OdyX' Raboud]

Source: netdata
Version: 1.44.3-2
Severity: wishlist

Dear Maintainer,

it would be really useful to have netdata-plugin-systemd-journal,
especially as a way to circumvent their future requirement to rely on
their cloud offer:
https://github.com/netdata/netdata/discussions/16136#discussioncomment-9014755

I think it mostly boils down to build-depending on libsystemd-dev and
shipping the plugin somewhere.

Happy to help; best,
OdyX

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

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

Bug#1068459: murano: CVE-2024-29156

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for murano.

CVE-2024-29156[0]:
| In OpenStack Murano through 16.0.0, when YAQL before 3.0.0 is used,
| the Murano service's MuranoPL extension to the YAQL language fails
| to sanitize the supplied environment, leading to potential leakage
| of sensitive service account information.

https://bugs.launchpad.net/murano/+bug/2048114
https://wiki.openstack.org/wiki/OSSN/OSSN-0093

No fix in Murano, but a change in src:python-yaql renders this unexploitable:
https://opendev.org/openstack/yaql/commit/83e28324e1a0ce3970dd854393d2431123a909d3
 (3.0.0)


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1063757:

[matte . mb2006 . 9990]

I removed the NVIDIA driver but the problem persists.

Bug#1068455: varnish: CVE-2024-30156

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for varnish.

CVE-2024-30156[0]:
| Varnish Cache before 7.3.2 and 7.4.x before 7.4.3 (and before 6.0.13
| LTS), and Varnish Enterprise 6 before 6.0.12r6, allows credits
| exhaustion for an HTTP/2 connection control flow window, aka a Broke
| Window Attack.

https://varnish-cache.org/security/VSV00014.html
https://varnish-cache.org/docs/7.5/whats-new/changes-7.5.html#cve-2024-30156
https://github.com/varnishcache/varnish-cache/commit/c0201724f0280894ec714fe76fc26ba9831f0551
 (varnish-7.5.0)
https://github.com/varnishcache/varnish-cache/commit/727a5f80347545b6fc7a6aa48f9fb74e90528f0c
 (varnish-7.5.0)
https://github.com/varnishcache/varnish-cache/commit/42a10e90015bd8a9cb1c7c2e0e313f8b5ae9ebe9
 (varnish-7.5.0)
https://github.com/varnishcache/varnish-cache/commit/eccb50837d61fcb5a6927eef94c570bd1d03c26d
 (varnish-7.5.0)
https://github.com/varnishcache/varnish-cache/commit/0b82e00708b88f696af5881b7a19caf2144d13f7
 (varnish-7.5.0)
https://github.com/varnishcache/varnish-cache/commit/4938f05b318eb2daa2ccc89dafeed3126552c481
 (varnish-7.5.0)
https://github.com/varnishcache/varnish-cache/commit/41ef373af53571a94ea8f73f0538322270799a84
 (varnish-7.5.0)


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1068457: azure-uamqp-python: CVE-2024-29195

[Moritz Mühlenhoff]

Source: azure-uamqp-python
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for azure-uamqp-python.

CVE-2024-29195[0]:
| The azure-c-shared-utility is a C library for AMQP/MQTT
| communication to Azure Cloud Services. This library may be used by
| the Azure IoT C SDK for communication between IoT Hub and IoT Hub
| devices. An attacker can cause an integer wraparound or under-
| allocation or heap buffer overflow due to vulnerabilities in
| parameter checking mechanism, by exploiting the buffer length
| parameter in Azure C SDK, which may lead to remote code execution.
| Requirements for RCE are 1. Compromised Azure account allowing
| malformed payloads to be sent to the device via IoT Hub service, 2.
| By passing IoT hub service max message payload limit of 128KB, and
| 3. Ability to overwrite code space with remote code. Fixed in commit
| https://github.com/Azure/azure-c-shared-
| utility/commit/1129147c38ac02ad974c4c701a1e01b2141b9fe2.

https://github.com/Azure/azure-c-shared-utility/security/advisories/GHSA-m8wp-hc7w-x4xg
https://github.com/Azure/azure-c-shared-utility/commit/1129147c38ac02ad974c4c701a1e01b2141b9fe2


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1068456: RFP: aerospike-database -- Distributed, scalable NoSQL database that supports both strict and eventual consistency

[Federico Ceratto]

Package: wnpp
Severity: wishlist

* Package name: aerospike-database
  Version : 7.0.0.7
  Upstream Contact: Aerospike
* URL : https://aerospike.com/
* License : AGPL-3.0
  Programming Lang: C
  Description : Distributed, scalable NoSQL database that supports both 
strict and eventual consistency

Aerospike is a distributed, scalable NoSQL database. It is architected with 
three key objectives:
To create a high-performance, scalable platform that would meet the needs of 
today's web-scale applications
To provide the robustness and reliability (i.e., ACID) expected from 
traditional databases.
To provide operational efficiency (minimal manual involvement)

Bug#1068454: qt6-base: CVE-2024-30161

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for qt6-base.

CVE-2024-30161[0]:
| In Qt before 6.5.6 and 6.6.x before 6.6.3, the wasm component may
| access QNetworkReply header data via a dangling pointer.

https://codereview.qt-project.org/c/qt/qtbase/+/544314
https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=a5b00cefef12999e9a213943855abe6bc0ab5365


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1068453: request-tracker5: CVE-2024-3262

[Moritz Mühlenhoff]

Source: request-tracker5
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for request-tracker5.

CVE-2024-3262[0]:
| Information exposure vulnerability in RT software affecting version
| 4.4.1. This vulnerability allows an attacker with local access to
| the device to retrieve sensitive information about the application,
| such as vulnerability tickets, because the application stores the
| information in the browser cache, leading to information exposure
| despite session termination.

https://github.com/bestpractical/rt/commit/ea07e767eaef5b202e8883051616d09806b8b48a
https://github.com/bestpractical/rt/commit/468f86bd3e82c3b5b5ef7087d416a7509d4b1abe


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1068452: request-tracker4: CVE-2024-3262

[Moritz Mühlenhoff]

Source: request-tracker4
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for request-tracker4.

CVE-2024-3262[0]:
| Information exposure vulnerability in RT software affecting version
| 4.4.1. This vulnerability allows an attacker with local access to
| the device to retrieve sensitive information about the application,
| such as vulnerability tickets, because the application stores the
| information in the browser cache, leading to information exposure
| despite session termination.

https://github.com/bestpractical/rt/commit/ea07e767eaef5b202e8883051616d09806b8b48a
https://github.com/bestpractical/rt/commit/468f86bd3e82c3b5b5ef7087d416a7509d4b1abe


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.