Bug#958895: libevhtp-dev: libtool arguments failure

[Vincent Bernat]

On 2023-01-12 08:46, Alexandre Rossi wrote:

Now that the blocking bug is fixed, I thing the patch should be uploaded to 
unstable.
Do you want me to prepare a build for you to upload?


Yes, please do.

Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy

[Alexandre Rossi]

Hi,

If I can help providing a build ready to upload for this, do not hesitate to 
ping me.

Alex

Bug#1000151: certbot.service: please provide some logs in journal

[Alexandre Rossi]

Hi,

If I can help providing a build ready to upload for this, do not hesitate to 
ping me.

Alex

Bug#958895: libevhtp-dev: libtool arguments failure

[Alexandre Rossi]

Hi,

Now that the blocking bug is fixed, I thing the patch should be uploaded to 
unstable.
Do you want me to prepare a build for you to upload?

Thanks,

Alex

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Control: tags 1026920 patch

Christoph Biedl wrote...

> It took a few hours to realize locale setting ruin your day. I could
> reproduce that only with LC_ALL=C, and then bisecting led to:
> 
> commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
> Author: Christos Zoulas 
> Date:   Sat May 28 01:04:57 2022 +
> 
> PR/351: CathyKMeow: octalify unprintable characters in filenames 
> unless raw.

... and there is a command-line option to bypass this.

So this should do the trick, worked for me:

--- a/lib/Lintian/Index/FileTypes.pm
+++ b/lib/Lintian/Index/FileTypes.pm
@@ -72,7 +72,7 @@ sub add_file_types {
 my @files = grep { $_->is_file } @{$self->sorted_list};
 my @names = map { $_->name } @files;
 
-my @command = qw(file --no-pad --print0 --print0 --);
+my @command = qw(file --raw --no-pad --print0 --print0 --);
 
 my %file_types;
 

Cheers,

Christoph


signature.asc
Description: PGP signature

Bug#1028451: 2nd DisplayPort doesn't get video

[Didier 'OdyX' Raboud]

Hello there,

It's really time-consuming to download, reboot, wait cryptsetup prompt, fail,
reboot, wait cryptsetup prompt, type long passphrase, log in account, dpkg -i,
reboot, rinse repeat.

Anyway, I can confirm that on my Lenovo X13 AMD;

* 6.1~rc3+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc5+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc6+1~exp1 doesn't boot until the cryptsetup prompt
* 6.1~rc7+1~exp1 boots until the cryptsetup prompt, but the culprit screen
  doesn't get anything

So it seems the issue was already there in 6.1~rc7+1~exp1, but I can't rewind
further.

Hope that helps!

OdyX

11 janvier 2023 10:04 "Diederik de Haas"  a écrit:

> On Wednesday, 11 January 2023 08:33:29 CET Didier 'OdyX' Raboud wrote:
> 
>> Package: src:linux
>> Version: 6.1.4-1
>> Severity: serious
>> 
>> Since booting 6.1.0-1, the 2nd DisplayPort output from my Lenovo Docking
>> Station doesn't get any output.
> 
> Can you try the previous versions of the 6.1.x series which you can get via
> snapshot.debian.org? I recommend to start with the first 6.1-rcX version.
> 
> A `git bisect` is the best way to figure out what caused it, but the above
> procedure is the quickest way to narrow down the search space.

Bug#1028468: bullseye-pu: package tomcat9/9.0.43-2~deb11u5

[Salvatore Bonaccorso]

Hi Utkarsh,

On Wed, Jan 11, 2023 at 07:14:42PM +0530, Utkarsh Gupta wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Tags: bullseye
> Severity: normal
> 
> Hello,
> 
> src:tomcat9 has been affected by debbug #1020948 which was fixed in
> sid and thus would want to backport the fix to bullseye in the next
> point release.
> 
> It was noticed that the tomcat-locate-java.sh script which seems to be
> in charge of identifying the Java version to use doesn't have version
> 17 listed. This is a trivial (and thus a low regression) fix.
> 
> Debdiff is duly attached. Let me know if you any more information. TIA! \o/

Only a suggestion, given your LTS team involvement with security
updates: If you have enough spare time, there are two CVEs as well,
which would would not warrant an immediate DSA, marked
no-dsa/postponed, which could be included in a bullseye-pu update?

https://security-tracker.debian.org/tracker/CVE-2022-42252
https://security-tracker.debian.org/tracker/CVE-2022-45143

Regards,
Salvatore

Bug#1028512: python3-sqlmodel: Depends: python3-sqlalchemy (< 1.4.46) but 1.4.46+ds1-1 is to be installed

[Adrian Bunk]

Package: python3-sqlmodel
Version: 0.0.8-3
Severity: grave

The following packages have unmet dependencies:
 python3-sqlmodel : Depends: python3-sqlalchemy (< 1.4.46) but 1.4.46+ds1-1 is 
to be installed

Bug#1028514: apper depends on the removed software-properties-kde

[Adrian Bunk]

Package: apper
Version: 1.0.0-3
Severity: grave

apper depends on the removed software-properties-kde.

Bug#1028513: dovecot: autopkgtest failure with python3.11

[Bas Couwenberg]

Source: dovecot
Version: 1:2.3.19.1+dfsg1-2
Severity: serious
Tags: patch
Justification: autopkgtest failure

Dear Maintainer,

The autopkgtest for your package fails with python3.11 because the crypt module 
is deprecated:

 autopkgtest [17:21:34]: test testmails: [---
 /tmp/autopkgtest-lxc.pzurscq6/downtmp/build.WWw/src/debian/tests/testmails:3: 
DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13
   import crypt
 test_imap (__main__.DovecotBasics.test_imap)
 Test IMAP4 protocol. ... ok
 test_imaps (__main__.DovecotBasics.test_imaps)
 Test IMAP4S protocol. ... ok
 test_pop3 (__main__.DovecotBasics.test_pop3)
 Test POP3 protocol. ... ok
 test_pop3s (__main__.DovecotBasics.test_pop3s)
 Test POP3S protocol. ... ok
 
 --
 Ran 4 tests in 78.337s
 
 OK
 autopkgtest [17:22:53]: test testmails: ---]
 autopkgtest [17:22:53]: test testmails:  - - - - - - - - - - results - - - - - 
- - - - -
 testmailsFAIL stderr: 
/tmp/autopkgtest-lxc.pzurscq6/downtmp/build.WWw/src/debian/tests/testmails:3: 
DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13
 autopkgtest [17:22:53]: test testmails:  - - - - - - - - - - stderr - - - - - 
- - - - -
 /tmp/autopkgtest-lxc.pzurscq6/downtmp/build.WWw/src/debian/tests/testmails:3: 
DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13
   import crypt
 autopkgtest [17:22:53]:  summary
 doveadm  PASS
 systemd  PASS
 command1 PASS
 testmailsFAIL stderr: 
/tmp/autopkgtest-lxc.pzurscq6/downtmp/build.WWw/src/debian/tests/testmails:3: 
DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13

The attached patch resolves the issue by using python3-passlib which has a pure 
Python implemention to fall back on when the crypt module is not available.

Kind Regards,

Bas
>From b02ebc95e735a488c6a71b2f68774dd7332d16ff Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Thu, 12 Jan 2023 08:04:19 +0100
Subject: Don't use deprecated crypt module.

---
 debian/tests/control   | 2 +-
 debian/tests/testmails | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 106e5d04a..496cfcc0b 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -11,4 +11,4 @@ Restrictions: needs-root, breaks-testbed, allow-stderr
 
 Tests: testmails
 Restrictions: needs-root, breaks-testbed
-Depends: dovecot-imapd, dovecot-pop3d, lsb-release, python3
+Depends: dovecot-imapd, dovecot-pop3d, lsb-release, python3, python3-passlib
diff --git a/debian/tests/testmails b/debian/tests/testmails
index 71ae3caab..3329809b5 100755
--- a/debian/tests/testmails
+++ b/debian/tests/testmails
@@ -1,6 +1,5 @@
 #!/usr/bin/python3
 
-import crypt
 import grp
 import imaplib
 import os
@@ -13,6 +12,8 @@ import subprocess
 import sys
 import unittest
 
+from passlib.hash import des_crypt
+
 
 def random_string(length):
 '''Return a random string, consisting of ASCII letters, with given
@@ -57,7 +58,7 @@ class TestUser:
 
 self.salt = random_string(2)
 self.password = random_string(8)
-self.crypted = crypt.crypt(self.password, self.salt)
+self.crypted = des_crypt.using(salt=self.salt).hash(self.password)
 
 subprocess.check_call(['useradd', '-p', self.crypted, '-m', login])
 
-- 
2.30.2

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Helge Kreutzmann]

Hello Sebastian,
On Wed, Jan 11, 2023 at 11:24:43PM +0100, Sebastian Andrzej Siewior wrote:
> On 2023-01-11 21:01:11 [+0100], To Helge Kreutzmann wrote:
> > > For your update you should use as version "<< 4.1.0-1".
> > > (and remember to put it in for both manpages-de and manpages-fr)
> > 
> > Okay, will do.
> 
> Just to double check: This is what I did:
>
> https://salsa.debian.org/debian/xz-utils/-/commit/6d608a9e56921abbad77f07e9e0fe4bc78e93854
> 
> and you say that this is okay, right? I'm just checking that you really
> meant 4.1.0-1 and not 4.10.0-1.

I double checked.

This is the last version of manpages-l10 which contained the templates
for unstable/stable:

## Version 4.0.0 *Mon Mar  2 22:09:38 CET 2020*


This is the first version of manpages-l10 which no longer contains the
templates for unstable/stable (but for backports!).

## Version 4.1.0 *Wed Jul  1 12:26:57 CEST 2020*


I did not check which man pages are actually shipped - this depends on
how complete the translations are. If necessary, one would need to get
the debs and review them. But I don't think this is necessary.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1028511: initramfs-tools: Please include `hyperv-keyboard` to enter LUKS password in Gen2 Hyper-V machines

[Arnaud Rebillout]

Package: initramfs-tools
Version: 0.142
Severity: normal
Tags: patch
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

As reported in the Kali Linux bug tracker, it's not possible to type the
LUKS password, in case of full disk encryption, in Gen2 Hyper-V virtual
machine. This is due to missing modules.

The original bug is at https://bugs.kali.org/view.php?id=7846, and I'll
quote the bits that are relevant:

> Because Generation 2 virtual machines in Hyper-V are presented with a
> minimal set of EFI hardware, the kernel module "hyperv_keyboard" must
> be present to interact with the console keyboard. On systems with disk
> encryption, the user will be prompted for the key to decrypt the disk,
> but cannot enter the password because no keyboard driver is present.
>
> [...]
>
> This module *is* present when the grub menu is presented and later
> when the kernel is fully loaded.  FYI, if some mechanism requires a
> mouse or touch, the hid_hyperv module will also be needed.

This issue also affects Debian, as discussed in:


This issue was also reported in the Ubuntu tracker, back in 2016:

It was fixed in Ubuntu, but the changes never made it to Debian.

Please find a merge request at:


Thanks,

  Arnaud

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Helge Kreutzmann]

Hello Sebastian,
On Wed, Jan 11, 2023 at 11:16:45PM +0100, Sebastian Andrzej Siewior wrote:
> On 2023-01-11 21:53:14 [+0100], Helge Kreutzmann wrote:
> > Hello Sebastian,
> Hello Helge,
> 
> > Well, this is not correct. See, e.g., 
> > https://packages.debian.org/bullseye-backports/all/manpages-de/filelist
> > 
> > The man pages are there. 
> 
> yes, in backports. Not in the "regular" package.

This is true - I cannot change the regular package after release - I
have to take what translators provided me at that point of time. This
is what backports is for.

> > We just took our probably final "snapshot". I.e. in the next backport
> > version, the man page as it was on monday in backports (or stable, if
> > backports was empty) is used as base. So this will be the final
> > release in bullseye-backports from our side. 
> > 
> > I don't know what the best solution is here. I see several options,
> > all not very nice:
> > 
> > 1. xz-utils does not ship translated man pages in backports. But then
> >the translated man page is out of sync with the package (it is a
> >pity that the upload to backports has not been done, already).
> > 
> > 2. I manually remove the translations in my final backport. Then there
> >is no file conflict. For this case, please tell me which man pages
> >I should delete. And the final version shipping it in backports
> >from my side would be "4.16.0-3~bpo11+1". 
> > 
> >Please tell me which version is the first backport version of your
> >package containing the translations, and I will set the appropriate
> >file relationships myself; however, I don't know if all upgrade paths 
> >will work, but we can try. 
> > 
> >With "all upgrade paths" I mean the user can have backports for
> >either package or none.
> 
> Okay. Let me get to this and then I will talk to you again once the
> release team gives an ack.

Ack.

Just for your information:
I expect upstream to release "this weekend" - but this might be
actually next monday/tuesday.

Then I might take a day or two to package this for unstable.

After migration ( ~ 5 days) I would like to prepare my backports,
which would need the proper package relations. (But I can delay this a
few days, if necessary, of course).

Greetings

 Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1028510: crmsh: Fails with python3.11

[Bas Couwenberg]

Source: crmsh
Version: 4.4.0-3
Severity: serious
Tags: upstream patch

Dear Maintainer,

Your package fails with python3.11:

 autopkgtest [17:21:55]: test pacemaker-node-status.sh: [---
 + DAEMON_TIMEOUT=60
 + CRM_TIMEOUT=5
 + ulimit -H -l unlimited
 + service corosync start
 + service pacemaker start
 + sleep 60
 + crm_node -n
 + NODE=node1
 + [ -z node1 ]
 + getent hosts node1
 + echo 127.0.0.1 node1
 + crm status
 + grep Online:.*node1
 Traceback (most recent call last):
   File "/usr/sbin/crm", line 35, in 
 from crmsh import main
   File "/usr/lib/python3/dist-packages/crmsh/main.py", line 17, in 
 from . import ui_root
   File "/usr/lib/python3/dist-packages/crmsh/ui_root.py", line 201, in 
 Root.init_ui()
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 503, in init_ui
 prepare(children, child, aliases)
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 488, in prepare
 info = ChildInfo(child, cls)
^
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 558, in __init__
 self.children = self.level.init_ui()
 
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 503, in init_ui
 prepare(children, child, aliases)
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 488, in prepare
 info = ChildInfo(child, cls)
^
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 558, in __init__
 self.children = self.level.init_ui()
 
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 503, in init_ui
 prepare(children, child, aliases)
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 494, in prepare
 add_help(info)
   File "/usr/lib/python3/dist-packages/crmsh/command.py", line 476, in add_help
 ui_utils.pretty_arguments(info.function, nskip=2)),
 ^
   File "/usr/lib/python3/dist-packages/crmsh/ui_utils.py", line 116, in 
pretty_arguments
 specs = inspect.getargspec(f)
 ^^
 AttributeError: module 'inspect' has no attribute 'getargspec'. Did you mean: 
'getargs'?
 autopkgtest [17:22:56]: test pacemaker-node-status.sh: ---]
 autopkgtest [17:22:57]: test pacemaker-node-status.sh:  - - - - - - - - - - 
results - - - - - - - - - -
 pacemaker-node-status.sh FAIL non-zero exit status 1

The attached patch resolves the issue by using inspect.getfullargspec() instead.

Kind Regards,

Bas
diff -Nru crmsh-4.4.0/debian/changelog crmsh-4.4.0/debian/changelog
--- crmsh-4.4.0/debian/changelog2022-11-13 13:18:35.0 +0100
+++ crmsh-4.4.0/debian/changelog2023-01-12 07:13:14.0 +0100
@@ -1,3 +1,10 @@
+crmsh (4.4.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to not use inspect.getargspec, removed from python3.11.
+
+ -- Bas Couwenberg   Thu, 12 Jan 2023 07:13:14 +0100
+
 crmsh (4.4.0-3) unstable; urgency=medium
 
   * d/patches: fix crmadmin parsing (Closes: #1023824)
diff -Nru crmsh-4.4.0/debian/patches/getargspec.patch 
crmsh-4.4.0/debian/patches/getargspec.patch
--- crmsh-4.4.0/debian/patches/getargspec.patch 1970-01-01 01:00:00.0 
+0100
+++ crmsh-4.4.0/debian/patches/getargspec.patch 2023-01-12 07:13:14.0 
+0100
@@ -0,0 +1,24 @@
+Description: Don't use inspect.getargspec, removed in Python 3.11.
+Author: Bas Couwenberg 
+Forwarded: https://github.com/ClusterLabs/crmsh/pull/1112
+
+--- a/crmsh/ui_utils.py
 b/crmsh/ui_utils.py
+@@ -113,7 +113,7 @@ def pretty_arguments(f, nskip=0):
+ Returns a prettified representation
+ of the command arguments
+ '''
+-specs = inspect.getargspec(f)
++specs = inspect.getfullargspec(f)
+ named_args = []
+ if specs.defaults is None:
+ named_args += specs.args
+@@ -140,7 +140,7 @@ def validate_arguments(f, args, nskip=0)
+ 
+ Note: Does not support keyword arguments.
+ '''
+-specs = inspect.getargspec(f)
++specs = inspect.getfullargspec(f)
+ min_args = len(specs.args)
+ if specs.defaults is not None:
+ min_args -= len(specs.defaults)
diff -Nru crmsh-4.4.0/debian/patches/series crmsh-4.4.0/debian/patches/series
--- crmsh-4.4.0/debian/patches/series   2022-11-13 13:02:22.0 +0100
+++ crmsh-4.4.0/debian/patches/series   2023-01-12 07:11:27.0 +0100
@@ -13,3 +13,4 @@
 0017-Fix-profiles-adoc.patch
 0018-Fix-python3-install.patch
 0019-Fix-crmadmin-parsing.patch
+getargspec.patch

Bug#1028316: libfplll8-data: missing Breaks+Replaces: libfplll7-data (>= 5.4.3)

[Nicolas Patrois]

Package: libfplll8-data
Version: 5.4.4-2
Followup-For: Bug #1028316

Dear Maintainer,

This bug prevents apt to upgrade packages, remove packages, autoremove obsolete
packages…
apt is completely broken (aptitude too) until libfplll8-data is fixed.
I reported a bug against apt to prevent such a behaviour.

Yours,
n.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.16.0-6-686-pae (SMP w/3 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1027959: transition: libkiwix

[Kunal Mehta]

Hi,

On 1/5/23 04:48, Sebastian Ramacher wrote:


I'd like to do the transition for libkiwix (and sibling libzim) in time
for bookworm, it's fully self-contained.

I uploaded src:zimlib 8.1.0 to unstable last week, which unintentionally
had a breaking change in it (sorry!). libkiwix 12.0.0 is waiting in 
experimental.


If it had an ABI breaking change, you also have to do a transition for
it. Please revert in unstable in the meantime and prepare the transition
in experimental.


Ack and done. libzim 8.1.0 is in experimental now, and unstable is back 
to 8.0.0.


Thanks,
-- Kunal

Bug#1028509: linux: Enable Intel Data Accelerators performance monitor

[Miguel Bernal Marin]

Source: linux
Version: 6.1.4-1
Severity: wishlist
Tags: patch, sid
X-Debbugs-Cc: miguel.bernal.ma...@linux.intel.com, 
jair.de.jesus.gonzalez.plascen...@intel.com

Dear Maintainer,

The last Octuber a request was made at Bug #1021337 to enable the
Intel Data Accelerators feature. It was merged at 5fbc3f893f3e ("[amd64]
drivers/dma: Enable INTEL_IDXD as module and INTEL_IDXD_SVM"), where the
feature was enabled as module and the Accelerator Shared Virtual Memory
feaure was integrated in the module (=y).

This request is to ask to inregrate the following feature to the IDXD
module:

# Intel Data Accelerators performance monitor support

  CONFIG_INTEL_IDXD_PERFMON=y

  Enable performance monitor (pmu) support for the Intel
  data accelerators present in Intel Xeon CPU.  With this
  enabled, perf can be used to monitor the DSA (Intel Data
  Streaming Accelerator) events described in the Intel DSA
  spec.

  This key integrated the prefmon.o logic to the IDXD module.

A MR was created for this request at:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/630


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/4 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

Bug#1028508: python3-packaging: Please package 23.0, 22.0 has an annoying bug

[Kai Weber]

Package: python3-packaging
Version: 22.0-2
Severity: normal
X-Debbugs-Cc: kai.weber+deb...@glorybox.de

Dear Maintainer,

please consider packaging the latest version 23.0. Version 22.0
introduced a problem that affects some packages.

See here for the upstream bug report
https://github.com/pypa/packaging/issues/629

And here a report from the pipx project
https://github.com/pypa/pipx/issues/924

Thanks for your work!


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

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

Versions of packages python3-packaging depends on:
ii  python3  3.11.1-1

python3-packaging recommends no packages.

python3-packaging suggests no packages.

-- no debconf information

Bug#1028507: digikam: downloads binary blobs from the internet

[Christoph Anton Mitterer]

Package: digikam
Version: 4:7.9.0-1+b1
Severity: important


Hey.

Every time when starting digikam, a dialog pops up asking to download
some engines for redeye removal and face detection from the internet,
which would cause them to be stored in /home/calestyo/.local/share/digikam/ 

Could that please be disabled?

a) It's a security risk. It's aboslutely unclear who controls these files
   (at least not debian).
   Further it would be code that circumvents the package management system
   and thus any security support or further things like checking for updates
   via tools like check_apt.

   Any code that's not distributed via Debian archives makes it always
   easier for an attacker to target only specific victims (rather than all
   which would be given if all users are guaranteed to get the same code),
   which makes it less likely to spot any breaches.

   Code ownloaders, even if they do e.g. signature verifications are actully
   much more difficult to do properly than just verfying a signature
   (see downgrade or replay attacks) - things which are all handled by the
   package management but perhaps not by any programs own downloaders.


b) If the files are only available as blobs, they aren't DFSG compatible
   so AFAIU, if digikam would still do so, wouldn't it no longer qualify
   for main.


c) Other packages in Debian, e.g. Firefox disable any such automatic downloads
   of security-wise at best questionable code downloaders or "self-updaters".



I also noticed that digikam, even if not downloading the stuff, creates:
  /home/user/.local/share/digikam/QtWebEngine/Default/blob_storage/
which also sounds a bit fishy.


Thanks,
Chris.

Bug#1028251: [Pkg-xen-devel] Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64

[Chuck Zmudzinski]

On 1/9/23 12:55 PM, Hans van Kranenburg wrote:
> Hi!
> 
> On 09/01/2023 18:44, Chuck Zmudzinski wrote:
>> Control: tag -1 + moreinfo
>> 
>> thanks
>> 
>> On 1/9/23 8:09 AM, Hans van Kranenburg wrote:
>>> Hi Chuck,
>>>
>>> On 1/8/23 23:18, Chuck Zmudzinski wrote:
 [...]

 The build failed:

debian/rules override_dh_missing
 make[1]: Entering directory '/home/chuckz/sources-sid/xen/xen-4.17.0'
 dh_missing --list-missing
 dh_missing: warning: usr/lib/modules-load.d/xen.conf exists in debian/tmp 
 but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/proc-xen.mount exists in 
 debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/xen-init-dom0.service exists 
 in debian/tmp but is not installed to anywhere
 dh_missing: warning: 
 usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service exists in 
 debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/xen-watchdog.service exists in 
 debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/xenconsoled.service exists in 
 debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/xendomains.service exists in 
 debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/xendriverdomain.service exists 
 in debian/tmp but is not installed to anywhere
 dh_missing: warning: usr/lib/systemd/system/xenstored.service exists in 
 debian/tmp but is not installed to anywhere
>>>
>>> I cannot reproduce this error here locally and the CI build also succeeds:
>>>
>>> https://salsa.debian.org/xen-team/debian-xen/-/pipelines/481577
>> 
>> I thought I had a fairly clean sid install, but I think the problem
>> on my system could be caused by some obscure grandfathered in
>> setting because the sid I am using was updated from all the way back to
>> an original install of jessie many years ago...
>> 
>> It might be time for me to refresh my sid with a clean installation.
>> 
>> Out of curiosity and if you have time, can you answer a couple of
>> question if you know the answer?
>> 
>> 1. Do the builds on a clean environment produce the missing files
>> listed in my build?
> 
> No, after my local package build, there's no such things in there:
> 
> ~/build/xen/debian-xen/debian/tmp/usr/lib m (master) 1-$ ll
> total 0
> drwxr-xr-x 1 knorrie knorrie  110 Jan  8 23:51 debug
> drwxr-xr-x 1 knorrie knorrie 2048 Jan  8 23:50 x86_64-linux-gnu
> drwxr-xr-x 1 knorrie knorrie   20 Jan  8 23:51 xen-4.17
> 
>> 
>> 2. Are those systemd service files installed anywhere in the xen
>> binary packages, either in arch=x86_64 packages or for the arch=all
>> packages such as xen-utils-common?
> 
> No, they are not:
> 
> https://packages.debian.org/search?searchon=contents=xenconsoled.service=path=unstable=any
> 
>> If you don't know the answer to these questions I will investigate
>> myself to find the answers, so you can work on more important things.
>> 
>>>
>>> How are you building the packages? In a clean build environment, using
>>> for example sbuild or pbuilder, or in an environment where unrelated
>>> other build dependencies could be present, that are not included in the
>>> xen list, but maybe 'wake up and do something' if they're present?
>> 
>> As I said, I am building on a sid install that might have some
>> stuff grandfathered in from old releases going back to jessie.
>> I also might have some stale stuff around from my private builds
>> of the traditional device model available from xen that is not
>> part of the Debian packages. I will investigate these possible causes.
>> 
>> I use debuild as a frontend to dpkg-buildpackage to build the packages.
> 
> Yes. So (I'm not entirely sure how it works, but as example, just making
> something up here): After doing something else first, you might end up
> with a system that has for example dh-systemd-yolo-all-the-things-helper
> installed. And, it might be that only it being present means that the
> package build process changes. It might even be a 'feature' of that
> helper... "just add it to your build depends, and it will automatically
> do all the things for you!!!~``1"
> 
> This is why it is very much recommended to build the packages using
> something like sbuild, so that you can be sure that every time it will
> start with a super minimal chroot which only has some essential things,
> and that the only build dependencies used will be the ones that are
> explicitly defined in the debian/control of the package.
>>> You can also compare your own build output with the full one from the CI
>>> job:
>>>
>>> https://salsa.debian.org/xen-team/debian-xen/-/jobs/3767564/raw

On my build:

checking for LIBNL3... yes
checking for SYSTEMD... no
checking for SYSTEMD... yes
checking for SYSTEMD... no
checking for SYSTEMD... yes
checking for bison... 

Bug#1028506: transition: libquotient

[Hubert Chathi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

reason: new upstream release
two packages affected:
- neochat: nearly builds as-is.  Only needed change is to disable
  running the tests, because the tests require a display.  (The tests
  only run with the new version of libquotient -- the tests did not run
  with the old version, so did not break the build.)
- quaternion: needs a new upstream release, which should be coming soon,
  but we can remove the current version from testing until it is released.

auto-ben from
https://release.debian.org/transitions/html/auto-libquotient.html seems
correct

Ben file:

title = "libquotient";
is_affected = .depends ~ "libquotient0.6" | .depends ~ "libquotient0.7";
is_good = .depends ~ "libquotient0.7";
is_bad = .depends ~ "libquotient0.6";

Bug#1028245: nala: missing dependency

[Blake Lee]

Hi thanks for using Nala and reporting bugs.

This has been fixed upstream actually. We're currently working through a bug 
that is causing Nala to get removed from the testing repos. Once we fix that 
and release then this will be fixed,

On Sun, Jan 8, 2023, at 2:13 PM, dimit...@stinpriza.org wrote:
> Package: nala
> Version: 0.12.0
> Severity: important
> 
> happy new year!
> 
> seems that nala fails if python3-debian is not installed. error : 
> 
> $ doas nala update
> Traceback (most recent call last):
>   File "/usr/bin/nala", line 5, in 
> from nala.__main__ import main
>   File "/usr/lib/python3/dist-packages/nala/__main__.py", line 31, in 
> import nala.fetch as _fetch  # pylint: disable=unused-import
>   File "/usr/lib/python3/dist-packages/nala/fetch.py", line 66, in 
> from debian.deb822 import Deb822  # isort:skip
> ModuleNotFoundError: No module named 'debian'
> 
> 
> installing python3-debian fixes this and nala runs as it should.. 
> but package is not listed as nala dependency..
> 
> thanks,
> d.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.142-antix.2-amd64-smp (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
> Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
> Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
> 
> Versions of packages nala depends on:
> ii  apt2.5.4.0nosystemd1
> ii  python33.10.6-3+b1
> ii  python3-anyio  3.6.2-1
> ii  python3-apt2.5.0
> ii  python3-httpx  0.23.1-1
> ii  python3-pexpect4.8.0-4
> ii  python3-rich   13.0.0-1
> ii  python3-tomli  2.0.1-2
> ii  python3-typer  0.7.0-1
> ii  python3-typing-extensions  4.3.0-2
> 
> Versions of packages nala recommends:
> ii  python3-socksio  1.0.0-2
> 
> nala suggests no packages.
> 
> -- no debconf information
> 

Bug#1028505: smplayer: prevents Gnome from turning of the screen (even if video playback is paused)

[Sandro Tosi]

Package: smplayer
Version: 22.7.0~ds0-1
Severity: important
X-Debbugs-Cc: mo...@debian.org

Hello,
as the title says, when smplayer is started, with at least a video in the play
list (even tho it's paused), it prevent GNOME (in this case with flashback
session) from shutting down the screen after the mount of time specified in

Settings > Power > Power Saving Options > Screen blank

(currently set to 3m).

I think this is an important regression from previous versions of smplayer,
hence the severity higher than normal.

Thanks,
Sandro


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

Kernel: Linux 5.17.0-3-amd64 (SMP w/8 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 smplayer depends on:
ii  libc6   2.36-7
ii  libgcc-s1   12.2.0-13
ii  libqt5core5a5.15.7+dfsg-2
ii  libqt5dbus5 5.15.7+dfsg-2
ii  libqt5gui5  5.15.7+dfsg-2
ii  libqt5network5  5.15.7+dfsg-2
ii  libqt5widgets5  5.15.7+dfsg-2
ii  libqt5xml5  5.15.7+dfsg-2
ii  libstdc++6  12.2.0-13
ii  libx11-62:1.8.3-3
ii  mplayer 4:1.4-dmo5
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages smplayer recommends:
ii  smplayer-l10n22.7.0~ds0-1
ii  smplayer-themes  1:20.11.0-1

smplayer suggests no packages.

-- no debconf information

Bug#1028504: libc6: valgrind reports "Invalid read of size 8" deep in decompose_rpath in dl-load.c

[Mike Hommey]

Package: libc6
Version: 2.36-8
Severity: important

STR:
- apt install firefox valgrind
- valgrind --show-mismatched-frees=no firefox

valgrind will quickly show errors like:
==6383== Invalid read of size 8
==6383==at 0x4023A34: strncmp (strcmp-sse2.S:162)
==6383==by 0x4004C8E: is_dst (dl-load.c:216)
==6383==by 0x4005A5E: _dl_dst_count (dl-load.c:253)
==6383==by 0x4005C37: expand_dynamic_string_token (dl-load.c:395)
==6383==by 0x4005DA2: fillin_rpath.isra.0 (dl-load.c:483)
==6383==by 0x4006092: decompose_rpath (dl-load.c:654)
==6383==by 0x400824B: _dl_map_object (dl-load.c:2111)
==6383==by 0x4002280: openaux (dl-deps.c:64)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x40025E9: _dl_map_object_deps (dl-deps.c:232)
==6383==by 0x400BB5C: dl_open_worker_begin (dl-open.c:592)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==  Address 0x4ebec59 is 9 bytes inside a block of size 15 alloc'd
==6383==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==6383==by 0x402381A: malloc (rtld-malloc.h:56)
==6383==by 0x402381A: strdup (strdup.c:42)
==6383==by 0x4006024: decompose_rpath (dl-load.c:629)
==6383==by 0x400824B: _dl_map_object (dl-load.c:2111)
==6383==by 0x4002280: openaux (dl-deps.c:64)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x40025E9: _dl_map_object_deps (dl-deps.c:232)
==6383==by 0x400BB5C: dl_open_worker_begin (dl-open.c:592)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x400B2B5: dl_open_worker (dl-open.c:782)
==6383==by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383==by 0x400B6A7: _dl_open (dl-open.c:884)

Mike

Bug#1028503: UDD: Unknown "yes" value for Forwarded field in patch metadata

[Guillem Jover]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi!

The new patch data is great, thanks! I just noticed though that it does
not recognize a "yes" value for the Forwarded field, while the
"Patch Tagging Guidelines" has this to say about it:

  * Forwarded (optional)

Any value other than "no" or "not-needed" means that the patch has
been forwarded upstream. Ideally the value is an URL proving that
it has been forwarded and where one can find more information about
its inclusion status.

If the field is missing, its implicit value is "yes" if the "Bug"
field is present, otherwise it's "no". The field is really required
only if the patch is vendor specific, in that case its value should
be "not-needed" to indicate that the patch must not be forwarded
upstream (whereas "no" simply means that it has not yet been done).

So it says that any value other than "no" or "not-needed" means
forwarded, then it says that if the field is missing it means it is an
implicit value of "yes", where I've always interpreted as implicitly
stating that "yes" is also a valid value.

(I also recently amended the patch metadata header template generated
by dpkg-source and did not have "yes" as a value there, but I've added
it locally now, and will probably queue it for dpkg 1.22.x.)

Thanks,
Guillem

Bug#1026920: New upstream version of file/libmagic breaks autopkgtest

[Christoph Biedl]

Louis-Philippe Véronneau wrote...

> Lintian runs file (more precisely, `file --no-pad --print0 --print0 --`)
> to get the "file_type" value of files [1].

Very exhausting debugging¹ reveals lintian has that file_type set to the
empty string. Obviously this causes ...

> Then, for all the files in "/usr/share/man/", it verifies .gz files are indeed
> gz-compressed with this perl regex match [2]:
> 
> if ($item->file_type !~ m/gzip compressed data/)

... this check to fail, and things go downhill from there.

> I built the test files Lintian uses for the autopkgtest and when
> I run file 1:5.43-3 on it, I do get an output that should match that regex:
> 
> -
> foo@bar:/tmp/foo/usr/share/man/man1# file -v
> > file-5.43
> > magic file from /etc/magic:/usr/share/misc/magic
> 
> foo@bar:/tmp/foo/usr/share/man/man1# file "鳥の詩.1.gz"
> > \351\263\245\343\201\256\350\251\251.1.gz: gzip compressed data, max 
> > compression, from Unix, original size modulo 2^32 145
> -

It took a few hours to realize locale setting ruin your day. I could
reproduce that only with LC_ALL=C, and then bisecting led to:

commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
Author: Christos Zoulas 
Date:   Sat May 28 01:04:57 2022 +

PR/351: CathyKMeow: octalify unprintable characters in filenames unless 
raw.

> My perl-foo is pretty bad, but I guess we should be trying to espace or 
> sanitize that value?

Problem is, since that change file(1) no longer returns the file as it
was given on the command line, and therefore add_file_types assigns the
file type to the wrong file, while the real one gets nothing at all.
.oO (from __rant__ import "use strict; use warning;")

Next I'll try

--- a/lib/Lintian/Index/FileTypes.pm
+++ b/lib/Lintian/Index/FileTypes.pm
@@ -98,6 +98,7 @@ sub add_file_types {
 }
 
 while (defined(my $path = shift @lines)) {
+$path =~ s/(\\[0-7]{3})/chr oct ($1)/eg;
 
 my $type = shift @lines;

but testing will take a while¹. I wasn't surprised if this
fails from some utf-8 vs. binary string mismatches.

Beside from that, the issue became more pressing now that file 1:5.44-1
is in unstable, blocked by this one from transitioning to testing. Which
is why I spent several hours¹ on this.

Christoph

¹ As I am in a way responsible for this situation, I agree I am
  also obliged to help resolving it. However, can you please provide a
  faster way to reproduce the failing test? Currently I am rebuilding
  and running autopkgtest, with a loop taking 50 minutes.


signature.asc
Description: PGP signature

Bug#1028502: cpdb-libs: Missing Breaks/Replaces for file move

[Jeremy Bicha]

Source: cpdb-libs
Version: 1.2.0-1
Severity: important
Tags: patch
X-Debbugs-CC: deb...@alteholz.de

The Debian packaging for cpdb-libs was based on the Ubuntu packaging.
One change was that usr/bin/print_frontend was moved to a separate
binary package. Breaks/Replaces are required for that move to avoid
upgrade problems in Ubuntu. I'm attaching a patch in my followup
email.

Thank you,
Jeremy Bicha

Bug#1028501: python3-nfs-ganesha: ships /usr/bin/ganesha-rados-grace, already in nfs-ganesha-rados-grace

[Andreas Beckmann]

Package: python3-nfs-ganesha
Version: 4.0.12-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

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

  Selecting previously unselected package python3-nfs-ganesha.
  Preparing to unpack .../102-python3-nfs-ganesha_4.0.12-2_all.deb ...
  Unpacking python3-nfs-ganesha (4.0.12-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-5OHUEb/102-python3-nfs-ganesha_4.0.12-2_all.deb 
(--unpack):
   trying to overwrite '/usr/bin/ganesha-rados-grace', which is also in package 
nfs-ganesha-rados-grace 4.0.12-2
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-5OHUEb/102-python3-nfs-ganesha_4.0.12-2_all.deb


cheers,

Andreas


nfs-ganesha-rados-grace=4.0.12-2_python3-nfs-ganesha=4.0.12-2.log.gz
Description: application/gzip

Bug#1028500: cpdb-libs: missing VCS

[Jeremy Bicha]

Source: cpdb-libs
Version: 1.2.0-1
X-Debbugs-CC: deb...@alteholz.de

There is no public repo at the location listed in the Vcs fields in
the packaging for cpdb-libs or cpdb-backend-cups.

Thank you,
Jeremy Bicha

Bug#1026093: RFS: dia/0.97.3+git20220525-5 -- Diagram editor

[Jeremy Bicha]

On Wed, Jan 11, 2023 at 4:54 PM Jeremy Bicha  wrote:
> I uploaded this for you after making my one suggested change to bump
> the urgency to high.

Actually, I was too slow and someone else uploaded first!

Thank you,
Jeremy Bicha

Bug#1028499: RM: pysha3 -- ROM; FTBFS, Bug#1028498

[Ben Finney]

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

The source package ‘pysha3’ fails to build on Debian with the supported
Python 3.11 version. This is detailed in Debian bug#1028498
https://bugs.debian.org/1028498>.

The package is unmaintained upstream. Fixing the bug appears to require
significant changes in the underlying C library code.

The package is a library for applications, and has no reverse dependencies
in Debian “unstable”. I (the package maintainer) hereby request removal of
package ‘pysha3’ from Debian.

-- 
 \   “The cost of education is trivial compared to the cost of |
  `\ ignorance.” —Thomas Jefferson |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1028498: pysha3: FTBFS, “error: lvalue required as left operand of assignment”

[Ben Finney]

Source: pysha3
Version: 1.0.2-5
Severity: serious
Tags: upstream ftbfs
Justification: Policy 4.9, FTBFS

Howdy,

When attempting to build the package from source using the Python 3.11
development libraries, this package fails to build. The relevant build
process output is:

=
running build_ext
building '_pysha3' extension
creating build/temp.linux-x86_64-cpython-311
creating build/temp.linux-x86_64-cpython-311/Modules
creating build/temp.linux-x86_64-cpython-311/Modules/_sha3
x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-DPY_WITH_KECCAK=1 -I/usr/include/python3.11 -c Modules/_sha3/sha3module.c -o 
build/temp.linux-x86_64-cpython-311/Modules/_sha3/sha3module.o
Modules/_sha3/sha3module.c: In function ‘PyInit__pysha3’:
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:744:5: note: in expansion of macro ‘init_sha3type’
  744 | init_sha3type("sha3_224", _224type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:745:5: note: in expansion of macro ‘init_sha3type’
  745 | init_sha3type("sha3_256", _256type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:746:5: note: in expansion of macro ‘init_sha3type’
  746 | init_sha3type("sha3_384", _384type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:747:5: note: in expansion of macro ‘init_sha3type’
  747 | init_sha3type("sha3_512", _512type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:749:5: note: in expansion of macro ‘init_sha3type’
  749 | init_sha3type("keccak_224", _224type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:750:5: note: in expansion of macro ‘init_sha3type’
  750 | init_sha3type("keccak_256", _256type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:751:5: note: in expansion of macro ‘init_sha3type’
  751 | init_sha3type("keccak_384", _384type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:752:5: note: in expansion of macro ‘init_sha3type’
  752 | init_sha3type("keccak_512", _512type);
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:754:5: note: in expansion of macro ‘init_sha3type’
  754 | init_sha3type("shake_128", );
  | ^
Modules/_sha3/sha3module.c:734:23: error: lvalue required as left operand of 
assignment
  734 | Py_TYPE(type) = _Type; \
  |   ^
Modules/_sha3/sha3module.c:755:5: note: in expansion of macro ‘init_sha3type’
  755 | init_sha3type("shake_256", );
  | ^
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:388: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build
=


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

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

-- 
 \ “Marriage is a wonderful institution, but who would want to |
  `\live in an institution.” —Henry L. Mencken |
_o__)  |
Ben Finney 

Bug#1028497: memcached: New upstream version available

[Bastian Germann]

Source: memcached
Version: 1.6.17-1
Severity: wishlist

Please import the new upstream version (currently 1.6.18).

Bug#843617: minizip: coordinate with minizip in src:zlib

[Bastian Germann]

Hi Michael,

On Tue, 08 Nov 2016 08:49:33 -0200 Johannes Schauer wrote:

It seems that right now we are in a situation where src:minizip ships an
outdated copy of minizip without the hopes of getting further
maintenance. The minizip original tarball is not even advertised for
download anymore on the minizip website.

Moving libminizip-dev to src:zlib would also avoid my problem with
src:vcmi because the minizip copy in src:zlib seems more up-to-date.


I do not think the minizip coordination is going anywhere.
Please just update the minizip package to have zlib's contrib/minizip source as 
upstream.

Thanks,
Bastian

Bug#1019799: Proposed MBF: wxwidgets3.2 transition

[gregor herrmann]

On Wed, 11 Jan 2023 14:30:15 -0500, Scott Talbert wrote:

> It seems that libalien-wxwidgets-perl is failing its autopkgtests.  I looked
> at it, but I can't understand why it is failing.  Can you take a look when
> you have a chance?

Thanks for noticing!

Olly also saw it, and some people have already discussed on IRC.

The reason is simple:

# /usr/bin/ld: cannot find crti.o: No such file or directory
# collect2: error: ld returned 1 exit status
# 
# ATTENTION: It apperars 'gcc' is not a working compiler, please make
# sure all necessary packages are installed.

use.t runs '/usr/bin/perl -w -M"Alien::wxWidgets" -e 1 2>&1'
in a minimal chroot, libalien-wxwidgets-perl depends on gcc [0] but not
libc6-dev (which contains crti.o) …

We haven't decided yet what's the best way out:
- skip use.t
- s/gcc/g++/ (which would pull in libc6-dev at the cost of adding
  more dependencies for reverse dependencies of libwx-perl)
- and/or some more refined solutions around libwx-perl's runtime
  dependencies

I hope that either the night shift fixes the issue one way or
another, or we'll come to a conclusion tomorrow :)


Cheers,
gregor

[0] as a result of the same test failure some years ago: 
https://bugs.debian.org/784846

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1028494: pysha3: FTBFS, expects Python header file ‘pystrhex.h’ removed in Python 3.11

[Ben Finney]

Control: retitle -1 pysha3: FTBFS, expects Python header file ‘pystrhex.h’ 
removed in Python 3.11
Control: forwarded -1 https://github.com/tiran/pysha3/issues/15
Control: tags -1 + upstream confirmed

Thanks Adrian,

On 12-Jan-2023, Adrian Bunk wrote:
> In file included from Modules/_sha3/sha3module.c:20:
> Modules/_sha3/backport.inc:78:10: fatal error: pystrhex.h: No such file or 
> directory
>78 | #include "pystrhex.h"

This is reported at the upstream project as a known bug
https://github.com/tiran/pysha3/issues/15>.

Fortunately, the code base already has a fallback local implementation of
the function, and upstream have already fixed this bug by using that local
implementation unconditionally.

I will incorporate that change in a new Debian release of this package.

-- 
 \  “Anyone who believes exponential growth can go on forever in a |
  `\finite world is either a madman or an economist.” —Kenneth |
_o__)   Boulding, 1973 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1028496: nvidia-driver: Geforce RTX 4070 Ti not supported with driver before 525.78.01

[Guillaume Clercin]

Package: nvidia-driver
Version: 470.161.03-1
Severity: wishlist

Dear maintainer,

A new graphic card has been released (RTX 4070 Ti) but it requires the lastest
version of driver (v525.78.01).
Please consider packaging this version.
Thanks.

Best regards


-- Package-specific info:
uname -a:
Linux amaterasu 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 
GNU/Linux

/proc/version:
Linux version 5.10.0-20-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.158-2 (2022-12-13)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  470.161.03  Wed Oct 19 00:10:36 
UTC 2022
GCC version:  gcc version 10.2.1 20210110 (Debian 10.2.1-6) 

lspci 'display controller [030?]':
26:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU104 [GeForce RTX 
2070 SUPER] [10de:1e84] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] TU104 [GeForce RTX 
2070 SUPER] [1462:c726]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Jan 11 20:11 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Jan 11 20:11 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Jan 11 20:11 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Jan 11 20:11 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Jan 11 20:11 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Jan 11 20:11 pci-:26:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jan 11 20:11 pci-:26:00.0-render -> ../renderD128
video:x:44:guillaume

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libcuda.so.1
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvidia-allocator.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-encode.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-fbc.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-fbc.so.1
  slave nvidia--libnvidia-fbc.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-fbc.so.1
  slave nvidia--libnvidia-ifr.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-ifr.so.1
  slave nvidia--libnvidia-ifr.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ifr.so.1
  slave nvidia--libnvidia-ml.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ngx.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ngx.so.1
  slave nvidia--libnvidia-opencl.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1
  

Bug#1028416: systemctl kexec doesn't shutdown system properly and corrupts mounted filesystems

[Michael Biebl]

Control: reassign -1 kexec-tools

Am 10.01.23 um 20:34 schrieb KOLANICH:

Package: systemd
Version: 252.4-1
Severity: grave
So do kexec-tools if a user has chosen to use it for
reboots during package configuration.
Either of the following can cause fs corruption (to the point one has to 
use `fsck -y`):
a) the procedure described in 
https://wiki.archlinux.org/title/Kexec#Manually
1. `kexec -l /boot/vmlinuz-6.0.0-6-amd64 
--initrd=/boot/initrd-6.0.0-6-amd64 --reuse-cmdline`

2. `systemctl kexec`
b) Just choosing to use kexec for reboots when installing it, and then 
rebooting.


Since systemd basically just calls kexec [1] and running kexec directly 
shows the same issue, let's reassign this to kexec-tools


Michael


[1] 
https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c#L584





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028495: kiwix-desktop fails with an undefined symbol in libkiwix.so.11

[Christian Solar]

Package: kiwix

Version: 2.3.0-1


The program kiwix-desktop aborts the startup process after following 
error message:


kiwix-desktop: symbol lookup error: 
/lib/x86_64-linux-gnu/libkiwix.so.11: undefined symbol: 
_ZNK3zim4Item7getPathB5cxx11Ev



The version of the package libkiwix11 is 11.0.0-2+b2

Bug#1028494: pysha3 FTBFS with Python 3.11 as supported version

[Adrian Bunk]

Source: pysha3
Version: 1.0.2-5
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pysha3=i386=1.0.2-5=1673471795=0

...
creating build/temp.linux-i386-cpython-311/Modules/_sha3
i686-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g 
-fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-DPY_WITH_KECCAK=1 -I/usr/include/python3.11 -c Modules/_sha3/sha3module.c -o 
build/temp.linux-i386-cpython-311/Modules/_sha3/sha3module.o
In file included from Modules/_sha3/sha3module.c:20:
Modules/_sha3/backport.inc:78:10: fatal error: pystrhex.h: No such file or 
directory
   78 | #include "pystrhex.h"
  |  ^~~~
compilation terminated.
error: command '/usr/bin/i686-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:388: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3 setup.py build 
dh_auto_build: error: pybuild --build -i python{version} -p "3.10 3.11" 
returned exit code 13
make: *** [debian/rules:20: binary-arch] Error 25

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Sebastian Andrzej Siewior]

On 2023-01-11 21:01:11 [+0100], To Helge Kreutzmann wrote:
> > For your update you should use as version "<< 4.1.0-1".
> > (and remember to put it in for both manpages-de and manpages-fr)
> 
> Okay, will do.

Just to double check: This is what I did:
   
https://salsa.debian.org/debian/xz-utils/-/commit/6d608a9e56921abbad77f07e9e0fe4bc78e93854

and you say that this is okay, right? I'm just checking that you really
meant 4.1.0-1 and not 4.10.0-1.

Sebastian

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Sebastian Andrzej Siewior]

On 2023-01-11 21:53:14 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hello Helge,

> Well, this is not correct. See, e.g., 
> https://packages.debian.org/bullseye-backports/all/manpages-de/filelist
> 
> The man pages are there. 

yes, in backports. Not in the "regular" package.

> Of course, only those we have (had) in manpages-l10n, but de
> definitely.
> 
> We just took our probably final "snapshot". I.e. in the next backport
> version, the man page as it was on monday in backports (or stable, if
> backports was empty) is used as base. So this will be the final
> release in bullseye-backports from our side. 
> 
> I don't know what the best solution is here. I see several options,
> all not very nice:
> 
> 1. xz-utils does not ship translated man pages in backports. But then
>the translated man page is out of sync with the package (it is a
>pity that the upload to backports has not been done, already).
> 
> 2. I manually remove the translations in my final backport. Then there
>is no file conflict. For this case, please tell me which man pages
>I should delete. And the final version shipping it in backports
>from my side would be "4.16.0-3~bpo11+1". 
> 
>Please tell me which version is the first backport version of your
>package containing the translations, and I will set the appropriate
>file relationships myself; however, I don't know if all upgrade paths 
>will work, but we can try. 
> 
>With "all upgrade paths" I mean the user can have backports for
>either package or none.

Okay. Let me get to this and then I will talk to you again once the
release team gives an ack.

Sebastian

Bug#1028039: Mention "use run e2fsck -f" to fix.

[Andreas Dilger]

The "extent tree (at level 1) could be narrower" message is
overly verbose and raises concerns by end users, even though
it is harmless.  On the flip side, this may save only a few
hundred blocks in the filesystem for a short period of time,
so there is little benefit to be had by printing a message.

Disable the extent optimization step in e2fsck by default by
adding the "no_optimize_extents" option to e2fsck.conf.

diff --git a/e2fsck.conf b/e2fsck.conf
new file mode 100644
index 0..b774f9ebf
--- /dev/null
+++ b/e2fsck.conf
@@ -0,0 +1,3 @@
+[options]
+# disable extent optimization to avoid spurios "errors" during runs
+no_optimize_extents=true

Bug#1015764: logwatch: get random errors about Use of uninitialized value in Exim

[Tim McConnell]

This seems to have fixed itself. Please close this.
-- 
Tim McConnell 

On Wed, 2022-07-20 at 15:20 -0500, Tim McConnell wrote:
> Package: logwatch
> Version: 7.5.6-1
> Severity: normal
> X-Debbugs-Cc: tmcconnell...@gmail.com
> 
> Dear Maintainer,
> 
> What led up to the situation? Not sure, these started randomly
> appearing in the
> email that is sent. It will be okay one report, the next one has
> these
> errors(?)
> 
> What exactly did you do (or not do) that was effective (or
> ineffective)?
> Nothing I know of was either.
> 
> What was the outcome of this action?The error in the nightly email
> reads:
> - EXIM Begin 
> 
>  Use of uninitialized value $SelfSigned in concatenation (.) or
> string at
> /usr/share/logwatch/scripts/services/exim line 334,  line 420.
> 
>  --- Self-Signed Certificate in use (  Time(s))
> 
>  -- EXIM End -
> The line numbers change also.
> 
> What outcome did you expect instead?To see:
> - EXIM Begin 
> 
> 
>  --- Self-Signed Certificate in use (2  Time(s))
> 
>  -- EXIM End -
> 
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.18.0-2-amd64 (SMP w/1 CPU thread; 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 logwatch depends on:
> ii  exim4-daemon-light [mail-transport-agent]  4.96-3
> ii  perl   5.34.0-5
> 
> Versions of packages logwatch recommends:
> ii  libdate-manip-perl   6.88-1
> ii  libsys-cpu-perl  0.61-3
> ii  libsys-meminfo-perl  0.99-2
> 
> logwatch suggests no packages.
> 
> -- no debconf information

Bug#1025985: glosstext: FTBFS: LaTeX Error: File `pdftexcmds.sty' not found.

[Hilmar Preuße]

Control: tags -1 + pending

Am 11.01.2023 um 02:48 teilte Adrian Bunk mit:

Hi,


Your package fails to build with:

|Writing index file glosstex.idx
|(/usr/share/texlive/texmf-dist/tex/latex/hypdoc/hypdoc.sty
|(/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty)
|(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
|(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
|(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty)
|
|! LaTeX Error: File `pdftexcmds.sty' not found.
...


This is basically a continuation of #1016218. :-(



Fixed on my computer, not pushed to github yet.

H.
--
sigfault

Bug#1026093: RFS: dia/0.97.3+git20220525-5 -- Diagram editor

[Jeremy Bicha]

I uploaded this for you after making my one suggested change to bump
the urgency to high.

The Debian bug tracker didn't automatically send your email to me. I
would have needed to explicitly subscribe to email updates. Therefore,
I suggest explicitly CCing people when replying to Debian bugs unless
they are the package maintainer.

Thank you,
Jeremy Bicha

Bug#1028493: geeqie: Does not print

[waxhead]

Package: geeqie
Version: 1:2.0.1-7
Severity: normal
X-Debbugs-Cc: waxh...@dirtcellar.net

Dear Maintainer,

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

   * What led up to the situation?

Tried to print a jpg picture

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

Restarted the machine, restarted printer, tried updating, looked at print queue 
(nothing), tried preview print (nothing)
Tried to print from GIMP (success)

   * What was the outcome of this action?

GIMP prints fine, geeqie does not.

   * What outcome did you expect instead?

I would like to print directly from geeqie.

*** End of the template - remove these template lines ***


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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:2.0.1-7
ii  libarchive13 3.6.2-1
ii  libc62.36-7
ii  libcairo21.16.0-7
ii  libdjvulibre21   3.5.28-2
ii  libexiv2-27  0.27.5-4
ii  libffmpegthumbnailer4v5  2.2.2+git20220218+dfsg-1+b1
ii  libgcc-s112.2.0-13
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.4-1
ii  libgspell-1-21.12.0-1+b1
ii  libgtk-3-0   3.24.36-1
ii  libheif1 1.13.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libjxl0.70.7.0-6
ii  liblcms2-2   2.14-1
ii  liblua5.3-0  5.3.6-2
ii  libopenjp2-7 2.5.0-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpoppler-glib8 22.08.0-2.1
ii  libraw20 0.20.2-2+b1
ii  libstdc++6   12.2.0-13
ii  libtiff5 4.4.0-6
ii  libwebp7 1.2.2-2+b2
ii  sensible-utils   0.0.17

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.4.2-1+b2
ii  exiftran 2.10-4
ii  exiv20.27.5-4
ii  imagemagick  8:6.9.11.60+dfsg-1.4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.4
ii  librsvg2-common  2.54.5+dfsg-1
ii  zenity   3.43.0-1

Versions of packages geeqie suggests:
ii  gimp   2.10.32-1+b2
pn  libjpeg-progs  
pn  xpaint 

-- no debconf information

Bug#1028492: gpaw FTBFS with elpa 2022.11.001

[Adrian Bunk]

Source: gpaw
Version: 22.8.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=gpaw=amd64=22.8.0-1%2Bb2=1673471220=0

...
c/elpa.c: In function ‘pyelpa_hermitian_multiply’:
c/elpa.c:238:9: warning: implicit declaration of function 
‘elpa_hermitian_multiply_d’; did you mean ‘elpa_hermitian_multiply’? 
[-Wimplicit-function-declaration]
  238 | elpa_hermitian_multiply_d(handle, uplo_a[0], uplo_c[0], ncb,
  | ^
  | elpa_hermitian_multiply
c/elpa.c:243:9: warning: implicit declaration of function 
‘elpa_hermitian_multiply_dc’; did you mean ‘elpa_hermitian_multiply’? 
[-Wimplicit-function-declaration]
  243 | elpa_hermitian_multiply_dc(handle, uplo_a[0], uplo_c[0], ncb,
  | ^~
  | elpa_hermitian_multiply
...
import _gpaw
E   ImportError: 
/<>/.pybuild/cpython3_3.11/build/_gpaw.cpython-311-x86_64-linux-gnu.so:
 undefined symbol: elpa_hermitian_multiply_dc
=== short test summary info 
ERROR ../../.. - ImportError: /<>/.pybuild/cpython...
 Interrupted: 1 error during collection 
=== 1 error in 0.12s ===
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=2: cd 
/<>/.pybuild/cpython3_3.11/build; python3.11 -m pytest -v -m ci
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 
3.11" --test-pytest "--test-args=-v -m ci" returned exit code 13
make[1]: *** [debian/rules:10: override_dh_auto_test] Error 25

Bug#1013206: O: python-fire -- automatically generate CLIs from absolutely any Python object

[Bastian Germann]

Control: retitle -1 ITA: python-fire -- automatically generate CLIs from 
absolutely any Python object
Control: owner -1 dani.be...@ubuntu.com

On Wed, 07 Dec 2022 16:54:17 +0330 =?iso-8859-6?b?x+jI6ObK6A==?= 
 wrote:
I can adopt this package from now on, since my own package is depended 
to it.


Would you please join the Python Team for that and add the package back under 
its umbrella?

Bug#1028491: Should depend on python3-lazr.restfulclient

[KOLANICH]

Package: python3-software-properties
Version: 0.99.30-1
Severity: normal
Traceback (most recent call last):
  File "/usr/bin/software-properties-qt", line 36, in  from 
softwareproperties.qt.SoftwarePropertiesQt import SoftwarePropertiesQt
  File 
"/usr/lib/python3/dist-packages/softwareproperties/qt/SoftwarePropertiesQt.py", 
line 45, in 
    from softwareproperties.SoftwareProperties import SoftwareProperties
  File 
"/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 
62, in 
    from softwareproperties.shortcuts import shortcut_handler
  File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line 
23, in 
    from softwareproperties.ppa import PPAShortcutHandler
  File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 25, in 

    from lazr.restfulclient.errors import (NotFound, BadRequest, Unauthorized)

-- System Information:
Debian Release: bookworm/sid
Versions of packages python3-software-properties depends on:
ii  gpg  2.2.40-1
ii  iso-codes    4.12.0-1
ii  lsb-release  12.0-1
ii  python3  3.11.1-1
ii  python3-apt  2.5.0
ii  python3-gi   3.42.2-3
python3-software-properties recommends no packages.
python3-software-properties suggests no packages.
-- no debconf information
 
 

Bug#991802: Your mail

[Bastian Germann]

On Thu, 5 Aug 2021 12:18:59 +0430 eshagh094  wrote:

My English is not good and I use Google Translator, if my explanations
are incomprehensible, I apologize.

few questions:
Do I have to compile the vazir font for Debian to package it?


Yes.


* Because I looked at some font sources, they used fonts made ttf or
 https://salsa.debian.org/fonts-team
Do I have to upload the font source I created to mentors.debian.net?


Not necessarily but you will have a better chance to find a sponsor if you do 
so.
Also, you should ask for sponsorship at the Fonts Team or at the pseudo package 
"sponsorship-requests".


Is the vazir font package I created ready to upload? What other changes
do I have to make?


The package is not accessible anymore.


I asked the upstream font holder at GitHub to remove the pre-made fonts,
but he said he had put them in the repository at the request of users
and was currently using several npm packages.


Then please repack as suggested.

Bug#1025274: RFS: tuxguitar/1.5.6+dfsg1-1 [QA] -- Multitrack guitar tablature editor and player

[Helmar Gerloni]

> > > ... wasn't the whole idea of Java to be arch independent?
> > That's true, but Tuxguitar comes with some audio modules written in C/C++ 
> > (see 
> > build-scripts/native-modules/).
> > I was able to cross compile them with aarch64-linux-gnu-gcc etc. on amd64. 
> > Next I will try to cross-build the whole package with sbuild (thanks for 
> > the 
> > links, Lourisvaldo).
> sbuild works fine for native builds on amd64, but fails for cross-builds ...
I was able to build the package for arm64 and ppc64el in Qemu. I assume it can 
be built on most architectures supported by Debian.

Bug#1028284: [Pkg-zfsonlinux-devel] Bug#1028284: zfs-dkms: build fails for linux-headers-6.1.0-1-amd64

[bts . debian . org]

Thanks.

Re-install helped.

Achim
On 09.01.23 15:03, Antonio Russo wrote:

On 1/9/23 01:48, Achim Schaefer wrote:

Package: zfs-dkms
Version: 2.1.7-1
Severity: important
X-Debbugs-Cc: bts.debian@schaefer-home.eu


When installing the new 6.1 kernel headers, dkms starts to build the zfs
module, but fails:
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating include/os/Makefile
config.status: creating include/os/linux/Makefile
config.status: creating include/os/linux/kernel/Makefile
config.status: creating include/os/linux/kernel/linux/Makefile
config.status: creating include/os/linux/spl/Makefile
config.status: creating include/os/linux/spl/rpc/Makefile
config.status: error: cannot find input file: 
`include/os/linux/spl/sys/Makefile.in'

Hello,

Can you please check that 
/usr/src/zfs-2.1.7/include/os/linux/spl/sys/Makefile.in
actually exists on your installation?  I.e., run

ls -l /usr/src/zfs-2.1.7/include/os/linux/spl/sys/Makefile.in

If that does not exist, please reinstall zfs-dkms; the file was somehow deleted.

On an unrelated note: BTS 1028242 means that some temporary files on ZFS with 
Linux 6.1
will not work.  (This should not be related to your compiling issue at all, 
though).

Best,
Antonio Russo

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Helge Kreutzmann]

Hello Sebastian,
On Wed, Jan 11, 2023 at 09:01:10PM +0100, Sebastian Andrzej Siewior wrote:
> On 2023-01-10 09:36:04 [+0100], Helge Kreutzmann wrote:
> > On Mon, Jan 09, 2023 at 09:38:31PM +0100, Sebastian Andrzej Siewior wrote:
> > > Oki. That means if I intend to upload xz-utils to Buster with translated
> > > man-pages than I need to check with you first?

> > This will note prevent this bug, but see below for this case. However,
> > it will fix peoples systems not using backports and upgrading from
> > bullseye to bookworm after release.
> > 
> > And this also explains why this bug was not seen on our side: During
> > this time maintainership both for upstream and for the Debian package
> > transitioned to new persons. And when I got responsible, I simply did
> > not realise this one was forgotten.
> > 
> > For bullseye:
> > Do you want to publish a backport for xz-utils? Then it gets
> > complicated.
> 
> I planned to upload the latest v5.2.X release to bullseye. Code wise it
> contains only fixes. Feature wise it contains more translations. There is
> a bug open in xz-utils that the man-page for xz vanished in xz-utils. It
> was provided by manpages-de but the release in Bullseye does not have
> it.
> The release team does not know about it and I have no idea if they allow
> so I'm checking with you first before i collides somehow with manpages-fr
> ;)

Well, this is not correct. See, e.g., 
https://packages.debian.org/bullseye-backports/all/manpages-de/filelist

The man pages are there. 

Of course, only those we have (had) in manpages-l10n, but de
definitely.

We just took our probably final "snapshot". I.e. in the next backport
version, the man page as it was on monday in backports (or stable, if
backports was empty) is used as base. So this will be the final
release in bullseye-backports from our side. 

I don't know what the best solution is here. I see several options,
all not very nice:

1. xz-utils does not ship translated man pages in backports. But then
   the translated man page is out of sync with the package (it is a
   pity that the upload to backports has not been done, already).

2. I manually remove the translations in my final backport. Then there
   is no file conflict. For this case, please tell me which man pages
   I should delete. And the final version shipping it in backports
   from my side would be "4.16.0-3~bpo11+1". 

   Please tell me which version is the first backport version of your
   package containing the translations, and I will set the appropriate
   file relationships myself; however, I don't know if all upgrade paths 
   will work, but we can try. 

   With "all upgrade paths" I mean the user can have backports for
   either package or none.

> > > > Technically, we treat debian-unstable and debian-backport as if they
> > > > were two different distributions (say arch and fedora). 
> > > > 
> > > > What got lost (and I will investigate this later this week, maybe
> > > > tomorrow) are the correct package relations. I have a vague idea, but
> > > > I will check. And the next upload (including the one to bpo) will have
> > > > the correct ones.
> > > 
> > > Since "recently" xz provides translated man-pages and sid is not
> > > affected. My understaning is that the bpo version of man-pages gets a
> > > breaks statement against xz. If so that would >= 5.2.7.
> > > Should I reassing the bug to manpages-l10n or do you do it yourself?
> > 
> > Will be done, see above. And given that upstream got the translated man 
> > pages in April 2020, I understand the quotes around "recently".
> > 
> > From your changelog I gathered the version "(<< 5.3.3alpha-0.0)".
> 
> The man-pages started to appear in 5.2.7 which I uploaded to unstable at
> the time. It was later superseded by the 5.3-beta series which become
> 5.4 (non-beta) and was cooked at the same time in experimental.

I fixed this for my upcoming package.

> …
> > As a side note:
> > We have man page translations for several other languages as well.
> > Over time, they will disappear, so I suggest to move them to xz-utils
> > as well. I can send the po files to you and inform the translators
> > about this, if you want. Then you can include them in your next upload
> > (to fix bug "-1") as well.
> 
> I would forward them to upstream if there is anything. Right now there
> are man pages in ro/de/fr.

Will do.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Diederik de Haas]

On Wednesday, 11 January 2023 19:28:25 CET Julian Groß wrote:
> On Mon, 09 Jan 2023 14:09:30 +0100 Diederik de Haas
>  wrote:
>  > https://wiki.debian.org/DebianKernel/GitBisect describes a procedure
>  > to find the exact commit which introduced the issue you reported, but it's
>  > often faster to first narrow down the range using snapshot.d.o.
> 
> The way I understand the `git bisect`, and with the issue taking
> sometimes days to happen, I will be sitting on this for months by the way.

Yep, that would/could be the consequence, which I can fully understand is not 
desirable or very useful.
Having the exact offending commit is ideal, but not a '100%' requirement.
As you've determined that it already happened with 6.0~rc7 and not with 
5.19.x, that's already a reasonably small range (likely introduced in the 6.0 
merge window).

So the next thing to do, is present the issue to the relevant upstream 
maintainers. Searching for "nvme controller is down" brought up another bug 
(but that happened pretty instantly) and in there the request was made to 
report the issue (via email) to the linux-...@vger.kernel.org and 
linux-n...@lists.infradead.org lists.
And that seems like the next best step for you too.

Use the information you provided in your initial bug report and add the extra 
findings (ie 6.1-rc7) to that too.
When you've done that, please inform this bug report where you did that so 
that we can track it's progress too.

Cheers,
  Diederik

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

Bug#1028489: transition: boost1.81

[Anton Gladky]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: boost1...@packages.debian.org
Control: affects -1 + src:boost1.81


Dear release team,

this is the placeholder for the possible upcoming boost1.81 transition.
We are working hard to prepare the transition as smooth as possible.

Large test rebuild of all dependent packages is planned.

Thanks

Ben file:

title = "boost1.81";
is_affected = .depends ~ /libboost[a-z-.]*1\.[74]/
is_good = .depends ~ /libboost[a-z-.]*1\.81/
is_bad = .depends ~ /libboost[a-z-.]*1\.74/

Bug#1028488: src:coccinelle: fails to migrate to testing for too long: FTBFS on armhf

[Paul Gevers]

Source: coccinelle
Version: 1.1.1.deb-1
Severity: serious
Control: close -1 1.1.1.deb-2
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:coccinelle has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package failed to build 
on armhf, while it built there successfully in the past.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=coccinelle



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Sebastian Ramacher]

Hi Ondřej

On 2023-01-11 20:42:28 +0100, Ondřej Surý wrote:
> Hi,
> 
> and with that I've uploaded the php-memcached and php-redis to NEW.
> 
> I've also throw in couple more extensions:
> 
> - php-xmlrpc (unbundled from PHP 8.x)
> - php-mcrypt (unbundled from PHP 8.x)
> - php-maxminddb (replacement for php-geoip)
> 
> Are there any extra extensions that the people actually using PHP would like 
> to have in Debian?
> 
> Now, what should I do about:
> 
> • Not built on buildd: arch amd64 binaries uploaded by ondrej

Those will be rebuilt semi-automatically.

> • Not built on buildd: arch all binaries uploaded by ondrej, a new 
> source-only upload is needed to allow migration

Those require a source-only upload.

Cheers

> 
> Do I really have to reupload everything that had to pass NEW with no-change 
> source-only upload?
> 
> Cheers,
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@sury.org
> 
> 
> 
> > On 8. 1. 2023, at 22:41, Ondřej Surý  wrote:
> > 
> > Hi,
> > 
> > yes, I will take care of those, I’m just uploading them in batches as the 
> > dependencies require. I’ll check all the errors tomorrow. It was just 
> > Sunday, so I was not sitting by the computer. I expect to have everything 
> > solved next week.
> > 
> > The Breaks have been added there since the last transition - there was a 
> > tendency for the apt dependency solver to pick one package (say 
> > php-imagick) from old PHP version and other one from new PHP version (say 
> > php-mysql). The Breaks was the only solution we came with that worked. I 
> > can dig up some old issues from the last transition.
> > 
> > Ondrej 
> > --
> > Ondřej Surý  (He/Him)
> > 
> >> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
> >> 
> >> Control: severity 1023370 serious
> >> Control: severity 1023381 serious
> >> 
> >> Hi Ondřej,
> >> 
> >>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
>  On 12/15/22 20:15, Ondřej Surý wrote:
>  I think everything is mostly ready in experimental. I'll try to sort out
>  the rest of the missing extensions over the weekend (imagick, memcached,
>  redis and maybe few others).
> >>> php-igbinary needs to be moved to unstable, php-apcu is built & installed 
> >>> on all release architectures.
> >>> php-raphf is also built & installed on all release architectures, but 
> >>> php-pecl-http was not staged in experimental and will need to pass NEW.
> >>> php-memcached and php-redis were not uploaded to experimental either.
> >> 
> >> I have a couple of questions:
> >> 
> >> I'm seeing that php-common has a Breaks on php8.1-common. Why is that? Is 
> >> that really needed? It makes the migration a bit more complicated as it 
> >> means that php8.1 has to be removed at the same time that php-common 
> >> migrates.
> >> 
> >> Will you also take care of src:xdebug, next to php-pecl-http, 
> >> php-memcached and php-redis as Bas suggested?
> >> 
> >> Paul
> 

-- 
Sebastian Ramacher

Bug#1027612: python-envisage: FTBFS: AssertionError: 0 != 3

[Scott Talbert]

On Tue, 10 Jan 2023, Scott Talbert wrote:


On Tue, 10 Jan 2023, Andreas Tille wrote:


Hi,

I've updated Git to latest upstream version which does not show the
reported error any more.  However, there are two other issues I seem to
need help for.  I've worked around the initial issue[1]

 FileNotFoundError: [Errno 2] No such file or directory: 'python'

with a patch[2] but this finally leads to a different error[3]

 subprocess.CalledProcessError: Command '['python3', 'setup.py', 
'bdist_egg', '--dist-dir', '/tmp/tmp14hpgj33']' returned non-zero exit 
status 1.


Any help would be welcome

Andreas.

[1] 
https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774020
[2] 
https://salsa.debian.org/python-team/packages/python-envisage/-/blob/master/debian/patches/python3.patch
[3] 
https://salsa.debian.org/python-team/packages/python-envisage/-/jobs/3774219


I'm looking into this.  It appears that something is going horribly wrong 
with the test egg generation (which is now being done upstream 
automatically).


Pushed a fix to salsa for that issue.  It seems that some of the Debian 
build environment variables were interfering with the test egg generation 
process.


Scott

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Sorry for top posting…

It’s easier for me to wait as I don’t want use custom repository for my sbuild 
chroots. Hence the wait…

Ondrej
--
Ondřej Surý  (He/Him)

> On 11. 1. 2023, at 21:01, Paul Gevers  wrote:
> 
> Hi Ondřej,
> 
>> On 11-01-2023 20:42, Ondřej Surý wrote:
>> Now, what should I do about:
>> • Not built on buildd: arch amd64 binaries uploaded by ondrej
>> • Not built on buildd: arch all binaries uploaded by ondrej, a new 
>> source-only upload is needed to allow migration
>> Do I really have to reupload everything that had to pass NEW with no-change 
>> source-only upload?
> 
> I have already NMU'd one of them (no change source only), because yes, our 
> infrastructure currently doesn't enable us to do binNMU that survives for 
> arch:all (we can do arch:any).
> 
>>> yes, I will take care of those, I’m just uploading them in batches as the 
>>> dependencies require.
> 
> Just in case you aren't aware, if the problem is that Build-Dependencies 
> aren't available yet (because of your previous batch), you don't need to wait 
> with uploading. The buildd's will know what to do and the package will stay 
> in "Builds Dependencies unavailable" until their B-D's are built and 
> available on the buildd.
> 
> Paul

Bug#1028487: dico-module-python: loading the python module in the config fails with "cannot load module python: file not found"

[Simon Heimberg]

Package: dico-module-python
Version: 2.10-1
Severity: important
X-Debbugs-Cc: simon.heimb...@heimberg-ea.ch

Dear Maintainer,

I found a problem in dico-module-python.

   * What led up to the situation?
I wanted to write a python module for dico, but could not load python
"mode".

   * What exactly did you do (or not do) that was effective (or
ineffective)?
When I included the following in the config file (/etc/dicod.conf), the
python module failed to load already.

load-module python;
# other variants with "load-module python {command python ...};" did
the same

   * What was the outcome of this action?
This error message was printed:

cannot load module python: file not found

   * What outcome did you expect instead?

I expected it to load the python module, to be able to load a database
loaded by my python code thereafter.

After research, I found out that /usr/lib/x86_64-linux-
gnu/dico/python.so does not find a dependant library. (LD_DEBUG=all
/bin/dicod ...)

I managed to get it running with setting a variable before the run:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpython3.9.so.1.0 /bin/dicod ...
or
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpython3.9.so.1 /bin/dicod ...

No idea if this happens on many systems. So here some more information
about mine:
The library l*n3.9.so.1 is a symlink to the other one (l*n3.9.so.1.0).
There is no other libpython* on my system (in any lib path).
Of course /lib is a symlink to /usr/lib/, so this files are shown once
more.


By the way, why does the package not depend on or recommend
libpython3.9 (which contains the library)? So I append some package
information additionally:
ii  libpython3.9  3.9.2-1


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

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

Versions of packages dico-module-python depends on:
ii  dicod 2.10-1
ii  libc6 2.31-13+deb11u5
ii  libdico2  2.10-1

dico-module-python recommends no packages.

dico-module-python suggests no packages.

-- no debconf information

Bug#1028363: usbguard-notifier: crashes with "terminate called after throwing an instance of 'std::runtime_error'

[Louis-Philippe Véronneau]

On 2023-01-11 01 h 26, Birger Schacht wrote:

Hi,

I can not reproduce this behavior. I started usbguard-notifier and 
removed my yubikey and replugged it:


 >  ~ usbguard-notifier --debug
 > Connection has been established
 > LOG: src/Notifier.cpp::114 [DevicePresenceChanged] Device presence 
changed signal
 > LOG: src/Notifier.cpp::114 [DevicePresenceChanged] Device presence 
changed signal
 > LOG: src/Notifier.cpp::73 [DevicePolicyChanged] Device policy changed 
signal


The crash message ("Failed to show notification") sounds to me as if 
there is maybe no notification daemon running?


cheers,
Birger


Here are the packages reportbug lists. I don't run GNOME or KDE, but a 
custom openbox DE, so maybe something is indeed missing and should be 
added in the packages' dependencies?


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (9, 'experimental')
Architecture: amd64 (x86_64)

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

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages usbguard-notifier depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.4-1
ii  libnotify4   0.8.1-1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-14
ii  libusbguard1 1.1.2+ds-3+b1

usbguard-notifier recommends no packages.

usbguard-notifier suggests no packages.

-- no debconf information



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

Bug#1028486: bullseye-pu: package jersey1/1.19.3-6

[Markus Koschany]

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

Hello,

I would like to update jersey1 in Bullseye. The package currently
FTBFS because of the latest security update of libjettison-java. The
fix is trivial. Please find attached the debdiff.

Regards,

Markus
diff -Nru jersey1-1.19.3/debian/changelog jersey1-1.19.3/debian/changelog
--- jersey1-1.19.3/debian/changelog 2019-03-02 02:04:24.0 +0100
+++ jersey1-1.19.3/debian/changelog 2022-12-31 16:49:13.0 +0100
@@ -1,3 +1,10 @@
+jersey1 (1.19.3-6+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Fix FTBFS with libjettison-java 1.5.3.
+
+ -- Markus Koschany   Sat, 31 Dec 2022 16:49:13 +0100
+
 jersey1 (1.19.3-6) unstable; urgency=medium
 
   * Fixed the build failure with librome-java >= 1.6
diff -Nru jersey1-1.19.3/debian/control jersey1-1.19.3/debian/control
--- jersey1-1.19.3/debian/control   2019-03-02 02:04:14.0 +0100
+++ jersey1-1.19.3/debian/control   2022-12-31 16:49:13.0 +0100
@@ -19,7 +19,7 @@
  libjackson-json-java,
  libjaxb-java,
  libjdom1-java,
- libjettison-java,
+ libjettison-java (>= 1.5.3),
  libjsr311-api-java,
  libmail-java,
  libmaven-bundle-plugin-java,
diff -Nru jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch 
jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch
--- jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch  1970-01-01 
01:00:00.0 +0100
+++ jersey1-1.19.3/debian/patches/libjettison-java-1.5.3.patch  2022-12-31 
16:49:13.0 +0100
@@ -0,0 +1,27 @@
+From: Markus Koschany 
+Date: Sat, 31 Dec 2022 11:56:31 +0100
+Subject: libjettison-java 1.5.3
+
+Fix FTBFS with libjettison-java 1.5.3.
+---
+ .../src/main/java/com/sun/jersey/json/impl/JSONTransformer.java   | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git 
a/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java 
b/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
+index e7c001f..46c7361 100644
+--- a/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
 b/jersey-json/src/main/java/com/sun/jersey/json/impl/JSONTransformer.java
+@@ -85,11 +85,11 @@ final class JSONTransformer {
+ return result;
+ }
+ 
+-static String asJsonArray(Collection collection) {
++static String asJsonArray(Collection collection) throws 
JSONException {
+ return (null == collection) ? "[]" : (new 
JSONArray(collection)).toString();
+ }
+ 
+-static String asJsonObject(Map map) {
++static String asJsonObject(Map map) throws JSONException {
+ return (null == map) ? "{}" : (new JSONObject(map)).toString();
+ }
+ }
diff -Nru jersey1-1.19.3/debian/patches/series 
jersey1-1.19.3/debian/patches/series
--- jersey1-1.19.3/debian/patches/series2019-03-02 01:54:20.0 
+0100
+++ jersey1-1.19.3/debian/patches/series2022-12-31 16:49:13.0 
+0100
@@ -2,3 +2,4 @@
 02-disable-moxy-support.patch
 03-add-enterprise-dependencies.patch
 04-rome-compatibility.patch
+libjettison-java-1.5.3.patch

Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Karsten Merker]

Control: tags -1 upstream
X-Debbugs-CC: debian-ri...@lists.debian.org

On Wed, Jan 11, 2023 at 09:21:42AM -0800 Vagrant Cascadian wrote:

> Definitely would be good to mention to upstream. Please Cc me if you do!

I've sent the bugreport upstream:
https://lists.denx.de/pipermail/u-boot/2023-January/504466.html

Regards,
Karsten
-- 
Hiermit widerspreche ich ausdrücklich der Nutzung sowie der Weitergabe
meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt-
oder Meinungsforschung.

Bug#1028418: signed package uploaded

[Tim Kuijsten]

I have uploaded a signed version of the package.

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


  https://netsend.nl/mongovi/v2.0.0/

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

  dget -x https://netsend.nl/mongovi/v2.0.0/mongovi_2.0.0-1.dsc

Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)

[Sebastian Andrzej Siewior]

On 2023-01-10 09:36:04 [+0100], Helge Kreutzmann wrote:
> Hello Sebastian,
Hi Helge,

> On Mon, Jan 09, 2023 at 09:38:31PM +0100, Sebastian Andrzej Siewior wrote:
> Sorry, I was really tired yesterday evening and just wanted to send a
> short "ack". 

no worries. Just warning before I get all the credit ;)

> > Oki. That means if I intend to upload xz-utils to Buster with translated
> > man-pages than I need to check with you first?
> 
> Let's separate this:
> For buster I don't think anyone will care anymore.
> 
> For bookworm: Yes, see:
> https://wiki.debian.org/PackageTransition
> Case #9: xz-utils is B, manpages-fr / manpages-de is A
> 
> For some reason I did not realize this, it is now prepared for
> manpages-l10n for the next release (slated next week, pending 
> upstream release). I did not create a bug for this (but please 
> do so, if you think it is necessary).
> 
> For your update you should use as version "<< 4.1.0-1".
> (and remember to put it in for both manpages-de and manpages-fr)

Okay, will do.

> This will note prevent this bug, but see below for this case. However,
> it will fix peoples systems not using backports and upgrading from
> bullseye to bookworm after release.
> 
> And this also explains why this bug was not seen on our side: During
> this time maintainership both for upstream and for the Debian package
> transitioned to new persons. And when I got responsible, I simply did
> not realise this one was forgotten.
> 
> For bullseye:
> Do you want to publish a backport for xz-utils? Then it gets
> complicated.

I planned to upload the latest v5.2.X release to bullseye. Code wise it
contains only fixes. Feature wise it contains more translations. There is
a bug open in xz-utils that the man-page for xz vanished in xz-utils. It
was provided by manpages-de but the release in Bullseye does not have
it.
The release team does not know about it and I have no idea if they allow
so I'm checking with you first before i collides somehow with manpages-fr
;)

> > > Technically, we treat debian-unstable and debian-backport as if they
> > > were two different distributions (say arch and fedora). 
> > > 
> > > What got lost (and I will investigate this later this week, maybe
> > > tomorrow) are the correct package relations. I have a vague idea, but
> > > I will check. And the next upload (including the one to bpo) will have
> > > the correct ones.
> > 
> > Since "recently" xz provides translated man-pages and sid is not
> > affected. My understaning is that the bpo version of man-pages gets a
> > breaks statement against xz. If so that would >= 5.2.7.
> > Should I reassing the bug to manpages-l10n or do you do it yourself?
> 
> Will be done, see above. And given that upstream got the translated man 
> pages in April 2020, I understand the quotes around "recently".
> 
> From your changelog I gathered the version "(<< 5.3.3alpha-0.0)".

The man-pages started to appear in 5.2.7 which I uploaded to unstable at
the time. It was later superseded by the 5.3-beta series which become
5.4 (non-beta) and was cooked at the same time in experimental.

…
> As a side note:
> We have man page translations for several other languages as well.
> Over time, they will disappear, so I suggest to move them to xz-utils
> as well. I can send the po files to you and inform the translators
> about this, if you want. Then you can include them in your next upload
> (to fix bug "-1") as well.

I would forward them to upstream if there is anything. Right now there
are man pages in ro/de/fr.

> Greetings
> 
>Helge
> 

Sebastian

Bug#1028374: libjna-java: JNA HelloWorld fails on aarch64

[Alexandre Rossi]

tag 1028374 patch
thanks

> I suspect debian/patches/04-load-native-code-from-fs.patch needs fixing.

Fix available for aarch64, and maybe the others (needs to get through CI to 
know).

https://salsa.debian.org/java-team/libjna-java/-/merge_requests/1/diffs?commit_id=bdc5980e070e033e0c3b04bdb93a73506ac04791

Please advise as to how to move on.


Thanks,

Alex

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Paul Gevers]

Hi Ondřej,

On 11-01-2023 20:42, Ondřej Surý wrote:

Now, what should I do about:

 • Not built on buildd: arch amd64 binaries uploaded by ondrej
 • Not built on buildd: arch all binaries uploaded by ondrej, a new 
source-only upload is needed to allow migration

Do I really have to reupload everything that had to pass NEW with no-change 
source-only upload?


I have already NMU'd one of them (no change source only), because yes, 
our infrastructure currently doesn't enable us to do binNMU that 
survives for arch:all (we can do arch:any).



yes, I will take care of those, I’m just uploading them in batches as the 
dependencies require.


Just in case you aren't aware, if the problem is that Build-Dependencies 
aren't available yet (because of your previous batch), you don't need to 
wait with uploading. The buildd's will know what to do and the package 
will stay in "Builds Dependencies unavailable" until their B-D's are 
built and available on the buildd.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998856: libvte-2.91-0[-common] 0.66.1-1 using wrong context menu font in mate-terminal

[Simon McVittie]

Control: reassign -1 mate-terminal 1.26.0-1
Control: forwarded -1 https://github.com/mate-desktop/mate-terminal/issues/407
Control: tags -1 + patch

On Wed, 11 Jan 2023 at 20:05:56 +0100, Vladis Dronov wrote:
> This bug was fixed in Ubuntu in the package mate-terminal - 1.26.0-1ubuntu2
> see: 
> https://bugs.launchpad.net/ubuntu/+source/mate-terminal/+bug/1955505/comments/2
> Probably, Debian can backport this fix.

It seems Ubuntu are treating this as a mate-terminal issue rather than a
vte issue, and the patch there is very straightforward, so reassigning
to mate-terminal.

smcv

Bug#1014460: [pkg-php-pear] Bug#1014460: transition: php8.2

[Ondřej Surý]

Hi,

and with that I've uploaded the php-memcached and php-redis to NEW.

I've also throw in couple more extensions:

- php-xmlrpc (unbundled from PHP 8.x)
- php-mcrypt (unbundled from PHP 8.x)
- php-maxminddb (replacement for php-geoip)

Are there any extra extensions that the people actually using PHP would like to 
have in Debian?

Now, what should I do about:

• Not built on buildd: arch amd64 binaries uploaded by ondrej
• Not built on buildd: arch all binaries uploaded by ondrej, a new 
source-only upload is needed to allow migration

Do I really have to reupload everything that had to pass NEW with no-change 
source-only upload?

Cheers,
Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



> On 8. 1. 2023, at 22:41, Ondřej Surý  wrote:
> 
> Hi,
> 
> yes, I will take care of those, I’m just uploading them in batches as the 
> dependencies require. I’ll check all the errors tomorrow. It was just Sunday, 
> so I was not sitting by the computer. I expect to have everything solved next 
> week.
> 
> The Breaks have been added there since the last transition - there was a 
> tendency for the apt dependency solver to pick one package (say php-imagick) 
> from old PHP version and other one from new PHP version (say php-mysql). The 
> Breaks was the only solution we came with that worked. I can dig up some old 
> issues from the last transition.
> 
> Ondrej 
> --
> Ondřej Surý  (He/Him)
> 
>> On 8. 1. 2023, at 22:24, Paul Gevers  wrote:
>> 
>> Control: severity 1023370 serious
>> Control: severity 1023381 serious
>> 
>> Hi Ondřej,
>> 
>>> On 08-01-2023 07:38, Sebastiaan Couwenberg wrote:
 On 12/15/22 20:15, Ondřej Surý wrote:
 I think everything is mostly ready in experimental. I'll try to sort out
 the rest of the missing extensions over the weekend (imagick, memcached,
 redis and maybe few others).
>>> php-igbinary needs to be moved to unstable, php-apcu is built & installed 
>>> on all release architectures.
>>> php-raphf is also built & installed on all release architectures, but 
>>> php-pecl-http was not staged in experimental and will need to pass NEW.
>>> php-memcached and php-redis were not uploaded to experimental either.
>> 
>> I have a couple of questions:
>> 
>> I'm seeing that php-common has a Breaks on php8.1-common. Why is that? Is 
>> that really needed? It makes the migration a bit more complicated as it 
>> means that php8.1 has to be removed at the same time that php-common 
>> migrates.
>> 
>> Will you also take care of src:xdebug, next to php-pecl-http, php-memcached 
>> and php-redis as Bas suggested?
>> 
>> Paul

Bug#1028485: bc: Ctrl+C does not clear the buffer

[Krzysztof Aleksander Pyrkosz]

Package: bc
Version: 1.07.1-2+b2
Severity: important
Tags: upstream
X-Debbugs-Cc: krzpyrk...@gmail.com

Dear Maintainer,

bc in the interactive mode keeps the contents of the previous line after
hitting Ctrl+C. Example:

Type 111, hit Ctrl+C, type 1+1. Expected output is 2. Observed result:

111^C
(interrupt) use quit to exit.
1+1
1112

The performed calculation is +1, definitely now what the user wants
(imagine a shell like bash not clearing the line after Ctrl+C).

There is another very annoying bug #932490 that prevents exiting with
Ctrl+D after Ctrl+C (which is common to all shells and itneractive
application I am aware of). It is also caused by the fact that the line
is not cleared after Ctrl+C.

Bug#1025784: [debian-mysql] Bug#1025784: Acknowledgement (mariadb-server-core-10.6: Can't connect to local server through socket '/run/mysqld/mysqld.sock' (111))

[Tim McConnell]

Hi Faustin, 
I do have libpam-tempdir installed: 
sudo dpkg -l | grep libpam-tmpdir
[sudo] password for tmick: 
ii  libpam-tmpdir  0.09+b2
amd64automatic per-user temporary directories

However I was getting different errors. Like so: 
RROR 2013 (HY000): Lost connection to server at 'handshake: reading
initial communication packet', system error: 104
and I have to use 'sudo systemctl start mariadb.socket' instead of
'sudo systemctl start mariadb.service' but it has to be restarted if
authentication fails.

And

2022-12-30 14:48:23 0 [ERROR] InnoDB: Operating system error number 13
in a file operation.
2022-12-30 14:48:23 0 [ERROR] InnoDB: The error means mariadbd does not
have the access rights to the directory.

MariaDB can't start because it can't read your files, the logs state it
very clearly:
Likely, you created the DB files and folders with the wrong
permissions. Please run : chown -R mysql:mysql /var/lib/mysql to fix
the issue and restart MariaDB again which allowed the DB to start etc. 
I then had to initialize it with the install_db command. 
So I'm not sure if it's a duplicate of the bug you mention, I'll leave
that to you to decide. 
Thanks!

-- 
Tim McConnell 


On Wed, 2023-01-11 at 10:52 +0100, Faustin Lammler wrote:
> Hi Tim!
> 
> Tim McConnell ,
> 10/01/2023 – 15:49:20 (-0600):
> 
> > Hi Faustin, 
> > Steps to recreate: 
> > 1.Install Mariadb client/server
> > 2. Attempt to run mysql -u root -p
> > 3. fail to be able to login
> 
> On a clean installation, I can't reproduce the problem with those
> steps
> and this is heavily tested in our CI pipelines. So, my best guess is
> that there is something else with your setup that caused the problem.
> 
> I can't be sure but what you described also in the mailing list makes
> me
> think of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022994,
> is
> it possible that you had libpam-tmpdir package installed before
> installing MariaDB?
> 
> You can verify with `dpkg -l | grep libpam-tmpdir`.
> 
> If that's the case, then this will be fixed in the next release, see:
> https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/cde8b8613e08ecb8d5f4a5de09d34418576d3040
> 
> And #1025784 should be marked as duplicate of #1022994.
> 
> Cheers!
> 

Bug#1028477: php-odbc: regression - login failed with php 8.2, works under 8.1

[Ondřej Surý]

Severity: control -1 normal

Hi,

stupid mailer on the phone sent this as HTML, resending as plain text:

> have you actually read the upgrade guide?
> 
> https://www.php.net/manual/en/migration82.incompatible.php

I believe it's not a bug, but rather result of the change described in the 
migration guide.

Ondrej

> --
> Ondřej Surý  (He/Him)
> 
>> On 11. 1. 2023, at 18:06, Joe Nahmias  wrote:
>> 
>> Package: php8.2-odbc
>> Version: 8.2.1-1
>> Severity: grave
>> X-Debbugs-Cc: j...@nahmias.net
>> 
>> Hello,
>> 
>> There seems to be a regression with php8.2-odbc, compared to php8.1-odbc:
>> 
>> $ cat /tmp/test-php_odbc.php
>> > // setup database connection
>> $u = getenv('DB_USERNAME');
>> $p = getenv('DB_PASSWORD');
>> $server = getenv('DB_HOSTNAME');
>> $dsn = "DRIVER=FreeTDS;Server=$server;Port=1433";
>> $pdo = new \PDO("odbc:$dsn", $u, $p);
>> $pdo->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);
>> print("Connected!\n");
>> 
>> $ php8.1 /tmp/test-php_odbc.php
>> Connected!
>> 
>> $ php8.2 /tmp/test-php_odbc.php
>> PHP Fatal error:  Uncaught PDOException: SQLSTATE[42000] SQLDriverConnect: 
>> 18456 [FreeTDS][SQL Server]Login failed for user 'kbUnitTests'. in 
>> /tmp/test-php_odbc.php:7
>> Stack trace:
>> #0 /tmp/test-php_odbc.php(7): PDO->__construct()
>> #1 {main}
>>  thrown in /tmp/test-php_odbc.php on line 7
>> 
>> $ dpkg -l php\* | grep ^i
>> ii  php-common 2:92+nmu1all  Common files for PHP 
>> packages
>> ii  php8.1-cli 8.1.12-1+b1  amd64command-line interpreter 
>> for the PHP scripting language
>> ii  php8.1-common  8.1.12-1+b1  amd64documentation, examples and 
>> common module for PHP
>> ii  php8.1-odbc8.1.12-1+b1  amd64ODBC module for PHP
>> ii  php8.1-opcache 8.1.12-1+b1  amd64Zend OpCache module for PHP
>> ii  php8.1-readline8.1.12-1+b1  amd64readline module for PHP
>> ii  php8.2-cli 8.2.1-1  amd64command-line interpreter 
>> for the PHP scripting language
>> ii  php8.2-common  8.2.1-1  amd64documentation, examples and 
>> common module for PHP
>> ii  php8.2-odbc8.2.1-1  amd64ODBC module for PHP
>> ii  php8.2-opcache 8.2.1-1  amd64Zend OpCache module for PHP
>> ii  php8.2-readline8.2.1-1  amd64readline module for PHP
>> 
>> Please let me know if you need any additional information!
>> --Joe
>> 

Bug#1019799: Proposed MBF: wxwidgets3.2 transition

[Scott Talbert]

On Mon, 9 Jan 2023, gregor herrmann wrote:


On Sun, 08 Jan 2023 16:56:14 -0500, Scott Talbert wrote:


On Thu, 15 Sep 2022, gregor herrmann wrote:

On Thu, 15 Sep 2022 15:13:24 -0400, Scott Talbert wrote:

Thanks for your work so far.  I'll try to take a stab at it...

Great, thank you!
(The preliminary patch is in git:
https://salsa.debian.org/perl-team/modules/packages/libwx-perl )


I just submitted a PR [1] with a patch to move libwx-perl to wxWidgets 3.2.
I tested with a few of libwx-perl's rdeps (kephra, unifont-bin, eekboek-gui
[as much as I could understand it]), and I didn't notice any obvious
problems.

[1] 
https://salsa.debian.org/perl-team/modules/packages/libwx-perl/-/merge_requests/1


Thank you very much!

Merged, and libalien-wxwidgets-perl and libwx-perl uploaded to
unstable.


Hi gregor,

It seems that libalien-wxwidgets-perl is failing its autopkgtests.  I 
looked at it, but I can't understand why it is failing.  Can you take a 
look when you have a chance?


Regards,
Scott

Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.

[Agustin Martin]

El mié, 11 ene 2023 a las 17:15, Jason Lee Quinn
() escribió:
>
> Package: dictionaries-common
> Version: 1.29.3
> Severity: minor
> X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com
>
> Dear Maintainer,
>
> About two weeks ago on a fresh install of Debian Bookworm
> from a daily installer build I
> came accross a dictionary error related to the
> installation of synaptic. The relavent output is
>
> 
>
> Setting up synaptic (0.91.2) ...
> Processing triggers for dictionaries-common (1.29.3) ...
> ispell-autobuildhash: Processing 'american' dict.
> ispell-autobuildhash: Processing 'brasilero' dict.
> ispell-autobuildhash: Processing 'british' dict.
> ispell-autobuildhash: Processing 'catala' dict.
> ispell-autobuildhash: Processing 'danish' dict.
> ispell-autobuildhash: Processing 'espa-nol' dict.
> ispell-autobuildhash: Processing 'lietuviu' dict.
> ispell-autobuildhash: Processing 'ngerman' dict.
> ispell-autobuildhash: Processing 'polish' dict.
> ispell-autobuildhash: Processing 'portugues' dict.
> ispell-autobuildhash: Processing 'russian' dict.
>
> Word '��� ��' contains illegal characters.
> ispell-autobuildhash: Processing 'swiss' dict.

HI,

This is a harmless message during hash creation for russian ispell
dict. Nothing to worry about.

> It looks to be an error in a dictionary file
> but I never selected any language except English so
> this is default behavior and as far as I can
> tell I do not even have the russian dictionary
> installed at all.

By the way, you have all those ispell dicts installed although you may
have not explicitly installed them.

Thanks for your contribution to Debian

-- 
Agustin

Bug#1026093: dia uploaded to mentors

[Philippe SWARTVAGHER]

Hello,

I uploaded dia on mentors, see RFS bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028482.

Philippe.

Bug#1028484: java-common: Please add powerpc to the list of openjdk-17 architectures

[John Paul Adrian Glaubitz]

Source: java-common
Version: 0.73
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi!

For some reason, powerpc is not in the list of openjdk-17 architectures [1]
despite openjdk-17 building fine on powerpc [2].

Could you enable openjdk-17 for powerpc for the next upload?

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/java-team/java-common/-/blob/master/debian/java_defaults.mk#L4
> [2] https://buildd.debian.org/status/package.php?p=openjdk-17=sid

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1028483: php-parser [experimental] autopkgtest timeouts

[Paul Gevers]

Source: php-parser
Version: 5.0.0~alpha1-1
Severity: important
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainer(s),

Your package in experimental has an autopkgtest, great. However, it 
fails. What's worse, it fails because it seems to hang and eventually 
times out after 2 hours and 47 minutes due to autopkgtest (while the 
version is unstable runs in mere seconds). Can you please investigate 
the situation and fix it? I copied some of the output at the bottom of 
this report.


More information about this bug and the reason for filing it can be 
found on 
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation


Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/p/php-parser/30170033/log.gz

autopkgtest [11:25:56]: test command1: [---
Proceeding without a composer.json file.phpab %development% - Copyright 
(C) 2009 - 2023 by Arne Blankerts and Contributors


Scanning directory test/PhpParser

Autoload file vendor/autoload.php generated.

PHPUnit 9.5.27 by Sebastian Bergmann and contributors.

Warning:   Your XML configuration validates against a deprecated schema.
Suggestion:Migrate your XML configuration using 
"--migrate-configuration"!


E..E.EEEF...E...EE.EFEEE.E...   61 / 
1490 (  4%)
..EE..EEE..E.  122 / 
1490 (  8%)
E...F.E..  183 / 
1490 ( 12%)
E  244 / 
1490 ( 16%)
E  305 / 
1490 ( 20%)
E  366 / 
1490 ( 24%)
EEF..  427 / 
1490 ( 28%)
..EE.  488 / 
1490 ( 32%)
...FF  549 / 
1490 ( 36%)
F  610 / 
1490 ( 40%)
FFF..  671 / 
1490 ( 45%)
.....  732 / 
1490 ( 49%)
FFF.FFautopkgtest [14:12:36]: ERROR: timed out on command "su -s 
/bin/bash debci -c set -e; export USER=`id -nu`; . /etc/profile 
>/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.2acz7iqj/downtmp/build.vwZ/src"; mkdir 
-p -m 1777 -- 
"/tmp/autopkgtest-lxc.2acz7iqj/downtmp/command1-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.2acz7iqj/downtmp/command1-artifacts"; 
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.2acz7iqj/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.2acz7iqj/downtmp/autopkgtest_tmp"; 
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; 
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=64; unset 
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY 
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT 
LC_IDENTIFICATION LC_ALL;cd "$buildtree"; exec 
/tmp/autopkgtest-lxc.2acz7iqj/downtmp/wrapper.sh 
--script-pid-file=/tmp/autopkgtest_script_pid 
--stderr=/tmp/autopkgtest-lxc.2acz7iqj/downtmp/command1-stderr 
--stdout=/tmp/autopkgtest-lxc.2acz7iqj/downtmp/command1-stdout -- bash 
-ec 'mkdir --parents vendor && phpabtpl --require nikic/php-parser > 
debian/autoload.tests.php.tpl && phpab -o vendor/autoload.php -t 
debian/autoload.tests.php.tpl test/PhpParser && phpunit' ;" (kind: test)

autopkgtest [14:12:37]: test command1: ---]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#998856: libvte-2.91-0[-common] 0.66.1-1 using wrong context menu font in mate-terminal

[Vladis Dronov]

This bug was fixed in Ubuntu in the package mate-terminal - 1.26.0-1ubuntu2
see: 
https://bugs.launchpad.net/ubuntu/+source/mate-terminal/+bug/1955505/comments/2
Probably, Debian can backport this fix.

Bug#1028482: RFS: dia/0.97.3+git20220525-5 -- Diagram editor

[Philippe SWARTVAGHER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dia
   Version  : 0.97.3+git20220525-5
   Upstream contact : Zander Brown 
* URL  : https://wiki.gnome.org/Apps/Dia/
* License  : GPL-2, GPL-2+, GFDL-NIV-1.1+
* Vcs  : https://salsa.debian.org/debian/dia
   Section  : graphics

The source builds the following binary packages:

  dia-common - Diagram editor (common files)
  dia - Diagram editor

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dia/dia_0.97.3+git20220525-5.dsc

Changes since the last upload:

dia (0.97.3+git20220525-5) unstable; urgency=medium
.
   [ Debian Janitor ]
   * Update lintian override info format in d/dia.lintian-overrides on line 2.
   * Set upstream metadata fields: Bug-Database, Bug-Submit, Contact,
 Repository-Browse.
   * Set field Upstream-Contact in debian/copyright.
   * Remove obsolete field Contact from debian/upstream/metadata (already 
present
 in machine-readable debian/copyright).
.
   [ Philippe SWARTVAGHER ]
   * Add patch for Poppler 22.09. Thanks to Nathan Pratta Teodosio
  Closes: #1026093
 - Remove wrong Origin in d/patches/poppler2206.patch
   * Bump Standards-Version to 4.6.2: no change needed

Regards,

Philippe.

Bug#1028481: Feature request: Support for custom repository package signing key

[Jim Scadden]

Package: openstack-cluster-installer
Version: 42.2.1~bpo11+1
Severity: wishlist
Tags: patch

Further to, and dependent upon, Bug#1028393, I would like to use
OpenStack Cluster Installer with packages from an internal aptly
mirror repository. Unfortunately as the packages hosted by aptly are
signed by its own keyring, this currently does not work.

The attached patches do the following:
- Add support to openstack-cluster-installer-build-live-image for using
  a custom archive keyring
- Add support to slave_install_server_os_command() in slave_actions.php
  to provide parameters to build-openstack-debian-image for custom
  archive keyring
- Add options to openstack-cluster-installer.conf for the above
- Update README with instructions for the above.

Please let me know if I'm following the correct process for raising this
request, and I'm happy to discuss the request/patches/etc.


Cheers
Jim
diff --git a/bin/openstack-cluster-installer-build-live-image b/bin/openstack-cluster-installer-build-live-image
index 12987332..4e6c97db 100755
--- a/bin/openstack-cluster-installer-build-live-image
+++ b/bin/openstack-cluster-installer-build-live-image
@@ -206,6 +206,13 @@ deb-src ${debian_incoming_buildd} buildd-sid main
 " >config/archives/incoming-buildd.list.binary
 fi
 
+# Install keyring, if configured
+if [ -n "${debian_keyring_package}" ]; then
+	cd config/archives
+	apt-get download ${debian_keyring_package}
+	cd ../..
+fi
+
 # Add the IP of the PXE server in a configuration file
 # for later use during the install process
 mkdir -p config/includes.chroot/etc/oci
@@ -863,6 +870,11 @@ if [ -d /etc/openstack-cluster-installer/live-image-additions ] ; then
 	fi
 fi
 	
+# Configure debootstrap to trust our archive keyring
+if [ -n "${debian_keyring_file}" ]; then
+	export DEBOOTSTRAP_OPTIONS="${DEBOOTSTRAP_OPTIONS} --keyring=${debian_keyring_file}"
+fi
+
 lb clean
 lb config --mirror-binary http://${OTCI_PXE_SERVER_IP}:/debian -b netboot --bootappend-live "boot=live iomem=relaxed console=tty0 console=ttyS0,115200 console=ttyS1,115200 earlyprintk=ttyS1,115200 consoleblank=0 systemd.show_status=true components url=http://${OTCI_PXE_SERVER_IP} fetch=http://${OTCI_PXE_SERVER_IP}/openstack-cluster-installer/filesystem.squashfs; --net-root-path /var/lib/openstack-cluster-installer --net-root-server ${OTCI_PXE_SERVER_IP}
 
diff --git a/src/inc/slave_actions.php b/src/inc/slave_actions.php
index 9374346f..b6056ca5 100644
--- a/src/inc/slave_actions.php
+++ b/src/inc/slave_actions.php
@@ -1376,6 +1376,9 @@ function slave_install_server_os_command($con, $conf, $machine_id){
 $package_list_file .= file_get_contents($package_list_path);
 }
 }
+if($conf["network"]["debian_keyring_package"] && $conf["network"]["install_debian_keyring_package"]){
+$package_list_file .= "," . $conf["network"]["debian_keyring_package"];
+}
 
 $cmd  = "oci-install-with-report";
 $cmd .= $network_params;
@@ -1383,6 +1386,12 @@ function slave_install_server_os_command($con, $conf, $machine_id){
 $cmd .= " --debootstrap-url ".$conf["network"]["debian_mirror"];
 $cmd .= " --sources.list-mirror ".$conf["network"]["debian_mirror"];
 $cmd .= " --security-mirror ".$conf["network"]["debian_security_mirror"];
+if($conf["network"]["debian_keyring_file"]){
+$cmd .= " --debootstrap-keyring-file " . $conf["network"]["debian_keyring_file"];
+if ($conf["network"]["install_debian_keyring_file"]) {
+$cmd .= " --copy-debootstrap-keyring-file";
+}
+}
 
 if($machine["boot_uefi"] == "yes"){
 $cmd .= " --boot-type uefi";
diff --git a/etc/openstack-cluster-installer/openstack-cluster-installer.conf b/etc/openstack-cluster-installer/openstack-cluster-installer.conf
index 9f9cb295..3d3e0935 100644
--- a/etc/openstack-cluster-installer/openstack-cluster-installer.conf
+++ b/etc/openstack-cluster-installer/openstack-cluster-installer.conf
@@ -28,6 +28,24 @@ debian_mirror=http://deb.debian.org/debian
 # Example: like http://mirror.infomaniak.com/debian-security
 debian_security_mirror=http://security.debian.org/debian-security
 
+# Package containing keyring used to sign packages in above repositories
+# this is useful when using self-hosted package repos which are not signed
+# by the official Debian archive keyring
+# Leave empty when using official debian packages
+debian_keyring_package=
+
+# Filename of keyring installed by above package (this also needs to be availble
+# on the OCI server)
+# Leave empty when using official debian packages
+debian_keyring_file=
+
+# Whether to install the keyring package specified above on OpenStack nodes
+install_debian_keyring_package=yes
+
+# Whether to copy above keyring file to OpenStack nodes (using a package instead
+# is preferred)
+install_debian_keyring_file=no
+
 # URL of the incoming buildd repo: useful for Sid development of OCI.
 debian_incoming_buildd=http://incoming.debian.org/debian-buildd
 
diff 

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[John Paul Adrian Glaubitz]

Hi!

On 1/11/23 19:45, John Paul Adrian Glaubitz wrote:

Attaching a patch which modifies debian/rules accordingly so that the build 
dependencies
are corrected after running "debian/rules debian/control".

Please consider including it for the next upload.


Oops, I just realized I forgot to add the line for "llvm". Please find an 
updated patch.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig	2022-12-29 23:21:43.0 +
+++ debian/rules	2023-01-11 18:53:56.537857661 +
@@ -688,7 +688,7 @@
 else
   ifeq "$(ALLOW_CLANG)" "y"
 ifeq "$(CLANG_VERSION)" "default"
-	  BUILD_DEPS += , llvm [$(OOO_LE_ARCHS)]
+	  BUILD_DEPS += , llvm [$(filter-out alpha ia64,$(OOO_LE_ARCHS))]
 else
 	  BUILD_DEPS += , llvm-$(CLANG_VERSION)-linker-tools [$(OOO_LE_ARCHS)]
 endif
@@ -766,7 +766,7 @@
   ifeq "$(CLANG_VERSION)" "default"
 	export LO_CLANG_CC=clang
 	export LO_CLANG_CXX=clang++
-	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))]
+	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))]
 	# see #963162, #963167 which apparently don't exist on 11
 	BUILD_DEPS += , clang (>= 1:11) [armel]
   else

Bug#1027233: prody: autopkgtest fail with numpy/1.24.1

[Sebastiaan Couwenberg]

Control: tags -1 patch

The attached patch resolves the issue.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1diff -Nru prody-2.3.1+dfsg/debian/changelog prody-2.3.1+dfsg/debian/changelog
--- prody-2.3.1+dfsg/debian/changelog   2022-12-06 08:32:42.0 +0100
+++ prody-2.3.1+dfsg/debian/changelog   2023-01-11 19:47:52.0 +0100
@@ -1,3 +1,11 @@
+prody (2.3.1+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix test failure with Numpy 1.24.
+(closes: #1027233)
+
+ -- Bas Couwenberg   Wed, 11 Jan 2023 19:47:52 +0100
+
 prody (2.3.1+dfsg-2) unstable; urgency=medium
 
   * python3-prody-tests: add missing Breaks+Replaces: python3-prody (<< 2.3.1)
diff -Nru prody-2.3.1+dfsg/debian/patches/numpy-1.24.patch 
prody-2.3.1+dfsg/debian/patches/numpy-1.24.patch
--- prody-2.3.1+dfsg/debian/patches/numpy-1.24.patch1970-01-01 
01:00:00.0 +0100
+++ prody-2.3.1+dfsg/debian/patches/numpy-1.24.patch2023-01-11 
19:47:43.0 +0100
@@ -0,0 +1,19 @@
+Description: Fix test failure with Numpy 1.24.
+Author: Bas Couwenberg 
+Bug-Debian: https://bugs.debian.org/1027233
+
+--- a/prody/compounds/pdbligands.py
 b/prody/compounds/pdbligands.py
+@@ -158,9 +158,9 @@ def fetchPDBLigand(cci, filename=None):
+ resnums = np.ones(n_atoms, dtype=ATOMIC_FIELDS['charge'].dtype)
+ 
+ alternate_atomnames = np.zeros(n_atoms, dtype=ATOMIC_FIELDS['name'].dtype)
+-leaving_atom_flags = np.zeros(n_atoms, np.bool)
+-aromatic_flags = np.zeros(n_atoms, np.bool)
+-stereo_configs = np.zeros(n_atoms, np.bool)
++leaving_atom_flags = np.zeros(n_atoms, bool)
++aromatic_flags = np.zeros(n_atoms, bool)
++stereo_configs = np.zeros(n_atoms, bool)
+ ordinals = np.zeros(n_atoms, int)
+ 
+ name2index = {}
diff -Nru prody-2.3.1+dfsg/debian/patches/series 
prody-2.3.1+dfsg/debian/patches/series
--- prody-2.3.1+dfsg/debian/patches/series  2022-12-01 12:35:56.0 
+0100
+++ prody-2.3.1+dfsg/debian/patches/series  2023-01-11 19:46:50.0 
+0100
@@ -1,2 +1,3 @@
 no-network-access.patch
 add-missing-test-files.patch
+numpy-1.24.patch

Bug#926276: Should guacamole-client be removed?

[Moritz Mühlenhoff]

reassign 926276 ftp.debian.org
retitle 926276 RM: guacamole-client -- RoQA; unmaintained, RC-buggy, open 
security issues, dropping from testing since 2017
severity 926276 normal
thanks

Am Tue, Apr 02, 2019 at 10:04:34PM +0200 schrieb Moritz Muehlenhoff:
> Source: guacamole-client
> Severity: serious
> 
> Should guacamole-client be removed?
> 
> guacamole-client hasn't been updated since 2016, is removed from testing
> since 1.5 years and has four RC bugs at this point

Reassigning for removal.

Cheers,
Moritz

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

Attaching a patch which modifies debian/rules accordingly so that the build 
dependencies
are corrected after running "debian/rules debian/control".

Please consider including it for the next upload.

Thanks a lot!
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig	2022-12-29 23:21:43.0 +
+++ debian/rules	2023-01-11 18:40:30.535026543 +
@@ -766,7 +766,7 @@
   ifeq "$(CLANG_VERSION)" "default"
 	export LO_CLANG_CC=clang
 	export LO_CLANG_CXX=clang++
-	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out armel ppc64el,$(OOO_LE_ARCHS))]
+	BUILD_DEPS += , clang (>= 1:8.0.1) [$(filter-out alpha armel ia64 ppc64el,$(OOO_LE_ARCHS))]
 	# see #963162, #963167 which apparently don't exist on 11
 	BUILD_DEPS += , clang (>= 1:11) [armel]
   else

Bug#1028480: RM: python-pynvml [armhf], nvidia-xconfig [armhf i386], nvidia-persistenced [armhf i386] -- ANAIS; needs 32-bit nvidia driver components which won't be in bookworm

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

bookworm won't ship with 32bit legacy nvidia drivers
(src:nvidia-graphics-drivers-lagacy-390xx), so we need to remove some
users (which are no longer built on the respective architectures) of
them on 32-bit architectures.


Andreas

Bug#1026988: ruby-ruby-magic-static: diff for NMU version 0.5.4-1.1

[Christoph Biedl]

Control: severity 1026988 serious
Control: tags 1026988 + patch pending

Dear maintainer,

with yesterday's upload of file 1:5.44-1 to unstable your package now
fails to build from source.

To fix the issues, I've prepared an NMU for ruby-ruby-magic-static
(versioned as 0.5.4-1.1), debdiff below. An upload to DELAYED/6 will
follow shortly. Please feel free to tell me if I should delay it longer.

Additionally, https://github.com/kwilczynski/ruby-magic/issues/38 is
about this upstream.

Regards,

Christoph

diff -Nru ruby-ruby-magic-static-0.5.4/debian/changelog 
ruby-ruby-magic-static-0.5.4/debian/changelog
--- ruby-ruby-magic-static-0.5.4/debian/changelog   2022-05-01 
23:36:22.0 +0200
+++ ruby-ruby-magic-static-0.5.4/debian/changelog   2023-01-11 
18:53:56.0 +0100
@@ -1,3 +1,10 @@
+ruby-ruby-magic-static (0.5.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Adjust PARAM_BYTES_MAX for change in file 5.44. Closes: #1026988
+
+ -- Christoph Biedl   Wed, 11 Jan 2023 
18:53:56 +0100
+
 ruby-ruby-magic-static (0.5.4-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
--- 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
   1970-01-01 01:00:00.0 +0100
+++ 
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file-bytes-max-value.patch
   2023-01-11 18:52:25.0 +0100
@@ -0,0 +1,17 @@
+Subject: Fix test breakage introduced with file 5.44
+Author: Christoph Biedl 
+Date: 2023-01-11
+Bug-Debian: https://bugs.debian.org/1026988
+Forwarded: https://github.com/kwilczynski/ruby-magic/issues/38
+
+--- a/test/test_magic.rb
 b/test/test_magic.rb
+@@ -205,7 +205,7 @@
+   end
+ 
+   def test_magic_get_parameter_with_PARAM_BYTES_MAX
+-assert_equal(1024 * 1024, @magic.get_parameter(Magic::PARAM_BYTES_MAX))
++assert_equal(1024 * 1024 * 7, 
@magic.get_parameter(Magic::PARAM_BYTES_MAX))
+   end
+ 
+   def test_magic_get_parameter_lower_boundary
diff -Nru ruby-ruby-magic-static-0.5.4/debian/patches/series 
ruby-ruby-magic-static-0.5.4/debian/patches/series
--- ruby-ruby-magic-static-0.5.4/debian/patches/series  2022-05-01 
23:36:22.0 +0200
+++ ruby-ruby-magic-static-0.5.4/debian/patches/series  2023-01-11 
18:44:05.0 +0100
@@ -1,2 +1,3 @@
 relax-mini-portile2-dependency.patch
 0002-test_magic-ignore-GC-compaction-test-on-unsupported-.patch
+adjust-for-new-file-bytes-max-value.patch


signature.asc
Description: PGP signature

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

[Julian Groß]

On Mon, 09 Jan 2023 14:09:30 +0100 Diederik de Haas 
 wrote:
> https://wiki.debian.org/DebianKernel/GitBisect describes a procedure 
to find

> the exact commit which introduced the issue you reported, but it's often
> faster to first narrow down the range using snapshot.d.o.

The way I understand the `git bisect`, and with the issue taking 
sometimes days to happen, I will be sitting on this for months by the way.


What happens if I give `git bisect` a false “good”?
Because it is perfectly possible that my computer will run fine for 48 
hours; I will tell git bisect that the revision is good; But the issue 
actually didn't trigger just by chance, instead of it not being in the 
revision.


OpenPGP_0xAF605C87F9E5AE94.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency

[Andreas Gerstmayr]

On 11.01.23 18:13, Ian Rogers wrote:

On Wed, Jan 11, 2023 at 5:18 AM Andreas Gerstmayr  wrote:


On 10.01.23 20:51, Ian Rogers wrote:

On Tue, Jan 10, 2023 at 10:02 AM Andreas Gerstmayr
 wrote:


On 05.01.23 10:24, Ian Rogers wrote:

On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers  wrote:


Currently flame graph generation requires a d3-flame-graph template to
be installed. Unfortunately this is hard to come by for things like
Debian [1]. If the template isn't installed warn and download it from
jsdelivr CDN. If downloading fails generate a minimal flame graph
again with the javascript coming from jsdelivr CDN.

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

Signed-off-by: Ian Rogers 


I'm not entirely convinced that this perf script should make a network
request. In my opinion

* best would be if this template gets packaged in Debian
* alternatively print instructions how to install the template:

   sudo mkdir /usr/share/d3-flame-graph
   sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html
https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html

* or eventually just embed the entire template (66 KB) in the Python
file (not sure if this is permissible though, it's basically a minified
HTML/JS blob)?
* if the above options don't work, I'd recommend asking the user before
making the network request, and eventually persist the template
somewhere so it doesn't need to be downloaded every time

What do you think?


So the script following this patch is going to try 3 things:
1) look for a local template HTML,
2) if a local template isn't found warn and switch to downloading the
CDN version,
3) if the CDN version fails to download then use a minimal (embedded
in the script) HTML file with JS dependencies coming from the CDN.

For (1) there are references in the generated HTML to www.w3.org,
meaning the HTML isn't fully hermetic - although these references may
not matter.


The references to w3.org are XML namespace names. As far as I'm aware
they do not matter, as they are merely identifiers and are never
accessed [1,2]. Therefore the generated HTML file in its current form is
hermetic.

This was a design decision from the start - the flame graph generation
and the resulting HTML file should not use any external resources loaded
over the network (the external host could be inaccessible or compromised
at any time). I understand that this requirement may not apply to every
user or company.


For (2) there will be a download from the CDN of the template during
the execution of flamegraph. The template is better than (3) as it
features additional buttons letting you zoom out, etc. The HTML will
contain CDN references.
For (3) the generated HTML isn't hermetic and will use the CDN.

For (2) we could give a prompt before trying to download the template,
or we could change it so that we give the wget command. I wouldn't
have the wget command require root privileges, I'd say that the
template could be downloaded and then the path of the download given
as an option to the flamegraph program. Downloading the file and then
adding an option to flamegraph seems inconvenient to the user,
something that the use of urllib in the patch avoids - it is
essentially just doing this for the user without storing the file on
disk. I think I prefer to be less inconvenient, and so the state of
the code at the moment looks best to me. Given that no choice results
in a fully hermetic HTML file, they seem similar in this regard. Is it
okay to try a download with urllib? Should there be a prompt? I think
the warning is enough and allows scripts, etc. using flamegraph to
more easily function across differing distributions.


I fully agree, your changes make the flame graph generation more
convenient in case the template is not installed. Also, downloading the
template to a local directory and having to specify the path to the
template every time is an inconvenience.

I think it is a tradeoff between convenience and security/privacy.
jsdelivr can get compromised, serving malicious JS (well, in that case,
printing instructions to jsdelivr is also flawed :|).
In the end it's up to the maintainers to decide.


Agreed. It is something of an issue with the perf tool, I think noted
by Arnaldo and Linus, that it has too many dependencies. We also have
a problem that a number of dependencies aren't license compatible for
distribution with perf's GPLv2. flamegraph.py is always installed but
it carries a dependency that can't be satisfied on Debian and
everything deriving from it. The prompting to install a package
solution, as is generally used in the build, is one approach. Using
http rather than files is the approach this change introduces, and is
an approach advocated by the d3 flamegraph README.md. Perhaps package
maintainers like Michael and Ben have opinions here.


An aside, Namhyung pointed out to me that there is a "perf report -g
folded" option, that was added in part to simplify 

Bug#1028479: bpfcc-tools: insecure use of /tmp

[Jakub Wilk]

Package: bpfcc-tools
Version: 0.25.0+ds-1
Tags: security

If kernel headers are not installed in the usual place, the BPF tools 
try to look them up in /tmp/kheaders-$(uname -r)/, even when this 
directory is owned by another user.


This can be exploited for denial of service, or likely something worse.

To reproduce, run this as a normal user:

   $ mkdir /tmp/kheaders-$(uname -r)/
   $ mkdir -p /tmp/kheaders-$(uname -r)/include/linux/
   $ echo "#error this header is malicious" > /tmp/kheaders-$(uname 
-r)/include/linux/kconfig.h

Then run this as root:

   # opensnoop-bpfcc
   In file included from :1:
   ././include/linux/kconfig.h:1:2: error: this header is malicious
   #error this header is malicious
^
   In file included from :2:
   /virtual/include/bcc/bpf.h:12:10: fatal error: 'linux/types.h' file not found
   #include 
^~~
   2 errors generated.
   Traceback (most recent call last):
 File "/usr/sbin/opensnoop-bpfcc", line 261, in 
   b = BPF(text='')
   
 File "/usr/lib/python3/dist-packages/bcc/__init__.py", line 476, in 
__init__
   raise Exception("Failed to compile BPF module %s" % (src_file or 
""))
   Exception: Failed to compile BPF module 


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=pl_PL.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 bpfcc-tools depends on:
ii  python3  3.11.1-1
ii  python3-bpfcc0.25.0+ds-1
ii  python3-netaddr  0.8.0-2

--
Jakub Wilk

Bug#1027435: ncurses-base: Breaks pasting in vim within tmux

[Sven Joachim]

On 2023-01-01 18:25 +0100, Sven Joachim wrote:

> So far so good, and I have already prepared ncurses 6.4-1 in git.  Now
> the bad news: it turned out that bracketed paste support in vim had
> (always?) been broken without anybody noticing it, because no terminal
> descriptions had included this feature.  Only two days ago Bram
> Moolenaar fixed the problem in patch 9.0.1117[1].
>
> I have backported this patch to the debian/sid branch in vim's git
> repository and can confirm that it fixes the problem, as long as
> ncurses-base is also upgraded to version 6.4-1.

James was so kind to upload this fix the next day, and so things have
been fine in unstable since then.  However Bookworm is still broken,
with vim currently unable to migrate because of vim-ultisnips'
autopkgtest failure in #1028442.

Once the fixed vim migrates to testing I intent to add versioned Breaks
on vim-common to ncurses-base and ncurses-term, so that users do not
experience the problem on partial upgrades from Bullseye, and close the
current bug.

Cheers,
   Sven

Bug#1026286: Unsatisfiable versioned dependency on python3-numpy

[Diane Trout]

On Wed, 2023-01-11 at 13:15 +0100, Enrico Zini wrote:
> 
> Thanks! I've opened
> https://github.com/numba/numba/issues/8703 upstream
> to track the possibility of numba making it in time for testing:
> let's
> see what happens.
> 


Thnaks I commented with the what I did to get numba to build.

Bug#1027686: transition: rakudo

[Dominique Dumont]

On Tuesday, 10 January 2023 11:21:32 CET Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> On 2023-01-09 13:54:08 -0500, M. Zhou wrote:
> > I missed the detail that the compiler ID even changes for different
> > architecture.. which may not be good.
> 
> Is it required that the build path of the compiler influences the ID?

Well, I don't know. I've created an issue upstream on that topic, but Raku 
devs are not really responsive on this issue. 
(see https://github.com/rakudo/rakudo/issues/5099)

> Can the computation of the ID be patched to be independent of the
> build path?

I haven't figured out completely how this compiler-id is created.

> I think it's too late to change this shortly before the freeze starts.
> If fixing the compiler ID computation is not possible, I prefer to delay
> this transition to trixie.

Agreed. Unfortunately, a lot of raku modules are currently broken or will 
break in stable if rakudo needs to be updated.

Hence my proposal to switch back to perform pre-compilation at installation 
time (detailed in my previous mail in this thread)

All the best.

Bug#1027833: user-mode-linux: hostfs directory traversal

[Jakub Wilk]

* Ritesh Raj Sarraf , 2023-01-10 18:43:
The man page says that hostfs kernel param is "used to confine all 
hostfs mounts to within the specified directory tree on the host". But 
it's trivial to escape this confinements with ../ sequences:


   # mount none -t hostfs -o ../../../../../../../../home/bob/secrets /mnt


Could you please share the kernel command line option passed to the 
running uml instance ?


I used with something like this:

   $ linux hostfs=/srv/chroots/unstable-i386/ rootfstype=hostfs init=/bin/sh 
quiet

--
Jakub Wilk

Bug#1027686: transition: rakudo

[Dominique Dumont]

On Monday, 9 January 2023 19:54:08 CET M. Zhou wrote:
> Is it possible for us to slightly modify the postinst script to
> recompile the cache locally when the compiler id mismatches?

I'd rather not. Untangling pre-compilation issues is hard enough. In case of 
problem I dont' want to wonder whether the failure comes from files compiled on 
Debian server or on user's machine.

> The fallback script rakudo-helper.pl can at least make sure
> a raku-* package is still functional even without a matching
> compiler ID. In that case we don't have to add the compiler ID
> to the virtual package name, and every architecture can track
> the same and consistent virtual package dependency.

Given the state of Raku's compiler-id, I think the only sane way (or rather 
which will preserve my sanity) is to go back to perform pre-compilation at 
installation time.

This require:
- an update of dh-raku to restore compilation at installation time.
- a modification of all raku modules to:
 - remove dependency on raku-api*
 - go back to arch:all
 - depend on next dh-raku version 

Thoughts ?

Bug#1028478: python-docutils: FTBFS with python 3.11: FAIL: test_local

[Andreas Beckmann]

Package: python-docutils
Version: 0.19+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Hi,

python-docutils/experimental FTBFS with python 3.11:

FAIL: test_local (__main__.BuildHtmlTests.test_local)
--
Traceback (most recent call last):
  File "/build/python-docutils-0.19+dfsg/tools/test/test_buildhtml.py", line 
105, in test_local
self.assertEqual(len(dirs), 1)
AssertionError: 2 != 1


Andreas


python-docutils_0.19+dfsg-2.log.gz
Description: application/gzip

Bug#1028477: php-odbc: regression - login failed with php 8.2, works under 8.1

[Ondřej Surý]

Control: severity -1 normalHi,have you actually read the upgrade guide?Backward Incompatible Changes - Manualphp.net--Ondřej Surý  (He/Him)On 11. 1. 2023, at 18:06, Joe Nahmias  wrote:Package: php8.2-odbcVersion: 8.2.1-1Severity: graveX-Debbugs-Cc: j...@nahmias.netHello,There seems to be a regression with php8.2-odbc, compared to php8.1-odbc:$ cat /tmp/test-php_odbc.php// setup database connection$u = getenv('DB_USERNAME');$p = getenv('DB_PASSWORD');$server = getenv('DB_HOSTNAME');$dsn = "DRIVER=FreeTDS;Server=$server;Port=1433";$pdo = new \PDO("odbc:$dsn", $u, $p);$pdo->setAttribute(\PDO::ATTR_ERRMODE, \PDO::ERRMODE_EXCEPTION);print("Connected!\n");$ php8.1 /tmp/test-php_odbc.phpConnected!$ php8.2 /tmp/test-php_odbc.phpPHP Fatal error:  Uncaught PDOException: SQLSTATE[42000] SQLDriverConnect: 18456 [FreeTDS][SQL Server]Login failed for user 'kbUnitTests'. in /tmp/test-php_odbc.php:7Stack trace:#0 /tmp/test-php_odbc.php(7): PDO->__construct()#1 {main}  thrown in /tmp/test-php_odbc.php on line 7$ dpkg -l php\* | grep ^iii  php-common 2:92+nmu1    all  Common files for PHP packagesii  php8.1-cli 8.1.12-1+b1  amd64    command-line interpreter for the PHP scripting languageii  php8.1-common  8.1.12-1+b1  amd64    documentation, examples and common module for PHPii  php8.1-odbc    8.1.12-1+b1  amd64    ODBC module for PHPii  php8.1-opcache 8.1.12-1+b1  amd64    Zend OpCache module for PHPii  php8.1-readline    8.1.12-1+b1  amd64    readline module for PHPii  php8.2-cli 8.2.1-1  amd64    command-line interpreter for the PHP scripting languageii  php8.2-common  8.2.1-1  amd64    documentation, examples and common module for PHPii  php8.2-odbc    8.2.1-1  amd64    ODBC module for PHPii  php8.2-opcache 8.2.1-1  amd64    Zend OpCache module for PHPii  php8.2-readline    8.2.1-1  amd64    readline module for PHPPlease let me know if you need any additional information!--Joe

Bug#531012: whysynth: Description completely wrong!

[Wolfgang Strowik]

Package: whysynth
Followup-For: Bug #531012
X-Debbugs-Cc: debianwo...@web.de

The package description is totally wrong since >11 years. Whysynth is a
Synthesizer plugin for DSSI, but the description sounds like whysynth is DSSI
itself.

You can find more information on the author's website:
http://smbolton.com/whysynth/

Maybe the priority / urgency of this bug should be increased, otherwise it will
grow >20 years old :-)

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages whysynth depends on:
ii  libc6 2.31-13+deb11u5
ii  libcairo2 1.16.0-5
ii  libfftw3-single3  3.3.8-2
ii  libglib2.0-0  2.66.8-1
ii  libgtk2.0-0   2.24.33-2
ii  liblo70.31-1

whysynth recommends no packages.

Versions of packages whysynth suggests:
ii  dssi-host-jack  1.1.1~dfsg0-5
ii  qjackctl0.9.1-1

Bug#1028343: u-boot-qemu 2023.01~rc4+dfsg-2: riscv64: FDT creation failed

[Vagrant Cascadian]

On 2023-01-11, Karsten Merker wrote:
> On Tue, Jan 10, 2023 at 09:22:02PM +0100 Karsten Merker wrote:
>
>> I've also taken a look at the u-boot changelogs and there have
>> been quite a few changes concerning u-boot's handling of
>> device-trees between the working and the non-working versions. 
>> Unfortunately I'm not familiar enough with the inner workings of
>> u-boot to understand the implications of several of these
>> changes.
>
> Hello,
>
> I've tried narrowing down the source of the issue by using
> git bisect on the u-boot tree and that has resulted in
> the following commit as the potential culprit:
>
>   commit a56f663f07073713042bb0fd08053aeb667e717b
>   Author: Simon Glass 
>   Date:   Thu Oct 20 18:23:14 2022 -0600
>
> vbe: Add info about the VBE device to the fwupd node
> 
> At present we put the driver in the /chosen node in U-Boot. This is a bit
> strange, since U-Boot doesn't normally use that node itself. It is better
> to put it under the bootstd node.
> 
> To make this work we need to copy create the node under /chosen when
> fixing up the device tree. Copy over all the properties so that fwupd
> knows what to do.
> 
> Update the sandbox device tree accordingly.
> 
> Signed-off-by: Simon Glass 

Thanks for digging into this!

> I'm not sure whether this is the actual culprit or just an
> operation that happens to expose a problem elsewhere, though.
> I'm inclined to forward the bug report to u-boot upstream unless
> somebody has another idea how to get this narrowed down further.

Reverting just that commit seems doable (one smallish conflict) to test
with greater confidence, though as you say, it could just be revealing
other bugs.

I do not see any debian-specific patches that are likely to be relevent.

If it is annoyingly subtle, it might also be the intersection of
... particular qemu, opensbi and u-boot versions...

Definitely would be good to mention to upstream. Please Cc me if you do!
If you would rather I nudge this upstream, let me know.

live well,
  vagrant

Bug#1028231: unibilium: parse-terminfo test uses wrong terminfo directory

[Sven Joachim]

Control: tags -1 + patch

On 2023-01-08 18:17 +0100, Sven Joachim wrote:

> Source: unibilium
> Version: 2.1.0-1
>
> The parse-terminfo autopkgtest uses a wrong directory for terminfo files
> below /usr:
>
> ,
> | for term in ansi xterm screen rxvt-unicode; do
> |   libterm=/lib/terminfo/${term%${term#?}}/${term}
> |   usrterm=/usr/${libterm}
> `
>
> The (bulk of the) terminfo database is located below /usr/share/terminfo
> rather than /usr/lib/terminfo.  For now this does not matter as we
> install the basic terminfo files in ncurses-base under /lib/terminfo,
> but after the Bookworm release I plan to relocate them to
> /usr/share/terminfo, see https://bugs.debian.org/1028202.  Once that
> happens, your test will still succeed but not do anything, if I read it
> correctly.

That seems to be quite easily fixed with a one-liner.

From 1ee726065fbffa0da996e2ab4663f0d7c82c807e Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 11 Jan 2023 17:26:33 +0100
Subject: [PATCH 1/2] autopkgtest: Look for terminfo files under
 /usr/share/terminfo

The terminfo database in Debian is distributed among the directories
/lib/terminfo (ncurses-base) and /usr/share/terminfo (ncurses-term),
future releases might relocate all terminfo files to
/usr/share/terminfo as per https://bugs.debian.org/1028202.

Closes: #1028231
---
 debian/tests/parse-terminfo | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/parse-terminfo b/debian/tests/parse-terminfo
index 43c4fee..36ae634 100755
--- a/debian/tests/parse-terminfo
+++ b/debian/tests/parse-terminfo
@@ -10,7 +10,7 @@ FAIL=0
 TESTS=0
 for term in ansi xterm screen rxvt-unicode; do
   libterm=/lib/terminfo/${term%${term#?}}/${term}
-  usrterm=/usr/${libterm}
+  usrterm=/usr/share/${term%${term#?}}/${term}
   if [ -e "$libterm" ]; then
 printf "# Parsing $libterm ...\\n"
 TESTS=$((TESTS + 1))
--
2.39.0


> There is also a flawed logic in the parse-terminfo script, it expects
> that any foo-256color terminfo entry is located at the same place as its
> foo counterpart.  For the terminfo entries tested this currently holds
> true, but it is not guaranteed as long as the terminfo files are split
> among multiple directories.

I have attempted to fix that logic with the patch below, and created a
merge request on Salsa:
https://salsa.debian.org/jamessan/unibilium/-/merge_requests/2.

Cheers,
   Sven

From a1e47a6c605ad84c9a983b80ff411d13d9b6b4d1 Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Wed, 11 Jan 2023 17:36:05 +0100
Subject: [PATCH 2/2] autopkgtest: Fix logic to find -256color terminfo entries

The code assumed that a terminfo entry and its -256color pendant
always exits in the same directory, which is not guaranteed.
---
 debian/tests/parse-terminfo | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/debian/tests/parse-terminfo b/debian/tests/parse-terminfo
index 36ae634..042a80e 100755
--- a/debian/tests/parse-terminfo
+++ b/debian/tests/parse-terminfo
@@ -15,20 +15,19 @@ for term in ansi xterm screen rxvt-unicode; do
 printf "# Parsing $libterm ...\\n"
 TESTS=$((TESTS + 1))
 ./tdump "$libterm" || FAIL=1
-if [ -e "${libterm}-256color" ]; then
-  printf "# Parsing ${libterm}-256color ...\\n"
-  TESTS=$((TESTS + 1))
-  ./tdump "${libterm}-256color" || FAIL=1
-fi
   elif [ -e "$usrterm" ]; then
 printf "# Parsing $usrterm ...\\n"
 TESTS=$((TESTS + 1))
 ./tdump "$usrterm" || FAIL=1
-if [ -e "${usrterm}-256color" ]; then
-  printf "# Parsing ${usrterm}-256color ...\\n"
-  TESTS=$((TESTS + 1))
-  ./tdump "${usrterm}-256color" || FAIL=1
-fi
+  fi
+  if [ -e "${libterm}-256color" ]; then
+printf "# Parsing ${libterm}-256color ...\\n"
+TESTS=$((TESTS + 1))
+./tdump "${libterm}-256color" || FAIL=1
+  elif [ -e "${usrterm}-256color" ]; then
+printf "# Parsing ${usrterm}-256color ...\\n"
+TESTS=$((TESTS + 1))
+./tdump "${usrterm}-256color" || FAIL=1
   fi
 done
 printf "1..${TESTS}\\n"
--
2.39.0