Bug#1028996: python-configshell-fb: (autopkgtest) needs update for Python 3.11

[Graham Inggs]

Source: python-configshell-fb
Version: 1:1.1.28-2
Severity: serious
Tag: bookworm sid
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Hi Maintainer

The autopkgtests of python-configshell-fb fail with Python 3.11 as the
default version (and Python 3.10 still supported) [1].  I've copied
what I hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-configshell-fb/testing/amd64/


Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.xyuu059i/downtmp/build.k7y/src/examples/myshell",
line 173, in 
main()
  File "/tmp/autopkgtest-lxc.xyuu059i/downtmp/build.k7y/src/examples/myshell",
line 170, in main
shell.run_interactive()
  File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line
900, in run_interactive
self._cli_loop()
  File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line
729, in _cli_loop
self.run_cmdline(cmdline)
  File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line
843, in run_cmdline
self._execute_command(path, command, pparams, kparams)
  File "/usr/lib/python3/dist-packages/configshell_fb/shell.py", line
818, in _execute_command
result = target.execute_command(command, pparams, kparams)
 ^
  File "/usr/lib/python3/dist-packages/configshell_fb/node.py", line
1405, in execute_command
self.assert_params(method, pparams, kparams)
  File "/usr/lib/python3/dist-packages/configshell_fb/node.py", line
1420, in assert_params
spec = inspect.getargspec(method)
   ^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did
you mean: 'getargs'?

Bug#998284: Please drop the dependency on ttf-bitstream-vera

[fabian]

control: tags -1 +patch
control: forwarded -1 
https://salsa.debian.org/freedesktop-team/fontconfig/-/merge_requests/10

Bug#1028995: mdtraj: (autopkgtest) needs update for Python 3.11

[Graham Inggs]

Source: mdtraj
Version: 1.9.7-4
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Hi Maintainer

The autopkgtests of mdtraj fail with Python 3.11 as the default
version (and Python 3.10 still supported) [1].  I've copied what I
hope is the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/m/mdtraj/testing/amd64/


Fatal Python error: Segmentation fault

Current thread 0x7f9669eda040 (most recent call first):
  File "/usr/lib/python3/dist-packages/mdtraj/core/trajectory.py",
line 2062 in image_molecules
  File 
"/tmp/autopkgtest-lxc.czx2fspl/downtmp/build.1n0/src/tests/test_trajectory.py",
line 732 in test_image_molecules
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 195 in
pytest_pyfunc_call
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1789 in runtest
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 167 in
pytest_runtest_call
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 260 in 
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 339 in from_call
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 259 in
call_runtest_hook
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 220 in
call_and_report
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 131 in
runtestprotocol
  File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 112 in
pytest_runtest_protocol
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 349 in
pytest_runtestloop
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 324 in _main
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 270 in
wrap_session
  File "/usr/lib/python3/dist-packages/_pytest/main.py", line 317 in
pytest_cmdline_main
  File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39 in
_multicall
  File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80 in _hookexec
  File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265 in __call__
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 167 in main
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py",
line 190 in console_main
  File "/usr/bin/pytest-3", line 33 in 

Bug#1028994: mailman3: (autopkgtest) needs update for Python 3.11

[Graham Inggs]

Source: mailman3
Version: 3.3.7-3
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Hi Maintainer

The autopkgtests of mailman3 fail with Python 3.11 as the default
version (and Python 3.10 still supported).  I've copied what I hope is
the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/m/mailman3/testing/amd64/


Traceback (most recent call last):
  File "/usr/bin/runner", line 33, in 
sys.exit(load_entry_point('mailman==3.3.7', 'console_scripts', 'runner')())
 ^
  File "/usr/lib/python3/dist-packages/click/core.py", line 1130, in __call__
return self.main(*args, **kwargs)
   ^^
  File "/usr/lib/python3/dist-packages/click/core.py", line 1055, in main
rv = self.invoke(ctx)
 
  File "/usr/lib/python3/dist-packages/click/core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
   ^^^
  File "/usr/lib/python3/dist-packages/click/core.py", line 760, in invoke
return __callback(*args, **kwargs)
   ^^^
  File "/usr/lib/python3/dist-packages/click/decorators.py", line 26,
in new_func
return f(get_current_context(), *args, **kwargs)
   ^
  File "/usr/lib/python3/dist-packages/mailman/bin/runner.py", line 184, in main
runner = make_runner(*runner_spec, once=once)
 
  File "/usr/lib/python3/dist-packages/mailman/bin/runner.py", line
55, in make_runner
runner_class = find_name(class_path)
   ^
  File "/usr/lib/python3/dist-packages/mailman/utilities/modules.py",
line 52, in find_name
module = import_module(module_path)
 ^^
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/mailman/runners/lmtp.py", line
128, in 
class LMTPHandler:
  File "/usr/lib/python3/dist-packages/mailman/runners/lmtp.py", line
129, in LMTPHandler
@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you
mean: 'coroutines'?
Exception in thread Thread-2 (loop):
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.11/threading.py", line 975, in run
self._target(*self._args, **self._kwargs)
  File 
"/tmp/autopkgtest-lxc.pwnysvr8/downtmp/build.1YK/src/src/mailman/testing/helpers.py",
line 203, in loop
self.start_check()
  File 
"/tmp/autopkgtest-lxc.pwnysvr8/downtmp/build.1YK/src/src/mailman/rest/tests/test_membership.py",
line 675, in _wait_for_both
cls.client = get_lmtp_client(quiet=True)
 ^^^
  File 
"/tmp/autopkgtest-lxc.pwnysvr8/downtmp/build.1YK/src/src/mailman/testing/helpers.py",
line 241, in get_lmtp_client
raise RuntimeError('Connection refused')
RuntimeError: Connection refused

Bug#1028904: pillow: Lost tiff support after binNMU with tiff 4.5.0

[Sebastiaan Couwenberg]

On 1/14/23 19:14, Sebastiaan Couwenberg wrote:

On 1/14/23 18:57, Sebastiaan Couwenberg wrote:

On 1/14/23 18:27, Bas Couwenberg wrote:
python3-pil lost the libtiff dependency after the recent rebuild 
during the transition to tiff 4.5.0:


The attached patch resolves the issue by adding support for the tiff.h 
multiarch path.


The initial patch uses the DEB_HOST_MULTIARCH environment variable.

The attached patch uses sysconfig.get_config_var('MULTIARCH') which 
seems more appropriate for upstreaming:


  https://github.com/python-pillow/Pillow/pull/6896


The underlying issue has been revealed, with tiff 4.5.0 pkg-config 
returns two paths which _pkg_config() in setup.py does not support.


The attached patch resolves that and is what's now been forwarded upstream.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
From 04cf5e2cfc5dc1676efd9f5c8d605ddfccb0f9ee Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Sat, 14 Jan 2023 19:09:43 +0100
Subject: Handle more than one directory returned by pkg-config.

tiff (4.5.0-1) in Debian results in two include directories being returned:
```
-I/usr/include/x86_64-linux-gnu -I/usr/include
```
---
 setup.py | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/setup.py b/setup.py
index 243365681..b4ebbb9c2 100755
--- a/setup.py
+++ b/setup.py
@@ -263,18 +263,20 @@ def _pkg_config(name):
 if not DEBUG:
 command_libs.append("--silence-errors")
 command_cflags.append("--silence-errors")
-libs = (
+libs = re.split(
+r"\s*-L",
 subprocess.check_output(command_libs, stderr=stderr)
 .decode("utf8")
-.strip()
-.replace("-L", "")
+.strip(),
 )
-cflags = (
-subprocess.check_output(command_cflags)
+libs.remove("")
+cflags = re.split(
+r"\s*-I",
+subprocess.check_output(command_cflags, stderr=stderr)
 .decode("utf8")
-.strip()
-.replace("-I", "")
+.strip(),
 )
+cflags.remove("")
 return libs, cflags
 except Exception:
 pass
@@ -473,8 +475,12 @@ class pil_build_ext(build_ext):
 else:
 lib_root = include_root = root
 
-_add_directory(library_dirs, lib_root)
-_add_directory(include_dirs, include_root)
+if lib_root is not None:
+for lib_dir in lib_root:
+_add_directory(library_dirs, lib_dir)
+if include_root is not None:
+for include_dir in include_root:
+_add_directory(include_dirs, include_dir)
 
 # respect CFLAGS/CPPFLAGS/LDFLAGS
 for k in ("CFLAGS", "CPPFLAGS", "LDFLAGS"):
-- 
2.30.2

Bug#1028667: dask BD-Uninstallable

[Diane Trout]

On Sun, 2023-01-15 at 14:42 -0800, Diane Trout wrote:
> On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote:
> > Probably fixed - see my merge request on Salsa.
> > 
> 
> 
> I'd tried to build versions of dask from 2022.03 - 2022.06 and they
> all
> failed with what appeared to be a strong dependency on pyarrow, which
> debian doesn't have.
> 
> Did you get around that for 2022.12?

Apparently 2022.12.1 builds without issue.

I merged your salsa PR, have a couple useful things from my branch and
there's about 2 tests triggering 5 failures in the autopkgtests to see
if I can tell whats wrong with in 2022.12.1

Though before releasing it I would like to try to build the matching
dask.distributed package.

Though I also need to clean up my git history to get the 2022.12.1
changes I made onto salsa. But I'm going to do that tomorrow morning. 

Diane

Bug#1028993: libsbml: (autopkgtest) needs update for Python 3.11

[Graham Inggs]

Source: libsbml
Version: 5.19.7+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Hi Maintainer

The autopkgtests of libsbml fail with Python 3.11 as the default
version (and Python 3.10 still supported).  I've copied what I hope is
the relevant part of the log below.

Regards
Graham


[1] https://ci.debian.net/packages/libs/libsbml/testing/amd64/


autopkgtest [21:36:52]: test autodep8-python3: set -e ; for py in
$(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo
"Testing with $py:" ; $py -c "import libsbml; print(libsbml)" ; done
autopkgtest [21:36:52]: test autodep8-python3: [---
Testing with python3.10:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/libsbml/libsbml.py", line 27, in 
import _libsbml
ModuleNotFoundError: No module named '_libsbml'

Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?

[GCS]

Hi Daniel,

On Mon, Jan 16, 2023 at 6:38 AM Salvatore Bonaccorso  wrote:
> On Sun, Jan 15, 2023 at 04:57:24PM -0500, Daniel Kahn Gillmor wrote:
> > I was looking into CVE-2022-24859 and pypdf2, and trying to figure out
> > whether the version in bullseye is still vulnerable, as it appears to be
> > according to the security tracker:
[...]
> It is still unfixed in bullseye TTBOMK, but would not warrant a DSA.
 Indeed, it's not yet fixed for Bullseye and doesn't warrant a DSA as
the max impact is an infinite loop in the user's own process.

> Can you propose a fix for it with cherry-picking the pull request
> changes for the next bullseye point release?
 Correct, it needs to go via Bullseye point update. I attached the
short change which has the original commit as Salvatore noted.

Sorry for the noise,
Laszlo/GCS
diff -Nru pypdf2-1.26.0/debian/changelog pypdf2-1.26.0/debian/changelog
--- pypdf2-1.26.0/debian/changelog	2020-01-19 09:08:58.0 +0100
+++ pypdf2-1.26.0/debian/changelog	2023-01-16 07:22:11.0 +0100
@@ -1,3 +1,10 @@
+pypdf2 (1.26.0-4+deb11u1) bullseye; urgency=high
+
+  * Backport fix for CVE-2022-24859: manipulated inline images can cause
+infinite loop (closes: #1009879).
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 16 Jan 2023 07:22:11 +0100
+
 pypdf2 (1.26.0-4) unstable; urgency=medium
 
   * Remove Python 2 from build dependencies (closes: #937505).
diff -Nru pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch
--- pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch	1970-01-01 01:00:00.0 +0100
+++ pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch	2023-01-16 00:10:42.0 +0100
@@ -0,0 +1,64 @@
+From d71fb3e6249a07682e8ebc456e26499923ff9031 Mon Sep 17 00:00:00 2001
+From: Sebastian Krause 
+Date: Fri, 15 Apr 2022 13:55:29 +0200
+Subject: [PATCH] SEC/PERF: ContentStream_readInlineImage (#740)
+
+Closes #329 - potential infinite loop (SEC)
+Closes #330 - performance issue of ContentStream._readInlineImage (PERF)
+---
+ PyPDF2/pdf.py | 32 ++--
+ 1 file changed, 22 insertions(+), 10 deletions(-)
+
+diff --git a/PyPDF2/pdf.py b/PyPDF2/pdf.py
+index 5bd4b7968..6d1824384 100644
+--- a/PyPDF2/pdf.py
 b/PyPDF2/pdf.py
+@@ -2723,11 +2723,25 @@ def _readInlineImage(self, stream):
+ # left at beginning of ID
+ tmp = stream.read(3)
+ assert tmp[:2] == b_("ID")
+-data = b_("")
++data = BytesIO()
++# Read the inline image, while checking for EI (End Image) operator.
+ while True:
+-# Read the inline image, while checking for EI (End Image) operator.
+-tok = stream.read(1)
+-if tok == b_("E"):
++# Read 8 kB at a time and check if the chunk contains the E operator.
++buf = stream.read(8192)
++# We have reached the end of the stream, but haven't found the EI operator.
++if not buf:
++raise utils.PdfReadError("Unexpected end of stream")
++loc = buf.find(b_("E"))
++
++if loc == -1:
++data.write(buf)
++else:
++# Write out everything before the E.
++data.write(buf[0:loc])
++
++# Seek back in the stream to read the E next.
++stream.seek(loc - len(buf), 1)
++tok = stream.read(1)
+ # Check for End Image
+ tok2 = stream.read(1)
+ if tok2 == b_("I"):
+@@ -2744,14 +2758,12 @@ def _readInlineImage(self, stream):
+ stream.seek(-1, 1)
+ break
+ else:
+-stream.seek(-1,1)
+-data += info
++stream.seek(-1, 1)
++data.write(info)
+ else:
+ stream.seek(-1, 1)
+-data += tok
+-else:
+-data += tok
+-return {"settings": settings, "data": data}
++data.write(tok)
++return {"settings": settings, "data": data.getvalue()}
+ 
+ def _getData(self):
+ newdata = BytesIO()
diff -Nru pypdf2-1.26.0/debian/patches/series pypdf2-1.26.0/debian/patches/series
--- pypdf2-1.26.0/debian/patches/series	2016-09-05 19:14:14.0 +0200
+++ pypdf2-1.26.0/debian/patches/series	2023-01-16 00:13:06.0 +0100
@@ -1 +1,2 @@
 Prevent_infinite_loop_in_readObject.patch
+CVE-2022-24859.patch

Bug#1028991: junit5: junit-jupiter-api.jar manifest contains invalid classpath

[Emmanuel Bourg]

Good catch, thank you! The fix has been uploaded

Emmanuel Bourg

Bug#1021079: NMU w/o ppc64el?

[Konstantinos Margaritis]

On 15/1/23 03:33, Adam Borowski wrote:

Hi!
As you're apparently too busy to either fix ppc or suggest a different plan,
I'd make a NMU dropping ppc64el for now so the package can be released with
Bookworm.

Please say if I shouldn't.


Hi Adam,

It is true that I am busy during this period, which may explain the lack 
of communication. Now regarding vectorscan w/o ppc64le, I have 2 serious 
bugs I want to fix before a new version upload (5.4.9), one is on Arm (a 
regression compared to x86) and the other is the failure on ppc64le. How 
long do I have to make an upload and ensure bookworm release? If that is 
too soon, then I will make an upload asap myself disabling ppc64le until 
I fix this locally.


Thanks for the interest in the package and apologies for lack of 
communication so far.


Regards

Konstantinos

Bug#827893: pygopherd: At least two zombies at all times

[Paul Wise]

On Wed, 22 Jun 2016 07:44:41 + David Griffith wrote:

> When pygopherd is running, there are always at least two zombie 
> processes associated with it.

pygopherd 3.0.0~git20221126.02c65d60-3 has been reintroduced into Debian 
unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/michael-lazar/pygopherd/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#657355: pygopherd: fails to bind to an IPv6 address

[Paul Wise]

On Wed, 25 Jan 2012 22:35:07 +0100 Damien CLAUZEL wrote:

> I am trying to run a gopher server on IPv6 (don’t ask me why :), but it
> does look like pygopherd cannot bind on an IPv6 address.

pygopherd 3.0.0~git20221126.02c65d60-3 has been reintroduced into Debian 
unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/michael-lazar/pygopherd/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#516679: gophermap h links misinterpreted

[Paul Wise]

On Sun, 22 Feb 2009 16:44:25 -0800 carbonated beverage wrote:

> h links in the gophermap file works correctly at the top-level gophermap,
> but not in a subdirectory.

pygopherd 3.0.0~git20221126.02c65d60-3 has been reintroduced into
Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/michael-lazar/pygopherd/issues

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#771165: [cycle] Year of calendar reverts to current after changing settings

[Paul Wise]

On Thu, 27 Nov 2014 11:39:47 +0200 Vangelis Skarmoutsos wrote:

> If we go few years back in calendar and then change some settings. The
> calendar shows the current year and not the one that we were viewing
> previously.

cycle 0.3.2-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/metlov/cycle/issues
https://sourceforge.net/p/cycle/bugs/
https://sourceforge.net/p/cycle/feature-requests/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#433759: cycle: Specific french caracters as password lead to crash

[Paul Wise]

On Thu, 19 Jul 2007 11:52:18 +0200 Damien BRUCKER wrote:

> When I enter a new female user and associate a password containing
> specific french caracters like éèçàù, the application starts, but cannot be
> exited normally: the cycle window remains on the KDE desktop.
> The only way to exit is to kill the cycle application roughly.

cycle 0.3.2-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/metlov/cycle/issues
https://sourceforge.net/p/cycle/bugs/
https://sourceforge.net/p/cycle/feature-requests/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#422878: cycle: Cycle failed to export to iCal

[Paul Wise]

On Tue, 08 May 2007 17:36:06 +0200 Petr Gajdusek wrote:

> Hi, I cannot export anything to iCal. Exported iCal file is always empty.

cycle 0.3.2-2 has been reintroduced into Debian unstable.

Please try it and see if the issue has been fixed.

If the issue has been fixed, please let us know on this bug.

If the issue has not been fixed, please search the upstream bug
databases to see if the issue is already reported and if it is not
reported, then report a new issue upstream. Please let us know about
any new or existing upstream bugs you file or find.

https://github.com/metlov/cycle/issues
https://sourceforge.net/p/cycle/bugs/
https://sourceforge.net/p/cycle/feature-requests/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?

[Salvatore Bonaccorso]

Hi Daniel,

On Sun, Jan 15, 2023 at 04:57:24PM -0500, Daniel Kahn Gillmor wrote:
> Hi László and debian security team--
> 
> I was looking into CVE-2022-24859 and pypdf2, and trying to figure out
> whether the version in bullseye is still vulnerable, as it appears to be
> according to the security tracker:
> 
>https://security-tracker.debian.org/tracker/CVE-2022-24859
> 
> It's not clear to me whether
> debian/patches/Prevent_infinite_loop_in_readObject.patch is intended to
> fix the same bug or not (it's certainly similar-sounding, but it is in
> an entirely different part of the codebase than i think is relevant).
> If it's not the same, maybe we need the patch that is currently applied
> to debian LTS.
> 
> If the latter is needed, the attached debdiff should solve the problem
> in bullseye.  I've also pushed a branch "debian/pypdf2/bullseye" in
> https://salsa.debian.org/debian/pypdf with the same information, in line
> with the collaborative workspace that László and i set up for handling
> PyPDF2 and its transition to pypdf.
> 
> Please let me know whether this is something that should be uploaded.
> 
> If it's not needed, then presumably we should update the security
> tracker to acknowledge that the version in bullseye is already fixed.

The fix for CVE-2022-24859 can be found via 

https://github.com/py-pdf/PyPDF2/issues/329
https://github.com/py-pdf/PyPDF2/pull/740
https://github.com/py-pdf/pypdf/security/advisories/GHSA-xcjx-m2pj-8g79

It is still unfixed in bullseye TTBOMK, but would not warrant a DSA.
Can you propose a fix for it with cherry-picking the pull request
changes for the next bullseye point release?

Regards,
Salvatore

Bug#1027656: leaflet autoremoval

[Jonas Smedegaard]

[replying via bugreport, to have the conversation public]

Quoting Sebastiaan Couwenberg (2023-01-16 05:54:07)
> Do either of you have time to look into fixing #1026688 which will cause 
> autoremoval of leaflet and its rdeps?

I should be able to take time for that before its removal - but am happy
if others beat me to it.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1028982: metakernel: autopkgtest regression on s390x: AssertionError

[Joe Nahmias]

On Sun, Jan 15, 2023 at 07:37:01PM +0100, Paul Gevers wrote:
> With a recent upload of metakernel the autopkgtest of metakernel fails in
> testing when that autopkgtest is run with the binary packages of metakernel
> from unstable on s390x. It passes when run with only packages from testing.
> In tabular form:
> 
>passfail
> metakernel from testing0.29.4-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
> 
> Currently this regression is blocking the migration to testing [1]. Can you
> please investigate the situation and fix it?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul

Hello Paul,

Thanks for the report. I ran the following to try and reproduce this using
unstable:

ssh zelenka.debian.org
schroot -b -c sid -n $LOGNAME-metakernel
dd-schroot-cmd -c $LOGNAME-metakernel apt-get update
dd-schroot-cmd -c $LOGNAME-metakernel apt-get dist-upgrade
dd-schroot-cmd -c $LOGNAME-metakernel apt-get build-dep metakernel
dd-schroot-cmd -c $LOGNAME-metakernel apt-get install python3-metakernel 
python-metakernel-doc autopkgtest autodep8 pybuild-plugin-autopkgtest
schroot -r -c $LOGNAME-metakernel
/usr/bin/autopkgtest --shell-fail metakernel -- null
exit
schroot -e -c $LOGNAME-metakernel

However, all the tests passed for both python 3.10 & 3.11.

> [0] You can see what packages were added from the second line of the log
> file quoted below. The migration software adds source package from unstable
> to the list if they are needed to install packages from metakernel/0.29.4-1.
> I.e. due to versioned dependencies or breaks/conflicts.
> [1] https://qa.debian.org/excuses.php?package=metakernel
> 
> https://ci.debian.net/data/autopkgtest/testing/s390x/m/metakernel/30188929/log.gz

I tried to look for this list of packages on the second line of the log.gz URL,
but second line I see is:

autopkgtest [16:36:08]: version 5.27

In any case, to the best of my knowledge, there aren't any direct versioned
deps from metakernel.

Moreover, I don't know how to inject metakernel/0.29.4-1 into a bookworm
schroot on zelenka, so I'm a bit stuck here :(

Any ideas on how to proceed?

--Joe

Bug#1027868: broadcom-sta: please switch to B-D: dh-sequence-dkms (or dh-dkms)

[Roger Shimizu]

Dear Andreas,

Thanks for the ticket, and helping to improve this package!

On Wed, Jan 4, 2023 at 2:21 AM Andreas Beckmann  wrote:
>
> Source: broadcom-sta
> Version: 6.30.223.271-23
> Severity: important
>
> Hi,
>
> please switch the Build-Depends of your package from `dkms` to `dh-dkms`
> or (preferrably) `dh-sequence-dkms`.
> With the latter you can also drop the `--with dkms` argument to `dh`.

I guess you prefer dh-sequence-dkms, since currently we're using
dh-dkms already.

> Please consider adding
>   Testsuite: autopkgtest-pkg-dkms
> to the source stanza in debian/control s.t. the module gets build-tested
> against any new kernel version in the archive and breakage is noticed
> quickly.

Thanks for reminding this.
It should be enabled for long.

> If you have questions or need help for disabling the module build on
> unsupported architectures/configurations (that may be exposed when
> enabling the autopkgtest), don't hesitate to contact me.

I did a code search, and found:
https://sources.debian.org/src/bbswitch/0.8-14/debian/tests/autopkgtest-pkg-dkms.conf/

I guess you just meant this, right?
Thanks again!

Cheers,
Roger

Bug#1028964: noweb: Want to use documentclass scrbook instead of book

[Hubert Chathi]

On Sun, 15 Jan 2023 12:47:04 +0100, Mechtilde Stehmann  
said:

> At upstream there is an additional line, so there it is line 16.

> I also filled a patch. You can find a patch under
> https://github.com/nrnrnr/noweb/pull/28/files

Most of the changes look pretty straightforward, but why did you remove
the "\def\nwgitversion{|GITVERSION|}" line?

(Also, I'd recommend that you give your PR a more descriptive name)

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1028992: bullseye-pu: package node-json5/2.1.3-2+deb11u1

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: node-js...@packages.debian.org
Control: affects -1 + src:node-json5

[ Reason ]
node-json5 is vulnerable to prototype pollution (CVE-2022-46175)

[ Impact ]
Medium security issue

[ Tests ]
New tests added, passed

[ Risks ]
Low risk, patch is simle and test passed

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

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index fef8d26..0aa0bd6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-json5 (2.1.3-2+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * add __proto__ to objects and arrays (Closes: CVE-2022-46175)
+
+ -- Yadd   Mon, 16 Jan 2023 07:34:31 +0400
+
 node-json5 (2.1.3-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/CVE-2022-46175.patch 
b/debian/patches/CVE-2022-46175.patch
new file mode 100644
index 000..1b2acc6
--- /dev/null
+++ b/debian/patches/CVE-2022-46175.patch
@@ -0,0 +1,91 @@
+Description: add __proto__ to objects and arrays
+Author: Jordan Tucker 
+Origin: upstream, https://github.com/json5/json5/commit/4a8c4568
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2023-01-16
+
+--- a/CHANGELOG.md
 b/CHANGELOG.md
+@@ -340,5 +340,6 @@
+ [#182]: https://github.com/json5/json5/issues/182
+ [#187]: https://github.com/json5/json5/issues/187
+ [#196]: https://github.com/json5/json5/issues/196
++[#199]: https://github.com/json5/json5/issues/199
+ [#208]: https://github.com/json5/json5/issues/208
+ [#210]: https://github.com/json5/json5/issues/210
+--- a/lib/parse.js
 b/lib/parse.js
+@@ -41,15 +41,35 @@
+ 
+ function internalize (holder, name, reviver) {
+ const value = holder[name]
+-if (value != null && typeof value === 'object') {
+-for (const key in value) {
+-const replacement = internalize(value, key, reviver)
+-if (replacement === undefined) {
+-delete value[key]
+-} else {
+-value[key] = replacement
+-}
++if (Array.isArray(value)) {
++  for (let i = 0; i < value.length; i++) {
++const key = String(i)
++const replacement = internalize(value, key, reviver)
++if (replacement === undefined) {
++  delete value[key]
++} else {
++  Object.defineProperty(value, key, {
++value: replacement,
++writable: true,
++enumerable: true,
++configurable: true,
++  })
++}
++  }
++} else {
++  for (const key in value) {
++const replacement = internalize(value, key, reviver)
++if (replacement === undefined) {
++  delete value[key]
++} else {
++  Object.defineProperty(value, key, {
++value: replacement,
++writable: true,
++enumerable: true,
++configurable: true,
++  })
+ }
++  }
+ }
+ 
+ return reviver.call(holder, name, value)
+@@ -973,7 +993,12 @@
+ if (Array.isArray(parent)) {
+ parent.push(value)
+ } else {
+-parent[key] = value
++Object.defineProperty(parent, key, {
++value,
++writable: true,
++enumerable: true,
++configurable: true,
++})
+ }
+ }
+ 
+--- a/test/parse.js
 b/test/parse.js
+@@ -293,6 +293,12 @@
+ )
+ 
+ t.strictSame(
++  JSON5.parse('{"__proto__":1}').__proto__,
++  1,
++  'preserves __proto__ property names',
++)
++
++t.strictSame(
+ JSON5.parse('{a:{b:2}}', (k, v) => (k === 'b') ? 'revived' : v),
+ {a: {b: 'revived'}},
+ 'modifies nested object property values'
diff --git a/debian/patches/series b/debian/patches/series
index dc10249..f55f44a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 update-unicode.diff
 ship_typescript_definitions.patch
+CVE-2022-46175.patch

Bug#1028991: junit5: junit-jupiter-api.jar manifest contains invalid classpath

[Vladimir Petko]

Source: junit5
Version: 5.9.1-1
Severity: normal

Dear Maintainer,

junit5-5.9.1/debian/junit5.manifest contains a typo: it references
/usr/share/java/junit-commons-platform.jar instead of /usr/share/java/junit-
platform-commons.jar.

This generates compile warnings when /usr/share/java/junit-jupiter-api.jar is
present on the classpath and prevents any applications that use it from working
properly unless junit-platform-commons.jar is explicitly specified.

I have attached a patch for the issue.

Best Regards,
  Vladimir.
diff -Nru junit5-5.9.1/debian/junit5.manifest junit5-5.9.1/debian/junit5.manifest
--- junit5-5.9.1/debian/junit5.manifest	2022-10-10 20:13:36.0 +1300
+++ junit5-5.9.1/debian/junit5.manifest	2023-01-16 16:09:19.0 +1300
@@ -1,5 +1,5 @@
 usr/share/java/junit-jupiter-api.jar:
- Class-Path: /usr/share/java/apiguardian-api.jar /usr/share/java/junit-commons-platform.jar /usr/share/java/opentest4j.jar
+ Class-Path: /usr/share/java/apiguardian-api.jar /usr/share/java/junit-platform-commons.jar /usr/share/java/opentest4j.jar
 
 usr/share/java/junit-jupiter-engine.jar:
  Class-Path: /usr/share/java/apiguardian-api.jar /usr/share/java/junit-jupiter-api.jar /usr/share/java/junit-platform-commons.jar /usr/share/java/junit-platform-engine.jar /usr/share/java/opentest4j.jar

Bug#1028643: fontconfig: 2.14.1-3 greatly changes font rendering

[Konomi]

This is the upstream change in fontconfig that led to this bug report
[1]. I can't find any reason why Noto is now preferred over DejaVu in
the change or issues.

[1] 
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/ad70d785974992c569b30108923875e5b5e9dc5e

Bug#1028990: python-glyphsets: Please package new version 0.5.4

[Boyuan Yang]

Source: python-glyphsets
Version: 0.5.2-2
Severity: normal
X-Debbugs-CC: deb...@microjoe.org

Dear Debian python-glyphsets maintainer,

Please consider packaging the new 0.5.4 release. Also, please look into
Ubuntu's patch on top of existing 0.5.2-2. It is likely applicable onto
current version in Debian.

Thanks,
Boyuan Yang


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

Bug#1028643: fontconfig: 2.14.1-3 greatly changes font rendering

[Konomi]

Just to add as an XFCE user this change greatly impacted the look of
my desktop. So while this may be fine for GNOME users, people with
other DEs could be affected by the change.

I also didn't quite get the file correct to revert the change in my
previous email so here's the updated version, as far as I know this
should work correctly.



monospace

DejaVu Sans Mono



sans

DejaVu Sans



sans-serif

DejaVu Sans



serif

DejaVu Serif

Bug#1028643: fontconfig: 2.14.1-3 greatly changes font rendering

[Konomi]

For anyone who is not super happy with this change from DejaVu to Noto
I just did this to revert it:

1. Create a file called /etc/fonts/conf.d/50-prefer-dejavu.conf
2. Add the following:



monospace

DejaVu Sans Mono



sans

DejaVu Sans Book



serif

DejaVu Serif Book




3. Save the file and run fc-cache -r

I'm not super familiar with how fontconfig works so if anyone who is
could look over this and suggest a better method it would be greatly
appreciated. But this seems to work if you want the old behaviour
back.

Bug#1028849: ddclient: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Richard Hansen]

On 1/14/23 07:54, Lucas Nussbaum wrote:

FAIL: t/geturl_connectivity.pl 10 - IPv* client to https://[::1]:41567
FAIL: t/geturl_connectivity.pl 11 - IPv6 client to https://[::1]:41567
FAIL: t/geturl_connectivity.pl 20 - no (unexpected) warnings (via done_testing)


Looks like a recent fix in IO::Socket::SSL 
() either introduced a new 
IPv6-specific bug (reported at ) 
or, if the IO::Socket::SSL behavior is not a bug, surfaced a latent bug in ddclient.  Either 
way, the workaround/fix is easy: set `SSL_verify_name` to `$peer` in the 
`IO::Socket::SSL->new` arguments.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#911189: libgpgme-firefox-native-messaging

[Ángel]

Sascha Wilde wrote:
>  /etc/chromium/native-messaging-hosts/gpgmejson.json
> 
>Upstream recommends a slightly different file name schema[0]:
>  /etc/chromium/native-messaging-hosts/com.my_company.my_application.json
> 
>As you can see, following this recommendation would mean adding a
>domain.  I'm not sure whether to follow this scheme, and if so, which
>domain to add:  org.debian, org.gnupg or ..?

I think the upstream org.gnupg.gpgme would be more fitting, but since
this is a distro, just the package name would work imho.

> 
> 2. The manifest for chromium is automatically marked configuration
> file,
>as it resides under /etc, which IMO is correct.  A sysadmin might
>want to edit the manifest, e.g. to add the IDs of further
>extensions.
> 
>However: the manifest for firefox is installed as
> 
>  /usr/lib/mozilla/native-messaging-hosts/gpgmejson.json
> 
>(This is dictated by firefox searching for global manifests in that
>place).  So it is not automatically marked as configuration.  And as
>of compatibility level 12 of debhelper it seems to be no longer
>possible to mark the file as configuration manually (dh_installdeb
>simply ignores any debian/package.conffiles.
> 
>Is there a way to work around this?  For the reason given above I
>think the manifest should be marked as a conffile for firefox,
>too...

Install the file in /etc/, e.g. /etc/mozilla/native-messaging-
hosts/gpgmejson.json and make a symlink to that from
 /usr/lib/mozilla/native-messaging-hosts/

I'm not convinced this should be a conffile, though. Couldn't other
externsions be added with a new file?

So you could install webext-mailvelope-gpgme if you wanted mailvelope 
with GnuPG backend, and webext-foobar-gpgme if foobar extension should
be enabled access to gpgme

Bug#911189: gpgme-json packaging

[Ángel]

I have tested https://salsa.debian.org/debian/gpgme/-/merge_requests/1
and it works fine.
I would however name the new package gpgme-json, not libgpgme-bin

The package is only providing gpgme-json(1). If it is going to ship
more binaries in the future, it can always be replaced. If someone is
told they need gpgme-json the expected package name is 'gpgme-json',
not libgpgme-bin. Plus, that lib prefix is even more confusing.

Even the description (“This package contains the gpgme-json binary to
access GPGME...”) seem to ask for that name.

That is the only nitpick I have. It "just works". :-)

The debian/changelog would need updating, and rebased on top of gpgme
1.18 (bookworm/sid) from the current 1.14.

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

[Axel Beckert]

Control: tag -1 + pending

Hi Christoph,

Christoph Biedl wrote:
> 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;

Thanks!

And it seems that --raw option does not only exist since recently, so
we can take that patch without having fear that backports will break.
:-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028912: Please build with C++20 to enable multi-symbol detection support for DataMatrix

[Boyuan Yang]

Control: confirmed -1

在 2023-01-14星期六的 21:53 +0100，Jakob Haufe写道：
> Source: zxing-cpp
> Version: 1.4.0-3
> Severity: wishlist
> Tags: patch
> 
> In d6dc409ef15ff7171c7f9130dff7266a7c65f053[1], upstream implemented
> detection for multiple DataMatrix symbols in a single input. As
> mentioned in the commit message, this needs C++20.
> 
> Patch attached.
> 
> [1]
> https://github.com/zxing-cpp/zxing-cpp/commit/d6dc409ef15ff7171c7f9130dff7266a7c65f053

Looks okay. I am not sure about whether it will bring ABI breakage; given
the current transition freeze, I plan to enable it with zxing-cpp 2.0 upload
after Debian 12 release.

Thanks,
Boyuan Yang


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

Bug#709584: Closing this bug (BTS maintenance for debian-printing)

[Paul Wise]

Control: reopen -1
Control: found -1 1.28.16-1

On Sun, 2023-01-15 at 18:48 +, Thorsten Alteholz wrote:

> this bug was marked as "fixed-upstream" long time ago, so it was probably 
> fixed in a later upload. Thus I am manually closing this bug now.

It is easy to verify this is unfixed, cups-filters still embeds aglfn:

   $ chronic apt source cups-filters
   $ find cups-filters*/ -iname *aglfn*
   cups-filters-1.28.16/fontembed/aglfn13.c

Looking at the upstream bug they just closed the bug (because the data
is currently unused) without removing the embed or updating it.

https://bugs.linuxfoundation.org/show_bug.cgi?id=1135

The preferred solution would be to have libfontembed load the aglfn
file at runtime. Alternatively the aglfn text file (from the aglfn
package or downloaded from GitHub) could be converted into C code
and compiled into the libfontembed library.

https://github.com/adobe-type-tools/agl-aglfn

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1028275: perl: Return value of system()

[David Christensen]

Debian Bug 1028275:

Here is an updated version of the Perl system() test script per the San 
Francisco Perl Mongers Raku Study Group meeting of January 15, 2023.



HTH,

David



2023-01-15 16:21:20 dpchrist@laalaa ~/sandbox/perl
$ cat system.t
#!/usr/bin/env perl
# $Id: system.t,v 1.7 2023/01/16 00:20:21 dpchrist Exp $
# by David Paul Christensen dpchr...@holgerdanske.com
# Public Domain
#
# Test Perl built-in system().
#
# See 'perldoc -f system'.


use strict;
use warnings;
use Capture::Tiny   qw( capture );
use POSIX   qw( SIGUSR2 );
use Test::More;
use Test::Warn;

our @args;

our $stdout;
our $stderr;
our $system;
our $ce;

our $TODO;



### Invoke test_engine() (see below) over list of test sets:

test_engine(@$_) for (

  ### First set of tests -- child failed to execute
  [
"Child failed to execute",
[qw( nosuchprogram foo bar )],
q(nosuchprogram foo bar),
sub {
  eval {
is $stdout, '', join $", __FILE__, __LINE__,
  'STDOUT is empty string';

like
  $stderr,
  qr/^Can't exec "nosuchprogram": No such file or directory/,
  join $", __FILE__, __LINE__,
   q(STDERR like /Can't exec "nosuchprogram": No such file or 
directory/);

is $system, $ce, join $", __FILE__, __LINE__,
  sprintf 'System return value (0x%X) is $CHILD_ERROR (0x%X)',
  $system,
  $ce;

is $ce, -1, join $", __FILE__, __LINE__,
  sprintf '$CHILD_ERROR (0x%X) is -1',
  $ce;

is $ce & 127, 0x7F, join $", __FILE__, __LINE__,
  sprintf 'Lower 7 bits of $CHILD_ERROR (0x%X) are ones',
$ce & 127;

is $ce >> 8, (~0) >> 8, join $", __FILE__, __LINE__,
  sprintf 'Upper bytes of $CHILD_ERROR (0x%X) are ones',
$ce >> 8;
  };
},
  ],

  ### Second set of tests -- signals
  [
"Child kills itself with signal USR2",
['perl', '-e', 'kill "USR2", $$'],
q(perl -e 'kill "USR2", $$'),
sub {
  eval {
is $system, $ce, join $", __FILE__, __LINE__,

sprintf 'System return value (0x%X) is $CHILD_ERROR (0x%X)',
  $system,
  $ce;

isnt $ce, -1, join $", __FILE__, __LINE__,
  sprintf '$CHILD_ERROR (0x%X) isnt -1',
$ce;
  };
},
sub {
  my $code = q{
is $ce & 127, SIGUSR2, join $", __FILE__, __LINE__,
  sprintf 'Lower 7 bits of $CHILD_ERROR (0x%X) is SIGUSR2 (0x%X)',
$ce & 127,
SIGUSR2;

is $ce >> 8, 0, join $", __FILE__, __LINE__,
  sprintf 'Upper bytes of $CHILD_ERROR (0x%X) are zeroes',
$ce >> 8;
  };
  if (@args == 1 && -e '/etc/debian_version') {
TODO: {
	  local $TODO = 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028275;;

  eval $code;
}
  }
  else {
eval $code;
  }
},
  ],

  ### Third set of tests -- exit value
  [
"Child exits with value 0xA5",
['perl', '-e', 'exit 0xA5'],
q(perl -e 'exit 0xA5'),
sub {
  eval {
is $system, $ce, join $", __FILE__, __LINE__,
  sprintf 'System return value (0x%X) is $CHILD_ERROR (0x%X)',
$system,
$ce;

isnt $ce, -1, join $", __FILE__, __LINE__,
  sprintf '$CHILD_ERROR (0x%X) isnt -1',
$ce;

is $ce & 127, 0, join $", __FILE__, __LINE__,
  sprintf 'Lower 7 bits of $CHILD_ERROR (0x%X) are zeroes',
$ce & 127;

is $ce >> 8, 0xA5, join $", __FILE__, __LINE__,
  sprintf 'Upper bytes of $CHILD_ERROR (0x%X) is 0xA5',
$ce >> 8;
  };
},
  ],
);

### test_engine()
#
#   test_engine DESCRIPTION,RA_LIST,ARG,RC_TEST...
#
#   DESCRIPTION is an explanatory note for the set of tests
#
#   RA_LIST is a reference to an array containing an argument list to be 
passed to Perl system()

#
#   ARG is the single-argument (string) form of the argument list
#
#   RC_TEST... is one or more references to code containing Test::More tests

sub test_engine
{
  note(shift @_);

  local @args = @{ shift(@_) };
  my $a = shift(@_);

  note("\@args='", join("', '", @args), "'");
  ($stdout, $stderr, $system) = capture { system(@args) };
  $ce = $?;
  $_->() for @_;

  local @args = ($a);
  note "\@args='", join("', '", @args), "'";
  ($stdout, $stderr, $system) = capture { system(@args) };
  $ce = $?;
  $_->() for @_;
}

done_testing;

Bug#1002053: lintian: false positive inconsistent-appstream-metadata-license (gpl-2.0+ != gpl-2+)

[Axel Beckert]

Control: tag -1 + confirmed pending

Hi Nicholas and Soren,

Nicholas D Steeves wrote:
> Gpl-2+ (used in d/copyright) is equivalent to gpl-2.0+ used in
> appstream metadata, so this is a false positive.

Correct, as
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
(part of the Debian Policy) also states:

»For SPDX compatibility, versions with trailing dot-zeroes are
considered to be equivalent to versions without (e.g., “2.0.0” is
considered equal to “2.0” and “2”).«

> Were GNU to hypothetically release a GPL 2.1, and were upstream to
> switch to it, the onus would be on the Debian maintainer to update
> d/copyright.

Yes, but they'd need to update it in both cases as neither "GPL-2+"
nor "GPL-2.0+" imply "newest version of the GPL 2.x series". :-)

> It also seems wrong to emit this at the warning level for this
> specific case.

Unfortunately the level is hardcoded in the tag. We can't emit a tag
e.g. once at warning and once at pedantic level depending on the found
data. (It also IMHO makes not so much sense semantic-wise.)

> If lintian is encouraging maintainers to use the "gpl-2.0+" notation
> rather than gpl-2+ in d/copyright, then it should emit a different
> (lower severity than warning) tag for that case.

Well, as the Debian Copyright Format Specification 1.0 explicitly
allows both variants, this seems not necessary.

> It seems clear to me that (gpl-2.0+ = gpl-2+), so it looks like the
> correct approach is to use a table of equivalent license notations to
> prevent the false positive.

Yeah, as that list would potentially became rather huge and hard to
maintain, I'd rather use a regexp to filter out such things.

Soren Stoutner wrote:
> The same basic problem also occurs with MIT and Expat licenses.

Ack.

> The specification for the AppStream metadata file only has a few
> options, one of them being MIT and none of them being Expat.

Same for SPDX: Neither https://spdx.org/licenses/ nor
https://spdx.org/licenses/MIT.html mention Expat.

> Debian, of course, prefers the Expat name as it is more precise.

According to
https://wiki.debian.org/Proposals/CopyrightFormat#Differences_between_DEP5_and_SPDX
SPDX does not have the Expat license. They do have though the "MIT
License" (the one and only ;-), so that would imply that they're not
the same license.

And indeed, there are two difference between
https://spdx.org/licenses/MIT.html and
http://www.jclark.com/xml/copying.txt (the Expat license):

* The MIT License starts with a headline "MIT License" (which is
  probably less relevant).

* The MIT License contains the following part in its second paragraph
  which the Expat license doesn't have: "(including the next
  paragraph)". This might make a subtle difference, but IANAL.

> inconsistent-appstream-metadata-license debian/metainfo.xml (mit !=
> expat) [debian/copyright]

So that actually seems a true positive as the licenses differ. They
only differ a bit, but they differ.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028592: Acknowledgement (tagcoll2 2.0.14-2 fails to build on sid)

[Holger Levsen]

control retitle -1 tagcoll2 2.0.14-2 fails to build on sid and bookworm
# as shown on 
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/tagcoll2.html
thanks


-- 
cheers,
Holger

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

First they came for the journalists, we don't know what happened after that.


signature.asc
Description: PGP signature

Bug#1026915: grub-install --removable uses CD boot image instead of normal disk boot image

[Steve McIntyre]

On Fri, Dec 23, 2022 at 10:03:18PM +0100, Pascal Hambourg wrote:
>Package: grub-efi-amd64-bin
>Version: 2.06-3~deb11u5
>Tags: patch
>
>When installing GRUB for UEFI secure boot, "grub-install --removable" uses
>the CD boot image gcd{arch}.efi.signed which is designed for CD boot and
>lacks encryption, LVM and RAID support. Such image cannot read /boot on LUKS,
>LVM or Linux RAID.

Right, you're totally correct. IMHO there's no good reason for us to
use the smaller image here with stuff missing. Let's fix that!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#1028978: libomxil-bellagio FTBFS on mipsel: error: ‘__builtin_strncpy’ destination unchanged after copying no bytes [-Werror=stringop-truncation]

[Ying-Chun Liu (PaulLiu)]

Thanks. I'm not sure what happened either. But this patch fixes the bug 
(attached). I'll upload it soon.




On 2023/1/15 19:59, Helmut Grohne wrote:

Source: libomxil-bellagio
Version: 0.9.3-7
Severity: serious
Tags: ftbfs

Hi,

libomxil-bellagio fails to build form source when built on mipsel. A
build ends as follows:

| gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
-DOMXILCOMPONENTSPATH=\"/usr/lib/mipsel-linux-gnu/libomxil-bellagio0/\" 
-I../include -g -O2 -ffile-prefix-map=/root/libomxil-bellagio-0.9.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror 
-DCONFIG_DEBUG_LEVEL=0 -c -o omxregister_bellagio-omxregister.o `test -f 'omxregister.c' 
|| echo './'`omxregister.c
| In file included from /usr/include/string.h:535,
|  from omxregister.c:42:
| In function ‘strncpy’,
| inlined from ‘showComponentsList’ at omxregister.c:110:3,
| inlined from ‘main’ at omxregister.c:454:9:
| /usr/include/mipsel-linux-gnu/bits/string_fortified.h:95:10: error: 
‘__builtin_strncpy’ destination unchanged after copying no bytes 
[-Werror=stringop-truncation]
|95 |   return __builtin___strncpy_chk (__dest, __src, __len,
|   |  ^~
|96 |   __glibc_objsize (__dest));
|   |   ~
| cc1: all warnings being treated as errors
| make[4]: *** [Makefile:719: omxregister_bellagio-omxregister.o] Error 1
| make[4]: Leaving directory '/root/libomxil-bellagio-0.9.3/src'
| make[3]: *** [Makefile:776: all-recursive] Error 1
| make[3]: Leaving directory '/root/libomxil-bellagio-0.9.3/src'
| make[2]: *** [Makefile:495: all-recursive] Error 1
| make[2]: Leaving directory '/root/libomxil-bellagio-0.9.3'
| make[1]: *** [Makefile:381: all] Error 2
| make[1]: Leaving directory '/root/libomxil-bellagio-0.9.3'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:9: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

If you look at https://crossqa.debian.net/src/libomxil-bellagio, you can
guess that this is not entirely mipsel-specific, but probably also a
FTBFS on ppc64el and s390x. That said, I have only reproduced it on
mipsel and thus am filing it on mipsel.

A native build on amd64 succeeds.

I also briefly looked into it and couldn' really make sense of why gcc
thinks that the len parameter would become 0 here. Maybe someone else
figures?

Helmut
From: Ying-Chun Liu (PaulLiu) 
Subject: fix FTBFS on mipsel
 We got /usr/include/mipsel-linux-gnu/bits/string_fortified.h:95:10:
 error: ‘__builtin_strncpy’ destination unchanged after copying no bes
 [-Werror=stringop-truncation]
 Thus we check the size before call strncpy.
Bug-Debian: http://bugs.debian.org/1028978
Index: libomxil-bellagio-0.9.3/src/omxregister.c
===
--- libomxil-bellagio-0.9.3.orig/src/omxregister.c
+++ libomxil-bellagio-0.9.3/src/omxregister.c
@@ -107,7 +107,9 @@ static int showComponentsList(FILE* omxr
 		while ((temp_buffer[i] != '\0') && (temp_buffer[i] != ' ')) {
 			i++;
 		}
-		strncpy(comp_name, temp_buffer, i);
+		if (i > 0) {
+			strncpy(comp_name, temp_buffer, i);
+		}
 		comp_name[i] = '\0';
 		temp_buffer += i;
 		if (*temp_buffer != '\0') {


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021812: powerline: Missing vim bindings

[Samuel Henrique]

Hello Rob,

I think the decision not to ship vim bindings happened before I was
the maintainer of the package, but your suspicion is correct regarding
Debian's vim not being built with python support. I don't think the
bindings would work.

What I use on my machines is vim-airline, which you can install using
apt or pretty much any vim plugin manager.

https://tracker.debian.org/pkg/vim-airline
https://github.com/vim-airline/vim-airline

I don't think it can be enabled by default since vim-airline doesn't
enable itself automatically. We could add vim-airline to powerline's
Suggests, and mention somewhere that the bindings for vim are in that
package (not sure where yet), but it's worth noting that they are two
separate projects with their own codebase each (although they look
pretty much the same).

Thank you for reporting this,

-- 
Samuel Henrique 

Bug#1028989: RFS: proftpd-mod-sftp-ldap/0.2-1 [ITP] -- ProFTPD module mod_sftp-ldap

[Hilmar Preuße]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "proftpd-mod-sftp-ldap":

 * Package name : proftpd-mod-sftp-ldap
   Version  : 0.2-1
   Upstream contact : TJ Saunders
 * URL  :
http://www.castaglia.org/proftpd/modules/mod_sftp-ldap.html
 * License  : GPL-2+
 * Vcs  :
https://salsa.debian.org/debian-proftpd-team/proftpd-mod-sftp-ldap
   Section  : net

The source builds the following binary packages:

  proftpd-mod-sftp-ldap - ProFTPD module mod_sftp-ldap

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

  https://mentors.debian.net/package/proftpd-mod-sftp-ldap/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/proftpd-mod-sftp-ldap/proftpd-mod-sftp-ldap_0.2-1.dsc

Changes for the initial release:

 proftpd-mod-sftp-ldap (0.2-1) unstable; urgency=medium
 .
   * Initial upload (Closes: #1028630).
 .
   [ Paweł Tomulik  ]
   * Providing an initial package I could use as starter.

Regards,
--
  Hilmar Preusse

Bug#1028988: DDPO: Show open security issues (CVEs)

[Samuel Henrique]

Package: qa.debian.org
X-Debbugs-Cc: fds, samuel...@debian.org
Severity: wishlist

The DDPO page could show open security vulnerabilities tracked on
security-tracker.debian.org, just like we see it in tracker.d.o.

Example for curl:
https://security-tracker.debian.org/tracker/source-package/curl

It would be really nice if there was a column for open security issues
under DDPO. I'm sure this would result in maintainers being more
proactive in fixing security issues on stable, as it's too easy to
miss them right now.

Thank you,

-- 
Samuel Henrique 

Bug#1025446: php8.2: Please link against libatomic for "riscv64" arch

[Ondřej Surý]

This makes absolutely no sense. C11 does not specify that some random library is needed for a language feature.I would rather suggest to patch gcc to add --as-needed -latomic --no-as-neededby default, than bugging random programs using C11 (that’s 11 years ago) to link with -latomic, see:81358 – libatomic not automatically linked with C11 codegcc.gnu.orgThat would help seamlessly bootstrap the platform right now.Ondrej--Ondřej Surý  (He/Him)On 15. 1. 2023, at 23:39, Manuel A. Fernandez Montecelo  wrote:Hi,On Sun, 4 Dec 2022 at 21:15, Manuel A. Fernandez Montecelo wrote:Source: php8.2Severity: wishlistTags: ftbfs patchUser: debian-ri...@lists.debian.orgUsertags: riscv64X-Debbugs-Cc: m...@debian.org, locutusofb...@debian.org, bba...@debian.orgHi,The package still in experimental builds with the changes attached, I built thepackage locally on this architecture, so please include it (or add an equivalentsolution) in the next uploads, at least before moving to unstable.Gentle ping?There are several packages (PHP modules or similar) waiting withDep-Wait on a newer version of php8.2, so it would be nice to havethis patch applied to have php8.2 building successfully and soavoiding these problems altogether.Cheers.-- Manuel A. Fernandez Montecelo 

Bug#1016737: Loop in POST when using --removable option in grub-install

[Steve McIntyre]

Hey folks,

On Sat, Aug 06, 2022 at 10:30:10PM +0900, Sugu wrote:
>Package: grub-efi-amd64
>Version: 2.04-20
>Severity: normal
>X-Debbugs-Cc: none
>
>Dear Maintainer,
>
>*** Reporter, please consider answering these questions, where appropriate
>***
>
>I run grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable
>and reboot, it repeats POST forever and loops.
>This bug does not occur on Arch Linux, so it appears to be Debian-specific.
>
>*** End of the template - remove these template lines ***

...

On Sat, Dec 24, 2022 at 01:53:48PM +0100, Pascal Hambourg wrote:
>Hello,
>
>I observe the same behaviour on my laptop.
>My workaround is to remove EFI/BOOT/fbx64.efi from the EFI partition.
>IMO --removable should not install this file.

On Mon, Dec 26, 2022 at 03:28:10PM +0100, Pascal Hambourg wrote:
>I wrote:
>> 
>> I observe the same behaviour on my laptop.
>
>And on another x86 desktop PC too. When loaded from the removable media path
>(/EFI/BOOT/BOOTX64.EFI), shim loads fbx64.efi which reboots the system if it
>did not find any BOOTX64.CSV file in /EFI/BOOT, as expected on removable
>media.
>
>Here is the console output after setting FALLBACK_VERBOSE with
>
> mokutil --set-fallback-verbosity true
>
>efi_main: System BootOrder not found.  Initializing defaults.
>efi_main: tpm not present, starting the first image
>Verbose enabled, sleeping for 50 mseconds... Press the Pause key now to
>hold for longer.
>Reset System
>Verbose enabled, sleeping for 50 mseconds... Press the Pause key now to
>hold for longer.
>
>> My workaround is to remove EFI/BOOT/fbx64.efi from the EFI partition.
>> IMO --removable should not install this file.
>
>This is confirmed in the shim source package.
>
>- In README.fallback:
>When you boot removable media, it'll be in \EFI\BOOT , but fallback.efi
>won't be there, so it goes ahead and boots the normal bootloader
>(grubx64.efi).
>
>- In shim.c:
>   /* Do not print the error here - this is an acceptable case
>* for removable media, where we genuinely don't want
>* fallback.efi to exist.
>
>Also fbx64.efi is not present in the EFI partition of Debian installation
>images.

OK, I can see what's happening here. The logic in grub-install is
*very* convoluted here, with lots of different patches applied. It's
quite difficult to follow. :-(

Yes, you're correct - fallback should *not* be installed here if
you're specifying --removable. In fact, on a Debian system we should
probably not be installing fallback unless we're doing the
--force-removable thing.

Testing stuff now...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Bug#1028630: RFP: proftpd-mod-sftp-ldap -- module for ProFTPD supports retrieving/using user SSH public keys from LDAP

[Hilmar Preuße]

Control: retitle -1 ITP: proftpd-mod-sftp-ldap
Control: reassign -1 wnpp

Am 13.01.2023 um 22:54 teilte Paweł Tomulik mit:

Hi,


ProFTPD mod_sftp_ldap may be very useful for ProFTPD installations with
virtual users stored in LDAP database together with SSH keys. It enables
the authentication based on these keys stored in LDAP.

The upstream project is here:
https://github.com/Castaglia/proftpd-mod_sftp_ldap

I've initially packaged it for Debian, and put here:
https://gitlab.com/ptomulik/proftpd-mod_sftp_ldap



Meanwhile I created an repo on salsa, which will be official repository.

Hilmar

--
sigfault

Bug#1028667: dask BD-Uninstallable

[Diane Trout]

On Sun, 2023-01-15 at 18:16 +, Rebecca N. Palmer wrote:
> Probably fixed - see my merge request on Salsa.
> 


I'd tried to build versions of dask from 2022.03 - 2022.06 and they all
failed with what appeared to be a strong dependency on pyarrow, which
debian doesn't have.

Did you get around that for 2022.12?

For what it's worth I had almost managed to back port enough of the
pandas 1.5 compatibility stuff to 2022.02 to get it working correctly.

To deal with the different repositories I pushed what I'd done to

https://salsa.debian.org/diane/dask

There's two errors left.

One's a deprecation warning from SQLAlchemy that can probably be
ignored  as it's about SQLAlchemy 2.0 and there's one test failure in:

FAILED
dataframe/tests/test_arithmetics_reduction.py::test_reductions_frame_dt
ypes_numeric_only - AssertionError: Series are different

when I get a chance I'll try building your 2022.12 branches, but I have
to go deal with family obligations now.

Diane

Bug#1025446: php8.2: Please link against libatomic for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Hi,

On Sun, 4 Dec 2022 at 21:15, Manuel A. Fernandez Montecelo
 wrote:
>
> Source: php8.2
> Severity: wishlist
> Tags: ftbfs patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: m...@debian.org, locutusofb...@debian.org, bba...@debian.org
>
> Hi,
>
> The package still in experimental builds with the changes attached, I built 
> the
> package locally on this architecture, so please include it (or add an 
> equivalent
> solution) in the next uploads, at least before moving to unstable.

Gentle ping?

There are several packages (PHP modules or similar) waiting with
Dep-Wait on a newer version of php8.2, so it would be nice to have
this patch applied to have php8.2 building successfully and so
avoiding these problems altogether.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#1025343: z3: Please link against -latomic for "riscv64" arch

[Manuel A. Fernandez Montecelo]

On Fri, 2 Dec 2022 at 22:45, Manuel A. Fernandez Montecelo
 wrote:
>
> Source: z3
> Version: 4.8.12-3
> Severity: wishlist
> Tags: ftbfs patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
>
> Hi,
>
> The package needs to link against libatomic in this architecture, with the 
> patch
> attached or an equivalent.
>
> I built it successfully on local hardware.

Gentle ping?

It would be nice to have this patch applied so the package would build
successfully in the case of binNMUs, or new revisions of the package
that would fix other problems (e.g. future NMUs), etc.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

[Axel Beckert]

Control: tag -1 + pending

Hi,

TL;DR:

The in-sbin-confusion-in-elf test in Lintian's test suite is broken
beyond repair: Lintian's arm64 result (which failed the test) is
actually the correct result, and the amd64 result (which passed the
test) is wrong due false negatives which lintian has no chance to
find. The cause are very likely different per-architecture compile
time string optimizations. So I will remove the test
in-sbin-confusion-in-elf from the test suite. The tag
bin-sbin-mismatch can't be tested on C-compiled binaries properly if
compile-time string optimizations are in use.

Long story including steps to get to that conclusion:

I've now digged into the second of these test suite failures on arm64
as I could neither reproduce it on armhf nor i386 (which were easier
available to me as I have Sid boxes with these architectures
permanently running).

And on arm64 I can indeed reproduce it. And it is much more weird than
I expected:

Paul Gevers wrote:
> # Hints do not match
> #
> # --- 
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.specified.calibrated
> # +++ 
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/hints.actual.parsed
> # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script ->
> usr/bin/our-script [usr/bin/calls-sbin]
> # +bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script ->
> usr/bin/our-script [usr/bin/calls-sbin]
> #
> #   Failed test 'Lintian passes for bin-sbin-confusion-in-elf'
> #   at /usr/share/lintian/lib/Test/Lintian/Run.pm line 343.
> # Looks like you failed 1 test of 1.
> ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/contents/bin-sbin-confusion-in-elf/generic.t
> 

> Still need to figure out where the issue with bin-sbin-mismatch. But
> that tag is known (at least to me) for weird false positives.

The tag's implementation is not the cause. This seems not a direct bug
in Lintian.

So Lintian's test suite has a sample C program calls-sbin.c which the
test suite expects to trigger once. Here's the source code:

---8<---
#include 
#include 

/* may not work as expected on ELF due to ld's SHF_MERGE */
#define BIN_PATH "/bin/our-script"
#define SBIN_PATH "/sbin/our-script"
#define USR_BIN_PATH "/usr/bin/our-script"
#define USR_SBIN_PATH "/usr/sbin/our-script"

int
main(void)
{
printf("Calling %s\n", BIN_PATH);
printf("Calling %s\n", SBIN_PATH);
printf("Calling %s\n", USR_BIN_PATH);
printf("Calling %s\n", USR_SBIN_PATH);

return 0;
}
--->8---

Both files, our-script and calls-sbin are only installed into
/usr/bin/.

So how often should this tag trigger then? Once? Twice? Thrice?

The test suite thinks only once which I find confusing. I'd expected
at least twice. But the expected emitted tags by the test suite are:

  bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch usr/sbin/our-script -> 
usr/bin/our-script [usr/bin/calls-sbin]

On arm64 these three tags are emitted:

  bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch usr/sbin/our-script -> 
usr/bin/our-script [usr/bin/calls-sbin]
  bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch sbin/our-script -> 
usr/bin/our-script [usr/bin/calls-sbin]
  bin-sbin-confusion-in-elf (binary): bin-sbin-mismatch bin/our-script -> 
usr/bin/our-script [usr/bin/calls-sbin]

Which is more what I would have expected on amd64 as well.

So far for the basic confusion.

Now to the more weird thing.

Not weird is IMHO that these four paths from the source are all in the
arm64 binary of calls-sbin:

[arm64] $ strings 
./debian/test-out/packages/checks/files/contents/bin-sbin-confusion-in-elf/bin-sbin-confusion-in-elf-1.0/debian/bin-sbin-confusion-in-elf/usr/bin/calls-sbin
 | fgrep bin
/bin/our-script
/sbin/our-script
/usr/bin/our-script
/usr/sbin/our-script

But in the amd64 binary, there are only two of them, with one being
the correct one:

[amd64] $ strings 
./debian/test-out/packages/checks/files/contents/bin-sbin-confusion-in-elf/bin-sbin-confusion-in-elf-1.0/debian/bin-sbin-confusion-in-elf/usr/bin/calls-sbin
 | fgrep bin
/usr/bin/our-script
/usr/sbin/our-script

This fits with the test suite only expecting this tag to be emitted.

But then again, the output of both architectures is the same:

[arm64] $ 
./debian/test-out/packages/checks/files/contents/bin-sbin-confusion-in-elf/bin-sbin-confusion-in-elf-1.0/debian/bin-sbin-confusion-in-elf/usr/bin/calls-sbin
Calling /bin/our-script
Calling /sbin/our-script
Calling /usr/bin/our-script
Calling /usr/sbin/our-script

[amd64] $ 
./debian/test-out/packages/checks/files/contents/bin-sbin-confusion-in-elf/bin-sbin-confusion-in-elf-1.0/debian/bin-sbin-confusion-in-elf/usr/bin/calls-sbin
Calling /bin/our-script
Calling /sbin/our-script
Calling /usr/bin/our-script
Calling /usr/sbin/our-script

So the more weird thing is: I 

Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?

[Daniel Kahn Gillmor]

Hi László and debian security team--

I was looking into CVE-2022-24859 and pypdf2, and trying to figure out
whether the version in bullseye is still vulnerable, as it appears to be
according to the security tracker:

   https://security-tracker.debian.org/tracker/CVE-2022-24859

It's not clear to me whether
debian/patches/Prevent_infinite_loop_in_readObject.patch is intended to
fix the same bug or not (it's certainly similar-sounding, but it is in
an entirely different part of the codebase than i think is relevant).
If it's not the same, maybe we need the patch that is currently applied
to debian LTS.

If the latter is needed, the attached debdiff should solve the problem
in bullseye.  I've also pushed a branch "debian/pypdf2/bullseye" in
https://salsa.debian.org/debian/pypdf with the same information, in line
with the collaborative workspace that László and i set up for handling
PyPDF2 and its transition to pypdf.

Please let me know whether this is something that should be uploaded.

If it's not needed, then presumably we should update the security
tracker to acknowledge that the version in bullseye is already fixed.

--dkg


signature.asc
Description: PGP signature

Bug#1028275: perl: Return value of system()

[David Christensen]

Debian bug 1028275:

I have expanded my test script to test Perl's built-in system() with a 
single argument and with a list of arguments.


HTH,

David



2023-01-15 13:07:34 dpchrist@laalaa ~/sandbox/perl
$ cat system.t
#!/usr/bin/env perl
# $Id: system.t,v 1.5 2023/01/15 21:07:33 dpchrist Exp $
# by David Paul Christensen dpchr...@holgerdanske.com
# Public Domain
#
# Test Perl built-in system().

use strict;
use warnings;
use Capture::Tiny   qw( capture );
use POSIX   qw( SIGUSR2 );
use Test::More;
use Test::Warn;

our @args;

our $stdout;
our $stderr;
our $system;
our $ce;

our $TODO;

sub _t
{
  note shift;

  local @args = @{ shift @_ };
  my $a = shift;

  note "\@args='", join("', '", @args), "'";
  ($stdout, $stderr, $system) = capture { system(@args) };
  $ce = $?;
  $_->() for @_;

  local @args = ($a);
  note "\@args='", join("', '", @args), "'";
  ($stdout, $stderr, $system) = capture { system(@args) };
  $ce = $?;
  $_->() for @_;
}

_t(@$_) for (
  [
"Child failed to execute",
[qw( nosuchprogram foo bar )],
q(nosuchprogram foo bar),
sub {
  eval {
is $stdout, '', join $", __FILE__, __LINE__,
  'STDOUT is empty string';

like
  $stderr,
  qr/^Can't exec "nosuchprogram": No such file or directory/,
  join $", __FILE__, __LINE__,
   q(STDERR like /Can't exec "nosuchprogram": No such file or 
directory/);

is $system, $ce, join $", __FILE__, __LINE__,
  sprintf 'System return value (0x%X) is $CHILD_ERROR (0x%X)',
  $system,
  $ce;

is $ce, -1, join $", __FILE__, __LINE__,
  sprintf '$CHILD_ERROR (0x%X) is -1',
  $ce;

is $ce & 127, 0x7F, join $", __FILE__, __LINE__,
  sprintf 'Lower 7 bits of $CHILD_ERROR (0x%X) are ones',
$ce & 127;

is $ce >> 8, (~0) >> 8, join $", __FILE__, __LINE__,
  sprintf 'Upper bytes of $CHILD_ERROR (0x%X) are ones',
$ce >> 8;
  };
},
  ],

  [
"Child kills itself with signal USR2",
['perl', '-e', 'kill "USR2", $$'],
q(perl -e 'kill "USR2", $$'),
sub {
  eval {
is $system, $ce, join $", __FILE__, __LINE__,

sprintf 'System return value (0x%X) is $CHILD_ERROR (0x%X)',
  $system,
  $ce;

isnt $ce, -1, join $", __FILE__, __LINE__,
  sprintf '$CHILD_ERROR (0x%X) isnt -1',
$ce;
  };
},
sub {
  my $code = q{
is $ce & 127, SIGUSR2, join $", __FILE__, __LINE__,
  sprintf 'Lower 7 bits of $CHILD_ERROR (0x%X) is SIGUSR2 (0x%X)',
$ce & 127,
SIGUSR2;

is $ce >> 8, 0, join $", __FILE__, __LINE__,
  sprintf 'Upper bytes of $CHILD_ERROR (0x%X) are zeroes',
$ce >> 8;
  };
  if (@args == 1 && -e '/etc/debian_version') {
TODO: {
	  local $TODO = 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028275;;

  eval $code;
}
  }
  else {
eval $code;
  }
},
  ],

  [
"Child exits with value 0xA5",
['perl', '-e', 'exit 0xA5'],
q(perl -e 'exit 0xA5'),
sub {
  eval {
is $system, $ce, join $", __FILE__, __LINE__,
  sprintf 'System return value (0x%X) is $CHILD_ERROR (0x%X)',
$system,
$ce;

isnt $ce, -1, join $", __FILE__, __LINE__,
  sprintf '$CHILD_ERROR (0x%X) isnt -1',
$ce;

is $ce & 127, 0, join $", __FILE__, __LINE__,
  sprintf 'Lower 7 bits of $CHILD_ERROR (0x%X) are zeroes',
$ce & 127;

is $ce >> 8, 0xA5, join $", __FILE__, __LINE__,
  sprintf 'Upper bytes of $CHILD_ERROR (0x%X) is 0xA5',
$ce >> 8;
  };
},
  ],
);

done_testing;



2023-01-15 13:24:04 dpchrist@laalaa ~/sandbox/perl
$ cat /etc/debian_version ; uname -a ; perl -v | head -n 2 | tail -n 1
11.6
Linux laalaa 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) 
x86_64 GNU/Linux
This is perl 5, version 32, subversion 1 (v5.32.1) built for 
x86_64-linux-gnu-thread-multi



2023-01-15 13:24:09 dpchrist@laalaa ~/sandbox/perl
$ perl system.t
# Child failed to execute
# @args='nosuchprogram', 'foo', 'bar'
ok 1 - system.t 50 STDOUT is empty string
ok 2 - system.t 56 STDERR like /Can't exec "nosuchprogram": No such file 
or directory/
ok 3 - system.t 59 System return value (0x) is 
$CHILD_ERROR (0x)

ok 4 - system.t 64 $CHILD_ERROR (0x) is -1
ok 5 - system.t 68 Lower 7 bits of $CHILD_ERROR (0x7F) are ones
ok 6 - system.t 72 Upper bytes of $CHILD_ERROR (0xFF) are ones
# @args='nosuchprogram foo bar'
ok 7 - system.t 50 STDOUT is empty string
ok 8 - system.t 56 STDERR like /Can't exec "nosuchprogram": No such file 
or directory/
ok 9 - system.t 59 System return value (0x) is 
$CHILD_ERROR (0x)

ok 10 - system.t 64 $CHILD_ERROR (0x) is -1
ok 

Bug#1028774: macsyfinder: FTBFS: RuntimeError: cannot join current thread

[Étienne Mollier]

Hi Nilesh,

Nilesh Patra, on 2023-01-16:
> https://github.com/gem-pasteur/macsyfinder/issues/58
> 
> I've now added a comment saying that the patch fixes these random
> issues. I am tempted to merge this patch and upload, but I am not 100%
> confident if it is correct. And hence, a review would be nice (Etienne,
> if you are reading this if you could check) or I'll wait for
> upstream action. They seem kind of active.

I reread the code without and with the patch, and I think I
begin to make sense of what could have happened: there is a
small probability to try to join on the main thread which I
think is not supposed to finish at this point, thus likely
causing the error.  The probability grows with the reduction of
the core count.  Also, it seems certain CPU may have allow more
fine grained threading models than others, explaining the
discrepancy between different brands.

Your change makes sense to me and should render the code robust.
I verified the build is not flaky after a dozen builds in the
environment where I saw the error previously.  This looks good
to me, and I learned a couple of things today.

> Again, thank you Santiago!

Seconded!

Thanks Lucas for the report, Santiago for the resource to
reproduce the issue, and Nilesh for actually fixing it!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.
On air: Canvas Solaris - Zero Point Field


signature.asc
Description: PGP signature

Bug#1027118: zabbix: FTBFS: error: invalid use of void expression

[Samuel Henrique]

This should be fixed by curl 7.87.0-2, which I uploaded just now.

curl BTS bug for reference: https://bugs.debian.org/1027564

Thanks,

-- 
Samuel Henrique 

Bug#1028447: cdist: unusable with python 3.11

[Steve Langasek]

On Sun, Jan 15, 2023 at 09:09:05PM +0100, Axel Beckert wrote:
> Dear Steve,

> Steve Langasek wrote:
> > > [1] https://code.ungleich.ch/ungleich-public/cdist/commit/b974969f28f4

> > Well, that's not the upstream repo listed in debian/copyright,

> JFTR:
> https://salsa.debian.org/debian/cdist/-/blob/debian/7.0.0-1/debian/upstream/metadata
> already had the up to date upstream VCS repo at the time you wrote the
> bug report. And that's the _canonical_ (sic!) place to look for the
> upstream VCS repo.

It absolutely is not.  Many packages that declare a Vcs URI in
debian/control don't provide upstream branches at all; those that do, do not
generally have any jobs in place to automatically sync from upstream; and
it's the nature of git that in the absence of looking at the content of such
a job, you do not know where the actual upstream is or whether the branch is
up to date with respect to it.

The only standard way to declare a pointer to upstream is in
debian/copyright, and that pointer pointed at a repo that had not been
updated.

Y'all are free to do what you want with this package, but it's in no way my
obligation to go hunting around for upstream git repos declared elsewhere.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#986152: Offer of help

[Romain Francoise]

Hi,

Replying to the latest messages in the thread in one go...

On Sun, Jan 08, 2023 at 02:35:17PM +, Jeremy Sowden wrote:
> I've created a Shorewall team on tracker.d.o and added you both to it.

Thanks!

On Mon, Jan 09, 2023 at 08:51:54AM -0500, Roberto C. Sánchez wrote:
> For a bit of historical context, the current multi-branch structure from
> the SF repo is quite antiquiated.  It is from a time before debhelper
> supported multiple .orig.tar.gz components.  It might make sense to
> consider starting with a new repo, with a more sensible branch
> structure (one that works more easily with tools like gbp), and that
> makes use of the multi-tarball capabilities so that you have have all
> the source packages in view at the same time.

That would be simpler indeed. The only worry is that it probably means
going through NEW very close to freeze... but on the other hand it eases
maintenance for the next few years in stable.

On Mon, Jan 09, 2023 at 08:48:38AM -0500, Roberto C. Sánchez wrote:
> My needs have been evolving the last few years and I have much less of a
> need for a tool like Shorewall these days.  Additionally, I have never
> used some of the advanced features (e.g., Multi-ISP, tc, accounting,
> etc.).  It would be good to have others involved in maintenance who are
> able to contribute in that way.

FWIW, I use the Multi-ISP feature.

> I'd like to mention that there is already a Gitlab group for upstream
> Shorewall work (which has been essentially dormant for some time):
> https://gitlab.com/shorewall
>
> It might make sense to consider if there is any overlap and if any of
> the Salsa work might be better house under the Shorewall Gitlab group.

Personally, I'm not a fan of hosting Debian source on upstream
infrastructure. And Salsa provides preconfigured CI pipelines that are
very useful. (I configured them already but they didn't run because
nothing was pushed the new repo yet.)

On Sun, Jan 15, 2023 at 10:38:43AM +, Jeremy Sowden wrote:
> I've managed to coax gbp into importing 5.2.8 into one upstream branch
> with each upstream tar-ball as a subdirectory:
>
>   [azazel@ulthar:/space/azazel/work/git/repos/salsa/azazel/shorewall 
> (master>)] $ ls -1
>   debian/
>   shorewall/
>   shorewall6/
>   shorewall6-lite/
>   shorewall-core/
>   shorewall-docs-xml/
>   shorewall-init/
>   shorewall-lite/

> I'm currently working on merging the debian/ directories.

Cool! Thanks for working on this.

Bug#1025274: License question about sf2 soundfont in Tuxguitar

[Helmar Gerloni]

> https://lists.debian.org/debian-legal/2023/01/msg5.html
> https://lists.debian.org/debian-mentors/2023/01/msg00097.html
Roberto, Tobias, thanks for your answers.

I have removed MagicSFver2.sf2 from the package and added a note to 
README.Debian.
The new package now depends on fluid-soundfont-gm, see
https://mentors.debian.net/package/tuxguitar/

The package builds and runs on amd64 and in Qemu for arm64. It looks pretty 
good to me now.
Maybe someone can take a look and upload it?
If there is anything more I can do, just let me know.

Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm

[Guilhem Moulin]

On Sun, 15 Jan 2023 at 21:49:33 +0100, Hauke Mehrtens wrote:
> I have the output I see on the terminal when a monitor is connected.

Unfortunately that doesn't help much, please use the aforementioned
README.debug.html instructions to get a log file.

> The comments look like a udev rule should create this. I can not find any
> udev rule doing anything with lvm on my system.

lvm2 ≥2.03.15-1 ships /usr/share/initramfs-tools/hooks/lvm2 ,
/lib/udev/rules.d/56-lvm.rules, and /lib/udev/rules.d/69-lvm.rules , and
the hook script install both files in the initramfs image (in
/usr/lib/udev/rules.d).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1028178: aubio FTBFS with Python 3.11 as default version

[IOhannes m zmoelnig]

Source: aubio
Followup-For: Bug #1028178

Dear Maintainer,

i've prepared and uploaded an NMU that fixes the problem.

Unfortunately, I failed to upload to a DELAYED/n queue (and instead uploaded
directly into the archives).

I sincerely apologize for that mistake.
In any case, i'm attaching the debdiff for the NMU.

Also note, that this NMU (along with the previous two NMUs) can be found in
https://salsa.debian.org/piem/aubio/-/merge_requests/1


cheers,
mfdsa
IOhannes
diff -Nru aubio-0.4.9/debian/changelog aubio-0.4.9/debian/changelog
--- aubio-0.4.9/debian/changelog2022-06-30 22:35:01.0 +0200
+++ aubio-0.4.9/debian/changelog2023-01-15 21:40:50.0 +0100
@@ -1,3 +1,10 @@
+aubio (0.4.9-4.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * waf compatibility with Python3.11 (Closes: #1028178)
+
+ -- IOhannes m zmölnig (Debian/GNU)   Sun, 15 Jan 2023 
21:40:50 +0100
+
 aubio (0.4.9-4.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru aubio-0.4.9/debian/patches/series aubio-0.4.9/debian/patches/series
--- aubio-0.4.9/debian/patches/series   2022-06-30 22:35:01.0 +0200
+++ aubio-0.4.9/debian/patches/series   2023-01-15 21:40:50.0 +0100
@@ -3,4 +3,5 @@
 fixpowerpc.patch
 fixi386.patch
 wscript_py3.patch
+waflib-py311.patch
 ffmpeg5.patch
diff -Nru aubio-0.4.9/debian/patches/waflib-py311.patch 
aubio-0.4.9/debian/patches/waflib-py311.patch
--- aubio-0.4.9/debian/patches/waflib-py311.patch   1970-01-01 
01:00:00.0 +0100
+++ aubio-0.4.9/debian/patches/waflib-py311.patch   2023-01-15 
21:40:50.0 +0100
@@ -0,0 +1,45 @@
+From: =?utf-8?q?=22IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29=22?=
+ 
+Date: Sun, 15 Jan 2023 21:33:38 +0100
+Subject: Make 'waflib' compatible with Python3.11
+
+---
+ waflib/ConfigSet.py | 2 +-
+ waflib/Context.py   | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/waflib/ConfigSet.py b/waflib/ConfigSet.py
+index 8212586..8142817 100644
+--- a/waflib/ConfigSet.py
 b/waflib/ConfigSet.py
+@@ -146,7 +146,7 @@ class ConfigSet(object):
+   Utils.writef(filename,''.join(buf))
+   def load(self,filename):
+   tbl=self.table
+-  code=Utils.readf(filename,m='rU')
++  code=Utils.readf(filename,m='r')
+   for m in re_imp.finditer(code):
+   g=m.group
+   tbl[g(2)]=eval(g(3))
+diff --git a/waflib/Context.py b/waflib/Context.py
+index ab6b154..cbe16c1 100644
+--- a/waflib/Context.py
 b/waflib/Context.py
+@@ -106,7 +106,7 @@ class Context(ctx):
+   cache[node]=True
+   self.pre_recurse(node)
+   try:
+-  function_code=node.read('rU',encoding)
++  function_code=node.read('r',encoding)
+   
exec(compile(function_code,node.abspath(),'exec'),self.exec_dict)
+   finally:
+   self.post_recurse(node)
+@@ -346,7 +346,7 @@ def load_module(path,encoding=None):
+   pass
+   module=imp.new_module(WSCRIPT_FILE)
+   try:
+-  code=Utils.readf(path,m='rU',encoding=encoding)
++  code=Utils.readf(path,m='r',encoding=encoding)
+   except EnvironmentError:
+   raise Errors.WafError('Could not read the file %r'%path)
+   module_dir=os.path.dirname(path)

Bug#1023716: cryptsetup: cryptroot-unlock in initramfs fails with lvm

[Hauke Mehrtens]

On 11/9/22 15:14, Guilhem Moulin wrote:

Control: tag -1 moreinfo unreproducible

Hi,

On Tue, 08 Nov 2022 at 22:36:39 +0100, Hauke Mehrtens wrote:

Unlocking and mounting of the root partitions does not work any more
from the initramfs. When I call cryptroot-unlock and provide the disk
password I see some error messages about mdadm, but the bootup process
does not continue. If needed I can provide the detailed messages, they
are not in a log file, but only printed on screen. Normally I unlock the
system over the network from the initramfs, then I do not get any error
message, but the system continues to stay in initramfs.


An LVM-specific regression in the `cryptroot-unlock` logic wouldn't have
broken the dropbear-initramfs autopkgtests since we don't use LVM there
anymore, but I tested it again after reverting the commit and the test
still pass.

 https://salsa.debian.org/debian/dropbear/-/jobs/3489869


It looks like this when unlocking the system unsuccessfully from the
initramfs over ssh:
--
$ ssh root@192.168.10.15
To unlock root partition, and maybe others like swap, run
`cryptroot-unlock`.

BusyBox v1.35.0 (Debian 1:1.35.0-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # vi /scripts/local-top/cryptroot
~ # cryptroot-unlock
Please unlock disk sda3_crypt:
cryptsetup: sda3_crypt set up successfully
~ #
--


I see nothing wrong in the above, `cryptroot-unlock` has only one job
which is to unlock the disk, and that appears to have worked.  Did the
system terminate the remote session before 2:2.5.0-2 and continued with
the boot process?  If so, perhaps the boot process is now blocking on
that shell session; does it help to type `exit` after `cryptroot-unlock`?

Otherwise, please compare your system messages withe the aforementioned
autopkgtest output, and/or provide debug output;  See 
/usr/share/doc/cryptsetup/README.debug
or https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html
for how to save it into a file.



Sorry for the long delay and thank you for the pointers.

I have the output I see on the terminal when a monitor is connected.
This is after I successfully entered the passphrase:
https://hauke-m.de/files/PXL_20230115_192349603.jpg

It looks like it can not find the root volume.

After issuing this command the root volume is available:
  lvm lvchange -a ay --sysinit -- system
https://hauke-m.de/files/PXL_20230115_195232849.jpg

The comments look like a udev rule should create this. I can not find 
any udev rule doing anything with lvm on my system.


Hauke

Bug#1028447: cdist: unusable with python 3.11

[Nico Schottelius]

Good evening everyone,

Axel Beckert  writes:

> Hi,
>
> Steve Langasek wrote:
>> On Sun, Jan 15, 2023 at 10:10:54AM +0100, s3v wrote:
>> > > Anyway, this package has no maintainer and upstream has not fixed this, 
>> > > and
>> > > there are no reverse-dependencies, so I would suggest the package should
>> > > just be removed.
>
> That's IMHO way too harsh given that the package is uptodate with the
> current upstream release despite being orphaned and the issue is
> easily fixable.

I agree and it has been fixed some weeks ago.

>> > Unless I missed something, upstream fixed this issue in [1]
>> > After applying this commit, I was able to build cdist in a sid
>> > chroot environment.
>>
>> > [1] https://code.ungleich.ch/ungleich-public/cdist/commit/b974969f28f4
>>
>> Well, that's not the upstream repo listed in debian/copyright, so if someone
>> wants to fix this bug perhaps they also want to fix the upstream pointer.
>
> Ack, https://github.com/telmich/cdist redirects to
> https://github.com/ungleich/cdist, but last commit there is from
> November 2021 and there's no note that it's no more updated.

So, that's a funky problem, I know. We moved away from github, long,
long time ago (probably 2021, that's why you see the last commit there).

However some in the cdist community wanted to keep the git repo on
github alive to allow easier contributions. As this did not really
materialise, we might actually delete and/or redirect that repo to
code.ungleich.ch, too.

> Funnily https://code.ungleich.ch/ungleich-public/cdist/#contributing
> refers to https://github.com/ungleich/cdist/pulls

Yes, it says "both" for contributing, but it does not say "we keep the
github repo updated". But yes, I can see how this might be confusing.

Again, the proper upstream URL is
https://code.ungleich.ch/ungleich-public/cdist/
and actually we also have a shiny website on...

https://www.cdi.st/

which references only the upstream repo.

> I'll take upstream into Cc so they're aware of these upstream
> infrastructure issues misleading users into thinking that upstream's
> development has stalled.

Much appreciated. I added to my todo list to replace the master branch
on github with a pointer to code.ungleich.ch, referencing this thread.

> I might also do a QA upload fixing these issues. No promises though,
> as I'm a bit out of time these days.

Thanks a lot Axel, much appreciated.

Best regards from Paris,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Antoine Beaupré]

On 2023-01-15 21:02:17, Christoph Biedl wrote:

[...]

> 1. Co-existence [alternatives]

[...]

> 2. Giving up the Go variant in favour of fq, ship only "python"

[...]

I like that idea. I particularly like shipping the Python version since
(according to you) it's more faithful to the `jq` operation, which I
like.

I am biased though, having packaged more Python things than Golang (but
liking both languages, I guess...)

In either case, I would favor "whatever someone has worked on". I
signaled the existence of the Python one to avoid a *future* naming
conflict, but if no one is packaging *that* then maybe it's best to let
whoever actually did a package upload that and resolve issues later. :)

It's kind of unfortunate people can't agree on the internet though, but
I don't think it's something we should fix before closing this issue,
otherwise it's going to be a while...

a.
-- 
Either you're with us or you're with the terrorist state.

Bug#839825: pithos: New version available

[Boyuan Yang]

X-Debbugs-CC: lfara...@debian.org

On Wed, 05 Oct 2016 23:02:42 +1030 David Purton 
wrote:
> Package: pithos
> Version: 1.1.2-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please consider packaging the latest version of pithos (currently
> 1.2.1).
> 
> In particular, I'm hoping that it fixes a problem I have with high CPU
> load with my GTK theme (Adapta Nokto). See this upstream bug report:
> https://github.com/pithos/pithos/issues/281

Dear maintainer,

Is there any update to it? It has been ~7 years since last maintainer
upload, and packaging the new version would be great. If you do not plan to
maintain it anymore, please also consider orphaning the package.

Thanks,
Boyuan Yang


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

Bug#1025695: openjdk-11-jdk: Please update to 11.0.16.1

[tony mancill]

On Wed, Dec 07, 2022 at 04:03:17PM +0100, Carsten Pfeiffer wrote:
> Package: openjdk-11-jdk
> Version: 11.0.16+8-1~deb11u1
> Severity: normal
> 
> Dear Maintainer,
> 
> openjdk 11.0.16 in Bullseye contains a severe problem that is fixed in 
> 11.0.16.1. See
> https://bugs.openjdk.org/browse/JDK-8292396
> https://bugs.openjdk.org/browse/JDK-8292260
> https://www.oracle.com/java/technologies/javase/11-0-16-1-relnotes.html
> 
> It would be nice, if an updated version could be provided, either 11.0.16.1 or
> 11.0.17, that is already available in Bookworm.

I am willing to perform the rebuild and upload of 11.0.17 against
bullseye, either a team upload or as an NMU.  Would that be acceptable
to the OpenJDK Team and the Security Team?

Thank you,
tony


signature.asc
Description: PGP signature

Bug#954662: obantoo: Obantoo includes an outdated BLZ.txt

[Jochen Sprickerhof]

Hi Tony,

* tony mancill  [2023-01-15 12:19]:

On Sun, Dec 18, 2022 at 01:49:59PM +0100, Jochen Sprickerhof wrote:

Hi Christian,

sorry for the late reply.

* Christian Weiske  [2022-03-14 17:47]:
> This problem still exists.
> I cannot transfer money to an N26 bank account, because jameica complains that
> the bank does not exist:
>
> > blz in der iban existiert nicht

Thanks for the report, I've just uploaded version 2.10.9+dfsg-2 that should
work around this problem (again).


Is this problem resolved?  Is it okay to mark this bug as closed?


I think the real solution here would be a package with up to date data 
(or some online service to check against, maybe). The current workaround 
is just there to avoid the software failing on a valid use case. Thus I 
would leave it open.


Are you interested in working on this?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1028987: linux-image-amd64: Does not build with rtlwifi

[Zach Flynn]

Package: linux-image-amd64
Version: 6.1.0-1
Severity: normal
X-Debbugs-Cc: zlfl...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Upgrading linux-image/linux-headers on Debian Sid with rtlwifi. 

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

sudo apt upgrade.  Then after it failed, I've been running sudo apt install -f 
to get it to retry after trying to fix.

   * What was the outcome of this action? 

The build fails (sudo apt install linux-image-amd64 fails). First, I got:

Deprecated feature: REMAKE_INITRD 
(/var/lib/dkms/rtlwifi-new/0.6/source/dkms.conf)

So I tried just removing that line from the dkms.conf file. Here is the log in 
/var/lib/dkms/rtlwifi-new/0.6/build/make.log after that:

DKMS make.log for rtlwifi-new-0.6 for kernel 6.1.0-1-amd64 (x86_64)
Sun Jan 15 02:14:08 PM CST 2023
make: Entering directory '/usr/src/linux-headers-6.1.0-1-amd64'

  ERROR: Kernel configuration is invalid.
 include/generated/autoconf.h or include/config/auto.conf are missing.
 Run 'make oldconfig && make prepare' on kernel src to fix it.

make: *** [/usr/src/linux-headers-6.1.0-1-common/Makefile:817: 
include/config/auto.conf] Error 1
make: Leaving directory '/usr/src/linux-headers-6.1.0-1-amd64'

I tried just following the instructions in the error.  But "make oldconfig" 
from that directory gives me:

  GEN Makefile
/usr/src/linux-headers-6.1.0-1-common/scripts/Makefile.build:44: 
/usr/src/linux-headers-6.1.0-1-common/scripts/basic/Makefile: No such file or 
directory
make[1]: *** No rule to make target 
'/usr/src/linux-headers-6.1.0-1-common/scripts/basic/Makefile'.  Stop.
make: *** [/usr/src/linux-headers-6.1.0-1-common/Makefile:644: scripts_basic] 
Error 2


   * What outcome did you expect instead?

The package to install.

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


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

Kernel: Linux 6.0.0-4-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

Versions of packages linux-image-amd64 depends on:
ih  linux-image-6.1.0-1-amd64  6.1.4-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

Bug#954662: obantoo: Obantoo includes an outdated BLZ.txt

[tony mancill]

On Sun, Dec 18, 2022 at 01:49:59PM +0100, Jochen Sprickerhof wrote:
> Hi Christian,
> 
> sorry for the late reply.
> 
> * Christian Weiske  [2022-03-14 17:47]:
> > This problem still exists.
> > I cannot transfer money to an N26 bank account, because jameica complains 
> > that
> > the bank does not exist:
> > 
> > > blz in der iban existiert nicht
> 
> Thanks for the report, I've just uploaded version 2.10.9+dfsg-2 that should
> work around this problem (again).

Is this problem resolved?  Is it okay to mark this bug as closed?

Bug#1028986: Multiple integer overflow and buffer overflow issues in game loading

[Ben Hutchings]

Package: sgt-puzzles
Version: 20220801.89391ba-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Ben Harris found multiple issues in sgt-puzzles where a malformed game
description or save file can lead to integer overflow or buffer
overflow.  These were fixed upstream today, and I'll upload the
changes to unstable shortly.

The Debian package doesn't register any media type handler for save
files, so I think this can only be exploited by social-engineering a
user into loading such a file or description.

Ben.

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 sgt-puzzles depends on:
ii  libc62.36-6
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libglib2.0-0 2.74.3-1
ii  libgtk-3-0   3.24.35-3
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1

Versions of packages sgt-puzzles recommends:
ii  chromium [www-browser]  108.0.5359.124-1
ii  firefox [www-browser]   108.0-2
ii  lynx [www-browser]  2.9.0dev.10-1+b1
ii  xdg-utils   1.1.3-4.1

sgt-puzzles suggests no packages.

-- debconf-show failed

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

[Lucas Nussbaum]

Hi Guillem,

> I'm wondering why diverge from the patch metadata guidelines? If there's
> a desire to change the field semantics, perhaps it would be better to
> change the guidelines instead? :)
> 
> But given this interchange, perhaps we should try to make it more
> clear or explicit about some of these aspects there!

Originally I admit that I misread the DEP3 rules.
Now the implementation is much closer to DEP3. Unfortunately, DEP3 was
probably not written with automatic processing in mind.

The current status of the data is the following[1]:

 forwarded_short | explanation  
|  cnt   | percent 
-+--++-
 no  | No Forwarded, No Bug field   
| 100145 |   68.12
 not-needed  |  
|  19329 |   13.15
 yes |  
|  12217 |8.31
 no  | Explicit Forwarded=no
|  11448 |7.79
 invalid | Invalid value for Forwarded field
|   2270 |1.54
 invalid | Forwarded=yes, but no Bug field  
|   1119 |0.76
 invalid | No forwarded, Debian bug in Bug: field. Bug-Debian: should 
be used instead.  |283 |0.19
 no  | No Forwarded, Upstream bug, but not a URL
|190 |0.13
 invalid | Forwarded=yes, Debian bug in Bug: field. Bug-Debian: should 
be used instead. |  8 |0.01

With some comments:
 no  | No Forwarded, No Bug field   
| 100145 |   68.12
=> that sticks to the DEP3 specification. (no forwarded: + no bugs: => implicit 
no)

 not-needed  |  
|  19329 |   13.15
=> that's an explicit "Forwarded: not-needed"

 yes |  
|  12217 |8.31
=> Those are the cases where it's clear that the bug has been forwarded

 no  | Explicit Forwarded=no
|  11448 |7.79
=> that's an explicit "Forwarded: no"


The remaining lines are the ones that could require discussion.
First, it's worth noting that they only account for 2.63% of the
patches.

 invalid | Invalid value for Forwarded field
|   2270 |1.54
=> I looked at the values considered invalid[2], and could not really convince
myself that they should automatically fit in one of the above
categories.

 invalid | Forwarded=yes, but no Bug field  
|   1119 |0.76
=> I think that we should strongly encourage leaving a public trace when
forwarding bugs

 invalid | No forwarded, Debian bug in Bug: field. Bug-Debian: should 
be used instead.  |283 |0.19
=> quite obviously invalid

 no  | No Forwarded, Upstream bug, but not a URL
|190 |0.13
=> those are mostly patches misusing the Bug: field for the Debian
bug.[3]. Since the specification requires a URL here, it could be
considered invalid as well.

 invalid | Forwarded=yes, Debian bug in Bug: field. Bug-Debian: should 
be used instead. |  8 |0.01
=> quite obviously invalid

So, all in all, my implementation[4] sounds sane.

> I otherwise do not know how we can mark patches as forwarded when
> for example you send them directly to upstream via email or to a mailing
> list that has no public archive or similar.

That's true. Other than blinding accepting "Forwarded: yes", I don't
know how this could be addressed.

> I think the Origin field needs to be taken into account too, in
> particular when it has an "upstream" or a "backport" value. As well as
> the Applied-Upstream field.

I would prefer the Forwarded field to be a simple field only allowing
'no', 'not-needed', and maybe 'yes' (with the pointer to where the patch
was forwarded in a separate field).

Or if the Forwarded field's value is supposed to be computed, I think
that we should provide a more detailed specification of the algorithm.

- Lucas

[1] UDD query:
SELECT forwarded_short, invalid_reason, cnt, round(100.0 * cnt / (sum(cnt) OVER 
()),2) as percent
FROM ( select forwarded_short, invalid_reason, count(*) cnt from patches group 
by 1,2 ) foo
order by 3 desc

[2] UDD query:
select forwarded, count(*) from patches where invalid_reason='Invalid value for 
Forwarded field' group by 1 order by 2 desc;

[3] UDD query:
select forwarded, 

Bug#1028447: cdist: unusable with python 3.11

[Axel Beckert]

Dear Steve,

Steve Langasek wrote:
> > [1] https://code.ungleich.ch/ungleich-public/cdist/commit/b974969f28f4
> 
> Well, that's not the upstream repo listed in debian/copyright,

JFTR:
https://salsa.debian.org/debian/cdist/-/blob/debian/7.0.0-1/debian/upstream/metadata
already had the up to date upstream VCS repo at the time you wrote the
bug report. And that's the _canonical_ (sic!) place to look for the
upstream VCS repo.

> so if someone wants to fix this bug perhaps they also want to fix
> the upstream pointer.

Will update the URL in debian/copyright, too, yes.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Christoph Biedl]

Varac wrote...

> * Package name: yq
>   Version : 2.1.2
>   Upstream Author : Mike Farah 
> * URL : http://mikefarah.github.io/yq/

Hello everybody,

it's been a while ... bookworm freeze is getting closer, and I'd like to
find a solution for the current problems providing an "yq" program to
handle yaml documents.

To sum it up:

* This ITP originally was about an implementation in Go ("go", by
  mikefarah)
  Pros:
  + (Possibly) faster
  + The first one in this thread
* There is another implementation in pure Python ("python", by kislyuk)
  Pros:
  + Simple
  + By design behaviour identical to jq
* The respective upstream are not willing to resolve the name clash

In the meantime, there is a new player around, called "fq"
, a somewhat Swiss army knife wrt
supported formats. Written in Go as well, it is available in bookworm.
Backporting to bullseye is at least not trivial.


Now my main interest was to have something as /usr/bin/yq, not just for
me but for everybody.

Ideas:

1. Co-existence

Debian ships both variants but with different binary names like "yq-go",
"yq-python" or "yq-mikefarah" and "yq-kislyuk". Using Debian's
alternatives system, user can set their preferred variant.

Pros:
+ Provides all flavours

Cons:
- Maintainance overhead
- Users might be confused because /usr/bin/yq is not what they expect
  (generic problem with alternatives)

2. Giving up the Go variant in favour of fq, ship only "python"

Assuming "go" and fq overlap a lot, one might argue there's little use
in providing both. So there would by "python" as the "yq" program for
the simple use cases, everybody else please refer to fq.

Pros:
+ Packaging "python" should be simple and backportable

Cons:
- Anything specific to "go" is not available.

3. (your idea here)


Thoughts?

Christoph

¹ Fun story, years ago I implemented a little brother of "python", a
  simple Perl script that reads YAML and pipes it to jq. Not at all
  proud of it, and I'll be happy to ditch it.



signature.asc
Description: PGP signature

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

[Agustin Martin]

Control: reassign -1 irussian
Control: tags -1 + patch pending

El sáb, 14 ene 2023 a las 15:39, Jason Lee Quinn
() escribió:
>
> Package: dictionaries-common
> Version: 1.29.3
> Followup-For: Bug #1028473
> X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com
>
> Thank you for the reply.
>
> If these dictionaries are installed,
> where are they located? I've searched
> /usr/lib/ispell and many other places can only find
> american and british dictionaries on my machine.

Hi,

You should find relevant files under different dirs. In one of my boxes

$ dir /usr/lib/ispell/ /usr/share/ispell/ /var/lib/ispell/
/var/lib/dictionaries-common/ispell/

/usr/lib/ispell/:
american.affcastellano.hash  english.affespanol.hash
spanish.hash
american.hashdefault.aff espa~nol.affREADME.select-ispell
castellano.affdefault.hash espa~nol.hashspanish.aff

/usr/share/ispell/:
american.med+.mwl.gz  american.mwl.gz  english.aff  espa~nol.mwl.gz

/var/lib/dictionaries-common/ispell/:
iamerican  ispanish

/var/lib/ispell/:
american.compat  american.hashamerican.remove  espa~nol.compat
espa~nol.hash  espa~nol.remove  README

If there is no trace of those dicts in your dirs, synaptic is
upgrading something else (A virtual machine?)

> Also where does the "contains illegal characters" message
> actually come from? Whatever the source of that messgae,
> I'm having trouble tracking it down. A techincal explaination
> about why the message is harmless would also be interesting
> for me. Perhaps the message itself and the logic that produces
> it could be improved to provide a nicer user experience.

Munched word in line 39 of original russian ispell dict contains
whitespace, which is allowed only as word separator, not in the middle
of a word. Then ispell (and aspell) complains about it and skips that
word, that is the message. This is harmless because its only result is
that word is skipped.

Attached patch should strip that word before package is built, thus
making the message go away. I am reassigning this bug report to
irussian (I am also uploader for it)  and will upload a package with
this fix unless maintainer disagree.

Thanks again for your feedback.

-- 
Agustin
diff --git a/debian/rules b/debian/rules
index 565a92f..2ce6cfc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ export LANG LC_ALL
 override_dh_auto_build:
 	# Generate ispell dictionary.
 	grep -h '[３]' $(DICTIONARIES) | tr '\243\263' '\305\345' > yo_subst.koi
-	cat $(DICTIONARIES) yo_subst.koi |./sortkoi8 | uniq > $(ILANGUAGE).dict
+	cat $(DICTIONARIES) yo_subst.koi |./sortkoi8 | uniq | LC_ALL=C grep -v ' ' > $(ILANGUAGE).dict
 	sed -e "s/^\#[ye]//;s/^\#koi/wordchars/" $(ILANGUAGE).aff.koi > $(ILANGUAGE).aff
 	# Generate traditional ispell hash needed by i2myspell.
 	buildhash $(ILANGUAGE).dict $(ILANGUAGE).aff $(ILANGUAGE).hash

Bug#1028965: RFS: linux/6.1.6-1~exp1 [ITP] -- Linux for multiprocessor

[Diederik de Haas]

On Sun, 15 Jan 2023 15:59:13 +0100 vmxevils...@gmail.com wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "linux":
> 
>  * Package name : linux
>Version  : 6.1.6-1~exp1
>Upstream contact : Salvatore Bonaccorso 
>  * URL  : https://www.kernel.org/
>  * License  : Unicode-data, LGPL-2.1, GPL-2+-or-X11, CRYPTOGAMS, 
LGPL-2.1 or BSD-2-clause, GPL-2 or BSD-2-clause, GPL-2, Xen-interface
>  * Vcs  : https://salsa.debian.org/kernel-team/linux
>Section  : kernel

JFTR: This isn't the way and Salvatore isn't the Upstream contact and was not 
made aware of this (prior).

6.1.6 is already present in salsa and earlier today an email was send out 
about the intention for an upload of 6.1.6
https://salsa.debian.org/kernel-team/linux/-/commit/
f44a493cc158a227718de2689434bb6db107edd8

IOW: in sofar it wasn't already completely obvious, ignore this RFS.

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

Bug#1028447: cdist: unusable with python 3.11

[Axel Beckert]

Hi,

Steve Langasek wrote:
> On Sun, Jan 15, 2023 at 10:10:54AM +0100, s3v wrote:
> > > Anyway, this package has no maintainer and upstream has not fixed this, 
> > > and
> > > there are no reverse-dependencies, so I would suggest the package should
> > > just be removed.

That's IMHO way too harsh given that the package is uptodate with the
current upstream release despite being orphaned and the issue is
easily fixable.

> > Unless I missed something, upstream fixed this issue in [1]
> > After applying this commit, I was able to build cdist in a sid
> > chroot environment.
> 
> > [1] https://code.ungleich.ch/ungleich-public/cdist/commit/b974969f28f4
> 
> Well, that's not the upstream repo listed in debian/copyright, so if someone
> wants to fix this bug perhaps they also want to fix the upstream pointer.

Ack, https://github.com/telmich/cdist redirects to
https://github.com/ungleich/cdist, but last commit there is from
November 2021 and there's no note that it's no more updated.

Funnily https://code.ungleich.ch/ungleich-public/cdist/#contributing
refers to https://github.com/ungleich/cdist/pulls

I'll take upstream into Cc so they're aware of these upstream
infrastructure issues misleading users into thinking that upstream's
development has stalled.

I might also do a QA upload fixing these issues. No promises though,
as I'm a bit out of time these days.

Regards, Axel (original author of Debian's cdist package)
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028913: closed by Debian FTP Masters (reply to Emmanuel Arias ) (Bug#1028913: fixed in poetry 1.3.2+dfsg-2)

[Sandro Tosi]

not only that but the traceback clearly points at pylev being missing
from cleo's dependencies not poetry, so addressing it in poetry is
incorrect

On Sun, Jan 15, 2023 at 1:00 PM Vincent-Xavier JUMEL
 wrote:
>
> Hello, python3-pylev isn't a Build-Deb but à runtime dependencie
>
> Thank you so much
>
> Le 15 janv. à 01:39 Debian Bug Tracking System a écrit
> > This is an automatic notification regarding your Bug report
> > which was filed against the python3-poetry package:
> >
> > #1028913: python3-poetry: poetry commands depends on pylev (python3-pylev)
> >
> > It has been closed by Debian FTP Masters  
> > (reply to Emmanuel Arias ).
> >
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Debian FTP Masters 
> >  (reply to Emmanuel Arias 
> > ) by
> > replying to this email.
> >
> >
> > --
> > 1028913: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028913
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
>
> > Date: Sun, 15 Jan 2023 00:35:49 +
> > From: Debian FTP Masters 
> > To: 1028913-cl...@bugs.debian.org
> > Subject: Bug#1028913: fixed in poetry 1.3.2+dfsg-2
> > Reply-To: Emmanuel Arias 
> > Message-Id: 
> >
>
> [---=| Quote block shrunk by t-prot: 82 lines snipped |=---]
> >
> > python3-poetry suggests no packages.
> >
> > -- no debconf information
> >
> > --
> > Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net
> >
> > Société Libre, Logiciel Libre http://www.april.org/adherer
> > Parinux, logiciel libre à Paris : http://www.parinux.org
>
>
> --
> Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net
>
> Société Libre, Logiciel Libre http://www.april.org/adherer
> Parinux, logiciel libre à Paris : http://www.parinux.org
>


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#825222: lintian: please allow debian/source/timestamps in unknown-file-in-debian-source

[Axel Beckert]

Control: tag -1 wontfix

Hi,

Abou Al Montacir wrote:
> I recently was interested in solving Lintian errors on FPC and
> friends and got pointed to this ticket.

I just checked
https://codesearch.debian.net/search?q=2022+path%3Adebian%2Fsource%2Ftimestamps=1
and it seems that exactly 2 source packages (fpc and lazarus) are using this.

Just affecting two packages is IMHO a valid case for lintian
overrides.

It's though a small change with practically no chance for false
positives, so I'm no directly opposed to implementing it.

I though wonder: Are more packages expected to use that? I mean, the
initial bug report ist from 2016 and I only see two packages using it.

> I tend to agree with Paul that the timestamps file is better located in
> debian/source folder and would lobby for that.

This seems to be the wrong audience for a discussion about the
location of that file. Such a discussion should come _before_ Lintian is
asked to implement something.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028821: missing mayavi2 should be installable soon

[Étienne Mollier]

Control: tags -1 confirmed pending

Hi,

Failure to install pysurfer build dependencies should be solved
once mayavi2 is rebuilt for python3.11.  This should be soon.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.
On air: Scenes - Mysterious Bird


signature.asc
Description: PGP signature

Bug#1028774: macsyfinder: FTBFS: RuntimeError: cannot join current thread

[Nilesh Patra]

On Sun, Jan 15, 2023 at 04:36:39PM +0100, Santiago Vila wrote:
> El 15/1/23 a las 15:45, Nilesh Patra escribió:
> > On Sun, Jan 15, 2023 at 02:02:15PM +0100, Santiago Vila wrote:
> > > I can reproduce this build failure on Hetzner virtual machines with 2 
> > > CPUs,
> > > where it fails randomly 50% of the time.
> > > 
> > > Therefore, to reproduce the randomness, you have to try many times.
> > 
> > I built it 50 times on barriere.debian.org (4 CPUs) and did not hit
> > the failure even once. I don't think I have the time/energy for further
> > debug this any further; I'd have tried if it was properly reproducible.
> 
> The randomness is 100% reproducible on *certain* machines. Unfortunately,
> as you have just checked, barriere was not one of them, but I can offer
> ssh access to such a machine. Please contact me privately for details.
> 
> Packages which FTBFS randomly are the worst, that's why I always offer ssh
> access to a machine where they happen when I report one of those bugs.

Thank you Santiago for providing me access to your instance and helping
me emulate the failure there. I am able to repro it on 5-6 attempt at
re-building.

The test code that fails in question does not make a lot of sense to me,
as some of it seems redundant and there's probably a bug there. I tried
to apply a small patch which I consider what upstream was trying to do,
and I built the package ~25 times with this script (in lots of 15 + 10)

#!/bin/bash

for i in {1..10}; do
cd /home/nilesh/macsyfinder && sbuild -d bookworm --no-clean-source 
2>&1 > /tmp/log
fgrep -q "cannot join current thread" 
/home/nilesh/macsyfinder_2.0-2_amd64.build
x=$?
if [ "$x" != 1 ]; then exit $x; fi
echo -n "Loop complete: "
echo $i
done

And I could see it being successful (I also checked the last 50 lines of
each *.build file and the status was successful). I had also sent the patch in
comments to upstream in the issue linked with this bug report

https://github.com/gem-pasteur/macsyfinder/issues/58

I've now added a comment saying that the patch fixes these random
issues. I am tempted to merge this patch and upload, but I am not 100%
confident if it is correct. And hence, a review would be nice (Etienne,
if you are reading this if you could check) or I'll wait for
upstream action. They seem kind of active.

Again, thank you Santiago!

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1028975: allegedly, tar warnings are not errors

[Marco d'Itri]

On Jan 15, Axel Beckert  wrote:

> I tend to ignore any tar STDERR output saying "tar: Ignoring" as
> solution for this issue. Do you think that should suffice?
Looks like a good start.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1028975: allegedly, tar warnings are not errors

[Axel Beckert]

Hi Marco,

Marco d'Itri wrote:
> tar complains to stderr about features of archives that it does not 
> understand, but the maintainer says that this is all right and consumers 
> of tar's output need to deal with it (see #1028970 for details).

Legit IMHO. Thanks for the bug report.

> How to reproduce:
> 
> $ libcrypt-x509-perl_0.55-1_amd64.changes
> Warning in processable ./libcrypt-x509-perl_0.55-1.dsc: Tried to issue 
> duplicate hint in check unpack: unpack-message-for-source tar: Ignoring 
> unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.lastuseddate#PS'
> E: libcrypt-x509-perl source: unpack-message-for-orig 
> libcrypt-x509-perl_0.55.orig.tar.gz . tar: Ignoring unknown extended header 
> keyword 'LIBARCHIVE.xattr.com.apple.lastuseddate#PS'
> W: libcrypt-x509-perl source: newer-standards-version 4.6.2.0 (current is 
> 4.6.1.0)
> 
> If this is not a real error then maybe it should have pedantic severity 
> instead.

I tend to ignore any tar STDERR output saying "tar: Ignoring" as
solution for this issue. Do you think that should suffice?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1025868: Should we remove bin-sbin-mismatch due to unfixable false positives and being obsolete due to usrmerge?

[Axel Beckert]

Hi,

[This mail is a side-effect of trying to fix the remaining part of the
RC bug #1025868 against lintian.]

I'm thinking about retiring the tag bin-sbin-mismatch due difficult to
solve false positive (and currently triggering an RC bug).

It has been introduced in #930702 and sounded like a good idea, but
caused quite some not so trivial to fix issues (if fixable at all),
especially false positives:

* #1017632: false positives on partial matchs — IMHO unfixable.

* #974677: false positive when using variables — probably partially
  fixable (i.e. unfixable) by ignoring cases where "}" stands directly
  before "/bin/" and maybe where "\$\w+" matches before directly
  before "/bin/". But the first will still have some false positives
  (being language-dependent and at least in shell and Perl it
  additionally requires strict adhering to some coding standards in
  the tested package — which is unrealistic).

* zsh: false positives when doing symlinking /bin/zsh and /usr/bin/zsh
  in postinst/postrm for non-usrmerge systems instead of shipping them
  properly in the package due to the usrmerge mess. (Not reported,
  just overridden.)

Additionally it has the following other issues:

* As far as I understand the topic, this tag is obosoleted by the
  forced usrmerge migration as those mismatch seem to be no more
  relevant since then.

* Order of the output parameters seem to vary per architecture, see
  the remaining issue of the current RC bug #1025868 against lintian
  (Cc'ed). I think this is related to C compilers/linkers not
  generating the same variable order on different architectures, see
  the test case which caused the RC bug:
  
https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/files/contents/bin-sbin-confusion-in-elf/build-spec/orig/calls-sbin.c

  Paul: Expect an update on the last remaining piece of #1025868 soon.
  I have a working arm64 Sid again. armhf and i386 didn't suffice to
  reproduce. But I clearly see the problem. :-/

* Misleading tag name, at least without the full tag desc I always
  expect that /sbin/$program and /bin/$program are mixed up. There's
  no "usr" present in the tag name. A potential better tag name would
  be something like bin-usr-bin-mismatch (with sbin being a seldom
  special case of it).

Other points which are no issue itself, but make the tag removal
potentially a bit easier, i.e. likely reduce the impact of removal:

* The tag is marked as experimental, i.e. not shown by default.

* The submitter of #930702 (i.e. the feature request submitter)
  himself is no more active in Debian. (And he — IMHO unfortunately —
  rage-quitted Debian over the systemd controversy, so I doubt that
  he's still interested in Debian, let it be alone Lintian. So I did
  not Cc him to not bother him with stuff reminding him of Debian.)

And given that other recent tag removal proposals (e.g.
very-long-line-length-in-source-file) lead into objections, also from
my side, I'd like to hear first if there's someone who considers this
tag useful.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1028985: monit: Monit check for running rsyslogd is broken

[Alex]

Package: monit
Version: 1:5.27.1-1~bpo10+1
Severity: important

Dear Maintainer,
the monit script to check for a running rsyslogd is checking
/var/run/rsyslog.pid, which does not exist by default (on a system using
systemd) to check if rsyslogd is running.
The script should probably be patched to use "check process matching"
instead of "check process pidfile"

-- System Information:
Debian Release: 10.13
  APT prefers oldstable
  APT policy: (900, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages monit depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10+deb10u2
ii  libpam0g 1.3.1-5
ii  libssl1.11.1.1n-0+deb10u3
ii  lsb-base 10.2019051400
ii  zlib1g   1:1.2.11.dfsg-1+deb10u2

monit recommends no packages.

Versions of packages monit suggests:
ii  ssmtp [mail-transport-agent]  2.64-8+b2
pn  sysvinit-core 

-- Configuration Files:
/etc/monit/monitrc [Errno 13] Keine Berechtigung: '/etc/monit/monitrc'

-- no debconf information

Bug#1028984: dh-ada-library: autopkgtest needs update for new version of gcc-10: deprecation warning on stderr

[Paul Gevers]

Source: dh-ada-library
Version: 8.5
Severity: serious
X-Debbugs-CC: gcc...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-10

Dear maintainer(s),

With a recent upload of gcc-10 the autopkgtest of dh-ada-library fails 
in testing when that autopkgtest is run with the binary packages of 
gcc-10 from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
gcc-10 from testing10.4.0-7
dh-ada-library from testing8.5
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. The actual 
tests seem to pass but the autopkgtest fails because there are 
deprecation warnings on stderr. Without the allow-stderr restriction, 
autopkgtest errors out on output to stderr.


Currently this regression is blocking the migration of gcc-10 to testing 
[1]. Of course, gcc-10 shouldn't just break your autopkgtest (or even 
worse, your package), but it seems to me that the change in gcc-10 was 
intended and your package needs to update to the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from gcc-10 should really add 
a versioned Breaks on the unfixed version of (one of your) package(s). 
Note: the Breaks is nice even if the issue is only in the autopkgtest as 
it helps the migration software to figure out the right versions to 
combine in the tests.


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
gcc-10/10.4.0-7. I.e. due to versioned dependencies or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=gcc-10

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dh-ada-library/30391876/log.gz

Running Makefile
dpkg-architecture: warning: cannot determine CC system type, falling 
back to default (native compilation)
dpkg-buildflags: warning: cannot determine CC system type, falling back 
to default (native compilation)
ADAFLAGS=-g -O0 
-ffile-prefix-map=/tmp/autopkgtest-lxc.yefsn1ti/downtmp/autopkgtest_tmp/pkg=. 
-fstack-protector-strong canary -gno-record-gcc-switches

-Wformat
cflag
-O0
canary
-gno-record-gcc-switches
OK
autopkgtest [02:16:18]: test adaflags



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028983: yade: FTBFS with Python 3.11 as default version

[Graham Inggs]

Source: yade
Version: 2022.01a-13
Severity: serious
Tags: ftbfs patch
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

yade FTBFS with Python 3.11 as default version, although the build
doesn't fail, it is mislinked against Python 3.10.

I believe this is the relevant part of the log:

Loop on the following python versions and check available
dependencies:3.10;3.9;3.8;3.7;3.6;3.5;3.4;3.3;3.2;3.1;3.0
-- Found PythonInterp: /usr/bin/python3.10 (found version "3.10.9")
Trying python version: 3.10 parsed as 3 10
Python version 3.10.9 found, try to import dependencies...
Boost_VERSION=107400, adding boost_python310 lib

Updating debian/patches/30_python310.patch as follows worked for me:

-+SET(PY3_VERSIONS 3.10 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
#append newer python versions at the beginning here.
++SET(PY3_VERSIONS 3.11 3.10 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
#append newer python versions at the beginning here.

Regards
Graham


[1] 
https://buildd.debian.org/status/fetch.php?pkg=yade=amd64=2022.01a-13=1673794605=0

Bug#1028982: metakernel: autopkgtest regression on s390x: AssertionError

[Paul Gevers]

Source: metakernel
Version: 0.29.4-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of metakernel the autopkgtest of metakernel fails 
in testing when that autopkgtest is run with the binary packages of 
metakernel from unstable on s390x. It passes when run with only packages 
from testing. In tabular form:


   passfail
metakernel from testing0.29.4-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

[0] You can see what packages were added from the second line of the log 
file quoted below. The migration software adds source package from 
unstable to the list if they are needed to install packages from 
metakernel/0.29.4-1. I.e. due to versioned dependencies or breaks/conflicts.

[1] https://qa.debian.org/excuses.php?package=metakernel

https://ci.debian.net/data/autopkgtest/testing/s390x/m/metakernel/30188929/log.gz

=== FAILURES 
===
 test_ls_path_complete 
_


def test_ls_path_complete():
kernel = get_kernel()
comp = kernel.do_complete('! ls ~/.ipytho', len('! ls ~/.ipytho'))

  assert comp['matches'] == ['ipython/'], comp
E   AssertionError: {'cursor_end': 14, 'cursor_start': 8, 'matches': 
['"ls', '-cdfa', 'compgen', 'ipython/', '~/.ipytho"'], 'metadata': {}, ...}

E   assert ['"ls', '-cdf... '~/.ipytho"'] == ['ipython/']
E At index 0 diff: '"ls' != 'ipython/'
E Left contains 4 more items, first extra item: '-cdfa'
E Use -v to get more diff

/usr/lib/python3/dist-packages/metakernel/tests/test_metakernel.py:85: 
AssertionError
=== short test summary info 

FAILED 
../../../../../usr/lib/python3/dist-packages/metakernel/tests/test_metakernel.py::test_ls_path_complete
=== 1 failed, 77 passed, 4 skipped in 31.59s 
===
E: pybuild pybuild:388: test: plugin pyproject failed with: exit code=1: 
cd /tmp/autopkgtest-lxc.v7kgsgqo/downtmp/autopkgtest_tmp/build; 
python3.10 -m pytest -o cache_dir={home_dir}/.pytest_cache 
${{PYBUILD_AUTOPKGTEST:+/usr/lib/python3/dist-packages/metakernel}}

Traceback (most recent call last):
  File "/usr/bin/pybuild", line 386, in main
run(func, i, version, c)
  File "/usr/bin/pybuild", line 324, in run
result = func(context, args)
  File "/usr/share/dh-python/dhpython/build/base.py", line 290, in 
wrapped_func

raise Exception(msg)
Exception: exit code=1: cd 
/tmp/autopkgtest-lxc.v7kgsgqo/downtmp/autopkgtest_tmp/build; python3.10 
-m pytest -o cache_dir={home_dir}/.pytest_cache 
${{PYBUILD_AUTOPKGTEST:+/usr/lib/python3/dist-packages/metakernel}}
pybuild-autopkgtest: error: pybuild --autopkgtest --test-pytest -i 
python{version} -p "3.11 3.10" returned exit code 13

make: *** [/tmp/A5vBrDVBPL/run:4: pybuild-autopkgtest] Error 25
pybuild-autopkgtest: error: /tmp/A5vBrDVBPL/run pybuild-autopkgtest 
returned exit code 2

autopkgtest [16:39:02]: test pybuild-autopkgtest



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028957: librocrand-dev: rocrand_INCLUDE_DIR does not exist

[Étienne Mollier]

Hi Cordell,

Not sure it will help, but I suppose I could first bump the
rocrand package up to 5.2.3 to be consistent with the build
chain.  It should still be easy to do while we're not in the
next stage of the freeze on February 12th.

Cordell Bloor, on 2023-01-15:
> The rocRAND and hipRAND repos upstream were split after ROCm 5.0, but only
> sort-of. The hipRAND repo was moved into a git submodule. Upstream still
> builds the two libraries together, just like in ROCm 5.0 (at least for now).
> So, perhaps the simplest step would be to make rocrand / hiprand a
> multi-upstream tarball repo?

There is that, or packaging hipRAND in a side package.  Given
the affinity between the two, multi-upstream tarball may be the
most natural approach in this case.

> The upstream hipRAND repo does't have any tags (and therefore getting tarballs
> with uscan might be tricky?). If tags would help, I can work with upstream to
> get them added retroactively for rocm-5.1.0 and later. Just let me know.

For a regular package it would be possible to use git commit IDs
instead, but that leads to hard to read version numbers.  In the
case of MUT, strolling through the example from rocm-hipamd, I
see it may be necessary to restrict the version number of the
side tarball to be the same as the main source package.  So...
yes please?  :)

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.
On air: King Gizzard & The Lizard Wizard - Change


signature.asc
Description: PGP signature

Bug#1028667: dask BD-Uninstallable

[Rebecca N. Palmer]

Probably fixed - see my merge request on Salsa.

Bug#1019865: evolution Hangs and goes to 100% CPU usage on compose

[Jeremy Bicha]

On Sun, Dec 11, 2022 at 9:29 AM Jeremy Bicha  wrote:
> Could y'all verify whether you still have this issue?
>
> Please upgrade to Evolution 3.46.2 which just landed in Testing today.
> Please log out and log back in to make sure you're running the latest
> version of evolution-data-server also.

Could anyone affected by this issue please verify whether the issue
still happens with 3.46.2 or 3.46.3?

Also, if you're running Unstable or Testing, you may get faster
results by reporting issues upstream:

https://gitlab.gnome.org/GNOME/evolution/-/issues

Thank you,
Jeremy Bicha

Bug#1028597: depthcharge-tools-installer: [INTL:de] initial German debconf translation

[Holger Wansing]

Hi,

Helge Kreutzmann  wrote (Sat, 14 Jan 2023 07:48:48 +0100):
> On Sat, Jan 14, 2023 at 12:38:46AM +0100, Holger Wansing wrote:
> > I've also added a note in the templates.pot file for these packages, which 
> > should
> > warn translators to not work on these files directly.
> 
> This note is not present. To double check, I just issued
> wget 
> https://i18n.debian.org/material/po/unstable/main/d/depthcharge-tools-installer/debian/po/depthcharge-tools-installer_2_templates.pot.gz
> 
> And reviewed the the file again. No note.

Hmm. I investigated this, the note *is* indeed present in the source package,
but in the file quoted above it is not.

So, there is something within the process of collecting the data for 
i18n.debian.org, which removes it. Sadly.

Ok, adding the note was just an idea, to save translators from doubled work,
sadly it does not work.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1027686: transition: rakudo

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2023-01-15 18:49:24 +0100, Dominique Dumont wrote:
> On Sunday, 15 January 2023 15:21:55 CET Sebastian Ramacher wrote:
> > > I've found where compiler-id is computed. I'm going patch rakudo in
> > > experimental so that compiler-id depends only on source files and nqp
> > > version. This patch will land in experimental.
> > 
> > Okay, please let me know once it's available in experimental.
> 
> Done with rakudo 2022.12-1~exp3
> 
> I've patched the compiler id to be a sha1 of "Debian-".
> 
> I've verified that compiler id is the same for the arch that are built.
> 
> Is it still time to trigger a transition to fix all raku modules ? (there's 
> no 
> impact outside of raku modules)

Thanks, please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1028447: cdist: unusable with python 3.11

[Steve Langasek]

On Sun, Jan 15, 2023 at 10:10:54AM +0100, s3v wrote:
> > It looks like this is easily fixable without regression by removing the
> > first assignment to parser['scan'], but this seems like such an obvious bug
> > that I don't know if I'm missing something with historical behavior of
> > argparse handling multiple assignments?

> > Anyway, this package has no maintainer and upstream has not fixed this, and
> > there are no reverse-dependencies, so I would suggest the package should
> > just be removed.

> Unless I missed something, upstream fixed this issue in [1]
> After applying this commit, I was able to build cdist in a sid
> chroot environment.

> [1] https://code.ungleich.ch/ungleich-public/cdist/commit/b974969f28f4

Well, that's not the upstream repo listed in debian/copyright, so if someone
wants to fix this bug perhaps they also want to fix the upstream pointer.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1028913: closed by Debian FTP Masters (reply to Emmanuel Arias ) (Bug#1028913: fixed in poetry 1.3.2+dfsg-2)

[Vincent-Xavier JUMEL]

Hello, python3-pylev isn't a Build-Deb but à runtime dependencie

Thank you so much

Le 15 janv. à 01:39 Debian Bug Tracking System a écrit
> This is an automatic notification regarding your Bug report
> which was filed against the python3-poetry package:
> 
> #1028913: python3-poetry: poetry commands depends on pylev (python3-pylev)
> 
> It has been closed by Debian FTP Masters  
> (reply to Emmanuel Arias ).
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Emmanuel Arias 
> ) by
> replying to this email.
> 
> 
> -- 
> 1028913: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028913
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

> Date: Sun, 15 Jan 2023 00:35:49 +
> From: Debian FTP Masters 
> To: 1028913-cl...@bugs.debian.org
> Subject: Bug#1028913: fixed in poetry 1.3.2+dfsg-2
> Reply-To: Emmanuel Arias 
> Message-Id: 
> 

[---=| Quote block shrunk by t-prot: 82 lines snipped |=---]
> 
> python3-poetry suggests no packages.
> 
> -- no debconf information
> 
> -- 
> Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net
> 
> Société Libre, Logiciel Libre http://www.april.org/adherer
> Parinux, logiciel libre à Paris : http://www.parinux.org


-- 
Vincent-Xavier JUMEL Id: 0xBC8C2BAB14ABB3F2 https://blog.thetys-retz.net

Société Libre, Logiciel Libre http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org

Bug#1027686: transition: rakudo

[Dominique Dumont]

On Sunday, 15 January 2023 15:21:55 CET Sebastian Ramacher wrote:
> > I've found where compiler-id is computed. I'm going patch rakudo in
> > experimental so that compiler-id depends only on source files and nqp
> > version. This patch will land in experimental.
> 
> Okay, please let me know once it's available in experimental.

Done with rakudo 2022.12-1~exp3

I've patched the compiler id to be a sha1 of "Debian-".

I've verified that compiler id is the same for the arch that are built.

Is it still time to trigger a transition to fix all raku modules ? (there's no 
impact outside of raku modules)

All the best.

Bug#1028980: asciidoctor: autopkgtest regression: test_should_dump_man_page_and_return_error_code_0_when_help_topic_is_manpage

[Paul Gevers]

Source: asciidoctor
Version: 2.0.18-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of asciidoctor the autopkgtest of asciidoctor fails 
in testing when that autopkgtest is run with the binary packages of 
asciidoctor from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
asciidoctorfrom testing2.0.18-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


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

Paul

[1] https://qa.debian.org/excuses.php?package=asciidoctor

https://ci.debian.net/data/autopkgtest/testing/amd64/a/asciidoctor/30387182/log.gz


┌──┐
│ Checking Rubygems dependency resolution on ruby3.1 
  │

└──┘

GEM_PATH= ruby3.1 -e gem\ \"asciidoctor\"

┌──┐
│ Run tests for ruby3.1 from debian/ruby-tests.rake 
  │

└──┘

RUBYLIB=. GEM_PATH= ruby3.1 -S rake -f debian/ruby-tests.rake
mv lib ./.gem2deb.lib
/usr/bin/ruby3.1 -w -I"lib:test" 
/usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb 
"test/api_test.rb" "test/attribute_list_test.rb" 
"test/attributes_test.rb" "test/blocks_test.rb" "test/converter_test.rb" 
"test/document_test.rb" "test/extensions_test.rb" "test/helpers_test.rb" 
"test/invoker_test.rb" "test/links_test.rb" "test/lists_test.rb" 
"test/logger_test.rb" "test/manpage_test.rb" "test/options_test.rb" 
"test/paragraphs_test.rb" "test/parser_test.rb" "test/paths_test.rb" 
"test/preamble_test.rb" "test/reader_test.rb" "test/sections_test.rb" 
"test/substitutions_test.rb" "test/syntax_highlighter_test.rb" 
"test/tables_test.rb" "test/text_test.rb" RUBY_GC_HEAP_FREE_SLOTS=75 
(default value: 4096)

RUBY_GC_HEAP_INIT_SLOTS=75 (default value: 1)
RUBY_GC_HEAP_GROWTH_FACTOR=2.00 (default value: 1.80)
RUBY_GC_HEAP_GROWTH_MAX_SLOTS=5 (default value: 0)
RUBY_GC_MALLOC_LIMIT=12800 (default value: 16777216)
RUBY_GC_OLDMALLOC_LIMIT=12800 (default value: 16777216)
/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.13.10/lib/nokogiri/version/info.rb:85: 
warning: possibly useless use of a variable in void context

Run options: --seed 42697

# Running:

Bug#1028979: php-horde-crypt-blowfish: (autopkgtest) needs update for php8.2: deprecation warnings on stderr

[Paul Gevers]

Source: php-horde-crypt-blowfish
Version: 1.1.4-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:php-defaults

Dear maintainer(s),

We are in the transition of replacing php8.1 with php8.2 [0]. With a 
recent upload of php-defaults the autopkgtest of 
php-horde-crypt-blowfish fails in testing when that autopkgtest is run 
with the binary packages of php-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


  passfail
php-defaults  from testing93
php-horde-crypt-blowfish  from testing1.1.4-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of php-defaults to 
testing [1]. https://www.php.net/ChangeLog-8.php lists the changes since 
7.4 and may help to identify what needs to be updated.


The test itself passes, but the autopkgtest fails because of deprecation 
warnings on stderr. Output on stderr makes autopkgtest fail by default, 
unless `allow-stderr` is added to the set of restrictions. As a flood of 
deprecation warnings in server logs may be very unwanted, I'm not saying 
that adding the restriction to autopkgtest is the right answer to this 
issue, but because of the php transition, it needs to be resolved one 
way or the other.


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

Paul

[0] https://bugs.debian.org/1014460
[1] https://qa.debian.org/excuses.php?package=php-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-horde-crypt-blowfish/30399803/log.gz

.PHP Deprecated:  Creation of dynamic property Horde_Crypt_Blowfish::$iv 
is deprecated in 
/tmp/autopkgtest-lxc.gq123uii/downtmp/build.QXD/src/Horde_Crypt_Blowfish-1.1.4/lib/Horde/Crypt/Blowfish.php 
on line 173
.PHP Deprecated:  Creation of dynamic property Horde_Crypt_Blowfish::$iv 
is deprecated in 
/tmp/autopkgtest-lxc.gq123uii/downtmp/build.QXD/src/Horde_Crypt_Blowfish-1.1.4/lib/Horde/Crypt/Blowfish.php 
on line 173
.PHP Deprecated:  Creation of dynamic property Horde_Crypt_Blowfish::$iv 
is deprecated in 
/tmp/autopkgtest-lxc.gq123uii/downtmp/build.QXD/src/Horde_Crypt_Blowfish-1.1.4/lib/Horde/Crypt/Blowfish.php 
on line 173
.PHP Deprecated:  Creation of dynamic property Horde_Crypt_Blowfish::$iv 
is deprecated in 
/tmp/autopkgtest-lxc.gq123uii/downtmp/build.QXD/src/Horde_Crypt_Blowfish-1.1.4/lib/Horde/Crypt/Blowfish.php 
on line 173
.PHP Deprecated:  Creation of dynamic property Horde_Crypt_Blowfish::$iv 
is deprecated in 
/tmp/autopkgtest-lxc.gq123uii/downtmp/build.QXD/src/Horde_Crypt_Blowfish-1.1.4/lib/Horde/Crypt/Blowfish.php 
on line 173
.PHP Deprecated:  Creation of dynamic property Horde_Crypt_Blowfish::$iv 
is deprecated in 
/tmp/autopkgtest-lxc.gq123uii/downtmp/build.QXD/src/Horde_Crypt_Blowfish-1.1.4/lib/Horde/Crypt/Blowfish.php 
on line 173

.  156 / 156 (100%)

Time: 00:00.392, Memory: 6.00 MB

There were 74 skipped tests:

[...]

OK, but incomplete, skipped, or risky tests!
Tests: 156, Assertions: 177, Skipped: 74.
autopkgtest [07:16:53]: test phpunit



OpenPGP_signature
Description: OpenPGP digital signature

Bug#869510: dhtnode: please handle connection problems gracefully

[Aaron M. Ucko]

Petter Reinholdtsen  writes:

> I guess someone should test and figure out what the status is.  The
> latest opendht is in Debian unstable and testing now.

As of 2.4.10-1, it no longer floods logs, but it doesn't seem to have
found anything either:

  $ dhtnode
  OpenDHT node [...] running on port [...]
   (type 'h' or 'help' for a list of possible commands)
  
  >> ll
  OpenDHT node [...] running on port [...]
  >> 1 ongoing operations
  Storage has 0 values, using 0 KB
  IPv4 stats:
  Known nodes: 0 good, 0 dubious, 0 incoming.
  0 searches, 0 total cached nodes
  
  IPv6 stats:
  Known nodes: 0 good, 0 dubious, 0 incoming.
  0 searches, 0 total cached nodes

Meanwhile, all I see in the log is

  dhtnode[...]: Bootstrap: bootstrap.ring.cx

Thanks for asking!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1028558: mathomatic: bad Homepage URL

[tony mancill]

On Thu, Jan 12, 2023 at 07:22:50PM +0100, Jakub Wilk wrote:
> Source: mathomatic
> Version: 16.0.5-4
> 
> Apparently mathomatic.org has been repurposed for something unrelated to
> this software. Maybe use https://launchpad.net/mathomatic instead?
> 
> Upstream bug report:
> https://bugs.launchpad.net/mathomatic/+bug/2002656

Hi Jakub,

Thank you for detecting this and taking time to file a bug report.  The
launchpad.net page is a good suggestion, although I noted that it also
links back to mathomatic.org a few times, so we can improve that as
well.  There are several forks on Github, including
https://github.com/mathomatic/mathomatic, but I don't see any recent
activity there.

Regards,
tony

Bug#1028654: dpkg: add loongarch64 architecture GNU triplet

[Guillem Jover]

On Sat, 2023-01-14 at 18:29:12 +0800, 张丹丹 wrote:
> Package: dpkg
> Version: 1.21.17
> Severity: wishlist
> Tags: patch
> User: debian-de...@lists.debian.org
> Usertags: loongarch64
 
> - I have added loongarch64 architecture GNU triplet to match the change in 
> gcc-12.
> This patch can fix problems when cross-building and ensure gcc and dpkg use 
> matched combination.
> Please consider the patch attached. (Reference from rabenda...@gmail.com)

Hmm, why was the triplet changed? I mean it's not been too long since
it got added into dpkg, and supposedly backwards compatibility should
not be much of an issue (?), but why is this really necessary?

What does the unqualified triplet stand for now, which is supposed to
be considered the baseline?

> - The change of gcc-12 for loongarch64, please see the bleow BugID request:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027278 

> - Are there any missing? Please tell me.

See above. Also the patch (if it ends up being really necessary) does
not look entirely correct, the entries should be placed before the
more general match. Attached the modified one which now also passes
the test suite («make check»).

Thanks,
Guillem
diff --git i/data/ostable w/data/ostable
index 7fd2bff08..c1f9d7a7c 100644
--- i/data/ostable
+++ w/data/ostable
@@ -24,6 +24,7 @@ eabihf-gnu-linux	linux-gnueabihf		linux[^-]*-gnueabihf
 eabi-gnu-linux		linux-gnueabi		linux[^-]*-gnueabi
 abin32-gnu-linux	linux-gnuabin32		linux[^-]*-gnuabin32
 abi64-gnu-linux		linux-gnuabi64		linux[^-]*-gnuabi64
+f64-gnu-linux		linux-gnuf64		linux[^-]*-gnuf64
 spe-gnu-linux		linux-gnuspe		linux[^-]*-gnuspe
 x32-gnu-linux		linux-gnux32		linux[^-]*-gnux32
 ilp32-gnu-linux		linux-gnu_ilp32		linux[^-]*-gnu_ilp32
diff --git i/data/tupletable w/data/tupletable
index a7a878f5b..06d2c4e7f 100644
--- i/data/tupletable
+++ w/data/tupletable
@@ -27,6 +27,7 @@ base-musl-linux-		musl-linux-
 ilp32-gnu-linux-arm64		arm64ilp32
 eabihf-gnu-linux-arm		armhf
 eabi-gnu-linux-arm		armel
+f64-gnu-linux-loong64		loong64
 abin32-gnu-linux-mips64r6el	mipsn32r6el
 abin32-gnu-linux-mips64r6	mipsn32r6
 abin32-gnu-linux-mips64el	mipsn32el
diff --git i/scripts/t/Dpkg_Arch.t w/scripts/t/Dpkg_Arch.t
index 59855dfa4..f9e080f4e 100644
--- i/scripts/t/Dpkg_Arch.t
+++ w/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 18900;
+use Test::More tests => 18907;
 
 use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
 debarch_eq debarch_is debarch_is_wildcard

Bug#958676: closed by Debian FTP Masters (reply to Ying-Chun Liu (PaulLiu) ) (Bug#958676: fixed in xsystem35 1.7.3-pre5-9)

[Helmut Grohne]

Control: reopen -1

Hi,

On Mon, Dec 26, 2022 at 03:12:04PM +, Debian Bug Tracking System wrote:
> #958676: xsystem35 FTCBFS: broken embedded copy of AM_PATH_GLIB_2_0

I can see that you uploaded the package with a changelog saying that you
dropped it. Unfortunately, there still is a copy left and it still is
being used. Please try again.

Helmut

Bug#1028978: libomxil-bellagio FTBFS on mipsel: error: ‘__builtin_strncpy’ destination unchanged after copying no bytes [-Werror=stringop-truncation]

[Helmut Grohne]

Source: libomxil-bellagio
Version: 0.9.3-7
Severity: serious
Tags: ftbfs

Hi,

libomxil-bellagio fails to build form source when built on mipsel. A
build ends as follows:

| gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 
-DOMXILCOMPONENTSPATH=\"/usr/lib/mipsel-linux-gnu/libomxil-bellagio0/\" 
-I../include -g -O2 -ffile-prefix-map=/root/libomxil-bellagio-0.9.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror 
-DCONFIG_DEBUG_LEVEL=0 -c -o omxregister_bellagio-omxregister.o `test -f 
'omxregister.c' || echo './'`omxregister.c
| In file included from /usr/include/string.h:535,
|  from omxregister.c:42:
| In function ‘strncpy’,
| inlined from ‘showComponentsList’ at omxregister.c:110:3,
| inlined from ‘main’ at omxregister.c:454:9:
| /usr/include/mipsel-linux-gnu/bits/string_fortified.h:95:10: error: 
‘__builtin_strncpy’ destination unchanged after copying no bytes 
[-Werror=stringop-truncation]
|95 |   return __builtin___strncpy_chk (__dest, __src, __len,
|   |  ^~
|96 |   __glibc_objsize (__dest));
|   |   ~
| cc1: all warnings being treated as errors
| make[4]: *** [Makefile:719: omxregister_bellagio-omxregister.o] Error 1
| make[4]: Leaving directory '/root/libomxil-bellagio-0.9.3/src'
| make[3]: *** [Makefile:776: all-recursive] Error 1
| make[3]: Leaving directory '/root/libomxil-bellagio-0.9.3/src'
| make[2]: *** [Makefile:495: all-recursive] Error 1
| make[2]: Leaving directory '/root/libomxil-bellagio-0.9.3'
| make[1]: *** [Makefile:381: all] Error 2
| make[1]: Leaving directory '/root/libomxil-bellagio-0.9.3'
| dh_auto_build: error: make -j1 returned exit code 2
| make: *** [debian/rules:9: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

If you look at https://crossqa.debian.net/src/libomxil-bellagio, you can
guess that this is not entirely mipsel-specific, but probably also a
FTBFS on ppc64el and s390x. That said, I have only reproduced it on
mipsel and thus am filing it on mipsel.

A native build on amd64 succeeds.

I also briefly looked into it and couldn' really make sense of why gcc
thinks that the len parameter would become 0 here. Maybe someone else
figures?

Helmut

Bug#1028977: mmdebstrap --include incorrectly splits apt patterns containing comma

[Helmut Grohne]

Package: mmdebstrap
Version: 1.2.5-1
File: /usr/bin/mmdebstrap
Tags: patch upstream

Hi Johannes,

we recently talked about mmdebstrap --include with an apt pattern
containing a comma being broken. An example invocation is:

mmdebstrap --variant=apt 
'--include=?or(?exact-name(linux-image-cloud-amd64),?exact-name(linux-image-amd64))'
 unstable

I figured that I could also come up with the fixing patch and am
attaching it to your convenience. If you want to include test cases,
please keep in mind that this is fixed twice, once for --variant=extract
and once for --variant=apt.

Helmut
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -2343,14 +2343,18 @@
 }
 my @apt_argv = ('install');
 for my $incl (@{ $options->{include} }) {
-for my $pkg (split /[,\s]+/, $incl) {
-# strip leading and trailing whitespace
-$pkg =~ s/^\s+|\s+$//g;
-# skip if the remainder is an empty string
-if ($pkg eq '') {
-next;
+if ($incl =~ /^[?~!(]/) {
+push @apt_argv, $incl;
+} else {
+for my $pkg (split /[,\s]+/, $incl) {
+# strip leading and trailing whitespace
+$pkg =~ s/^\s+|\s+$//g;
+# skip if the remainder is an empty string
+if ($pkg eq '') {
+next;
+}
+push @apt_argv, $pkg;
 }
-push @apt_argv, $pkg;
 }
 }
 
@@ -2882,14 +2886,18 @@
 
 my %pkgs_to_install;
 for my $incl (@{ $options->{include} }) {
-for my $pkg (split /[,\s]+/, $incl) {
-# strip leading and trailing whitespace
-$pkg =~ s/^\s+|\s+$//g;
-# skip if the remainder is an empty string
-if ($pkg eq '') {
-next;
+if ($incl =~ /^[?~!(]/) {
+$pkgs_to_install{$incl} = ();
+} else {
+for my $pkg (split /[,\s]+/, $incl) {
+# strip leading and trailing whitespace
+$pkg =~ s/^\s+|\s+$//g;
+# skip if the remainder is an empty string
+if ($pkg eq '') {
+next;
+}
+$pkgs_to_install{$pkg} = ();
 }
-$pkgs_to_install{$pkg} = ();
 }
 }
 if ($options->{variant} eq 'buildd') {

Bug#1028976: php-imagick: autopkgtest needs update for new version of php-defaults

[Paul Gevers]

Source: php-imagick
Version: 3.7.0-3
Severity: serious
X-Debbugs-CC: php-defau...@packages.debian.org
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:php-defaults

Dear maintainer(s),

With a recent upload of php-defaults the autopkgtest of php-imagick 
fails in testing when that autopkgtest is run with the binary packages 
of php-defaults from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
php-defaults   from testing93
php-imagickfrom testing3.7.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of php-defaults to 
testing [1]. Of course, php-defaults shouldn't just break your 
autopkgtest (or even worse, your package), but it seems to me that the 
change in php-defaults was intended and your package needs to update to 
the new situation.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from php-defaults should 
really add a versioned Breaks on the unfixed version of (one of your) 
package(s). Note: the Breaks is nice even if the issue is only in the 
autopkgtest as it helps the migration software to figure out the right 
versions to combine in the tests.


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

Paul

[1] https://qa.debian.org/excuses.php?package=php-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/php-imagick/30392957/log.gz

There was 1 failure:

1) 
/tmp/autopkgtest-lxc.0guk5e6e/downtmp/build.IKf/src/imagick-3.7.0/tests/243_Tutorial_svgExample_basic.phpt

Failed asserting that string matches format description.
--- Expected
+++ Actual
@@ @@
-Ok
+Fatal error: Uncaught ImagickException: no decode delegate for this 
image format `SVG' @ error/blob.c/BlobToImage/363 in Standard input code:43

+Stack trace:
+#0 Standard input code(43): Imagick->readImageBlob()
+#1 Standard input code(49): svgExample()
+#2 {main}
+  thrown in Standard input code on line 43

/tmp/autopkgtest-lxc.0guk5e6e/downtmp/build.IKf/src/imagick-3.7.0/tests/243_Tutorial_svgExample_basic.phpt:58



OpenPGP_signature
Description: OpenPGP digital signature