Bug#1055527: [Debian-med-packaging] Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable

[Étienne Mollier]

Étienne Mollier, on 2023-11-07:
> Étienne Mollier, on 2023-11-07:
> >   I'm also tempted by the unversionned llvm
> > packages so these kind of version bumps do not go overlooked in
> > the future, but need to check why the specific version was
> > applied in the first place.
> 
> According to commit 4be8e58e4d07bde442b5b118318e8dc2e1ac80c8,
> the versionning originated from a need to bump ahead of the
> default at llvm-9 to get simde intrinsics support.  It thus
> looks now suitable to drop the versionning.

… if it weren't for packages, like the mlir, which have only
versioned packages.  I push dependency on llvm 17.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Odd Dimension - Far From Desire


signature.asc
Description: PGP signature

Bug#1055563: pycdio ftbfs with Python 3.12

[Matthias Klose]

Package: src:pycdio
Version: 2.1.1-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12


[...]
   dh_auto_test -O--buildsystem=pybuild -O--builddirectory=build
dh_auto_test: warning: warning: pybuild does not support building out of 
source tree. In source building enforced.
I: pybuild base:310: cd 
/<>/.pybuild/cpython3_3.12_cdio/build; python3.12 -m nose 
-v test

Traceback (most recent call last):
  File "", line 189, in _run_module_as_main
  File "", line 148, in _get_module_details
  File "", line 112, in _get_module_details
  File "/usr/lib/python3/dist-packages/nose/__init__.py", line 1, in 


from nose.core import collector, main, run, run_exit, runmodule
  File "/usr/lib/python3/dist-packages/nose/core.py", line 12, in 
from nose.loader import defaultTestLoader
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 21, in 


from nose.importer import Importer, add_path, remove_path
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 12, in 


from imp import find_module, load_module, acquire_lock, release_lock
ModuleNotFoundError: No module named 'imp'
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=1: 
cd /<>/.pybuild/cpython3_3.12_cdio/build; python3.12 -m 
nose -v test



and then later fails with:

[...]
   dh_auto_test -O--buildsystem=pybuild -O--builddirectory=build
dh_auto_test: warning: warning: pybuild does not support building out of 
source tree. In source building enforced.
I: pybuild base:310: cd 
/home/packages/12/pycdio-2.1.1/.pybuild/cpython3_3.12_cdio/build; 
python3.12 -m nose -v test

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/result.py", line 14, in 


from unittest.runner import _TextTestResult
ImportError: cannot import name '_TextTestResult' from 'unittest.runner' 
(/usr/lib/python3.12/unittest/runner.py). Did you mean: 'TextTestResult'?


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 189, in _run_module_as_main
  File "", line 148, in _get_module_details
  File "", line 112, in _get_module_details
  File "/usr/lib/python3/dist-packages/nose/__init__.py", line 1, in 


from nose.core import collector, main, run, run_exit, runmodule
  File "/usr/lib/python3/dist-packages/nose/core.py", line 15, in 
from nose.result import TextTestResult
  File "/usr/lib/python3/dist-packages/nose/result.py", line 16, in 


from unittest import _TextTestResult
ImportError: cannot import name '_TextTestResult' from 'unittest' 
(/usr/lib/python3.12/unittest/__init__.py). Did you mean: 'TextTestResult'?
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=1: 
cd /home/packages/12/pycdio-2.1.1/.pybuild/cpython3_3.12_cdio/build; 
python3.12 -m nose -v test

Bug#1055562: RM: libpam-elogind-compat/experimental -- ROM; Not required anymore.

[Mark Hindley]

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

Hello,

Please remove src:libpam-elogind-compat from experimental. It has served its
purpose and is no longer required now the virtual packages default-logind and
logind are used in all Depends.

Thanks

Mark

Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"

[Gregor Riepl]

Hi Dave,


Since it's just a warning, I wouldn't touch it. Stable updates are
possible, but need poking the stable release managers who have more
interesting problems to fix.


In that case, I recommend comparing the list of files and removing 
what's not needed:


https://packages.debian.org/bookworm/all/python3-charon/filelist
->
https://packages.debian.org/trixie/all/python3-charon/filelist

You can basically delete /lib/systemd/system/charon.service and 
/usr/share/dbus-1/system.d/nl.ultimaker.charon.conf on your system to 
get rid of the warning.


It's not a persistent change, but it's unlikely that there will be an 
update to the package in stable.


Regards,
Gregor

Bug#1055237: does not conform to the standards for library packaging

[Andrius Merkys]

Hello,

On Thu, 02 Nov 2023 18:10:19 +0100 Pierre Gruet  wrote:

Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the binary packages
do not follow the layout for libraries that is described in Policy Section 8.
For instance I think we should provide a shared library and if there are enough
reasons not to do so (see Policy 8.3), at least the binary package name should
be changed to libcatch2-dev.

Also this is not a header-only library anymore, the description of the package
should be changed.


I agree, binary package could be renamed and descriptions should be 
adapted as well. I am not sure about shared library, though.


First, upstream uses full source package version for soversion. This 
means a transition for even a patch level upstream release. I maintain a 
couple of packages like this and it is tiring.


Second, I do not expect any real binary package depending on catch2 
shared library as only test objects are linked with it. But I may be 
wrong here.



As a side note, the upload of the major version 3.x came out with many breaking
interface changes giving rise to RC bugs in e.g. genomicsdb, netgen, spdlog,
therion just to name a few, also to failing autopkgtests in many rdeps. I would
have been more comfortable with such a huge version change being advertised and
more prepared, with some kind of a library transition process for instance.


Right. Such changes should be announced beforehand since catch2 is used 
widely in the archive. Transition would have been nice indeed.



In any case, thanks for your work on catch2,


Seconded - thanks for maintaining this package.

Best wishes,
Andrius

Bug#1055561: pyodbc ftbfs with Python 3.12

[Matthias Klose]

Package: src:pyodbc
Version: 4.0.39-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

[...]
I: pybuild base:310: python3.12 -m build --skip-dependency-check 
--no-isolation --wheel --outdir 
/<>/.pybuild/cpython3_3.12_pyodbc

* Building wheel...
/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py:265: 
UserWarning: Unknown distribution option: 'include_package_files'

  warnings.warn(msg)
WARNING: '' not a valid package name; please use only .-separated 
package names in setup.py

running bdist_wheel
running build
running build_py
creating build
creating build/lib.linux-x86_64-cpython-312
copying src/pyodbc.pyi -> build/lib.linux-x86_64-cpython-312
running build_ext
building 'pyodbc' extension
creating build/temp.linux-x86_64-cpython-312
creating build/temp.linux-x86_64-cpython-312/src
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 
-Wall -g -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/pyodbc-4.0.39-1build1 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=4.0.39 
-I/usr/include/python3.12 -c src/buffer.cpp -o 
build/temp.linux-x86_64-cpython-312/src/buffer.o -Wno-write-strings

In file included from src/pyodbc.h:172,
 from src/buffer.cpp:12:
src/pyodbccompat.h: In function ‘PyObject* Text_New(Py_ssize_t)’:
src/pyodbccompat.h:75:12: error: ‘PyUnicode_FromUnicode’ was not 
declared in this scope; did you mean ‘PyUnicode_FromString’?

   75 | return PyUnicode_FromUnicode(0, length);
  |^
  |PyUnicode_FromString
src/pyodbccompat.h: In function ‘Py_UNICODE* Text_Buffer(PyObject*)’:
src/pyodbccompat.h:86:12: error: ‘PyUnicode_AS_UNICODE’ was not declared 
in this scope; did you mean ‘PyUnicode_AsUCS4’?

   86 | return PyUnicode_AS_UNICODE(o);
  |^~~~
  |PyUnicode_AsUCS4
src/pyodbccompat.h: In function ‘Py_ssize_t Text_Size(PyObject*)’:
src/pyodbccompat.h:126:40: error: ‘PyUnicode_GET_SIZE’ was not declared 
in this scope; did you mean ‘PyDict_GET_SIZE’?

  126 | return (o && PyUnicode_Check(o)) ? PyUnicode_GET_SIZE(o) : 0;
  |^~
  |PyDict_GET_SIZE
src/pyodbccompat.h: In function ‘Py_ssize_t 
TextCopyToUnicode(Py_UNICODE*, PyObject*)’:
src/pyodbccompat.h:146:26: error: ‘PyUnicode_GET_SIZE’ was not declared 
in this scope; did you mean ‘PyDict_GET_SIZE’?

  146 | Py_ssize_t cch = PyUnicode_GET_SIZE(o);
  |  ^~
  |  PyDict_GET_SIZE
src/pyodbccompat.h:147:24: error: ‘PyUnicode_AS_UNICODE’ was not 
declared in this scope; did you mean ‘PyUnicode_AsUCS4’?
  147 | memcpy(buffer, PyUnicode_AS_UNICODE(o), cch * 
sizeof(Py_UNICODE));

  |^~~~
  |PyUnicode_AsUCS4
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1

ERROR Backend subprocess exited when trying to invoke build_wheel
E: pybuild pybuild:395: build: plugin pyproject failed with: exit 
code=1: python3.12 -m build --skip-dependency-check --no-isolation 
--wheel --outdir /<>/.pybuild/cpython3_3.12_pyodbc

Bug#1055560: pysmbc ftbfs with Python 3.12

[Matthias Klose]

Package: src:pysmbc
Version: 1.0.23-2
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

[...]
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:310: cd 
/<>/.pybuild/cpython3_3.12_smbc/build; python3.12 -m 
unittest discover -v

smbc (unittest.loader._FailedTest.smbc) ... ERROR
tests.test_auth (unittest.loader._FailedTest.tests.test_auth) ... ERROR

==
ERROR: smbc (unittest.loader._FailedTest.smbc)
--
ImportError: Failed to import test module: smbc
Traceback (most recent call last):
  File "/usr/lib/python3.12/unittest/loader.py", line 415, in 
_find_test_path

package = self._get_module_from_name(name)
  
  File "/usr/lib/python3.12/unittest/loader.py", line 325, in 
_get_module_from_name

__import__(name)
  File 
"/<>/.pybuild/cpython3_3.12_smbc/build/smbc/__init__.py", 
line 2, in 

from _smbc import *
ImportError: 
/<>/.pybuild/cpython3_3.12_smbc/build/_smbc.cpython-312-x86_64-linux-gnu.so: 
undefined symbol: PyUnicode_GET_SIZE



==
ERROR: tests.test_auth (unittest.loader._FailedTest.tests.test_auth)
--
ImportError: Failed to import test module: tests.test_auth
Traceback (most recent call last):
  File "/usr/lib/python3.12/unittest/loader.py", line 382, in 
_find_test_path

module = self._get_module_from_name(name)
 
  File "/usr/lib/python3.12/unittest/loader.py", line 325, in 
_get_module_from_name

__import__(name)
  File 
"/<>/.pybuild/cpython3_3.12_smbc/build/tests/test_auth.py", 
line 1, in 

import smbc
  File 
"/<>/.pybuild/cpython3_3.12_smbc/build/smbc/__init__.py", 
line 2, in 

from _smbc import *
ImportError: 
/<>/.pybuild/cpython3_3.12_smbc/build/_smbc.cpython-312-x86_64-linux-gnu.so: 
undefined symbol: PyUnicode_GET_SIZE



--
Ran 2 tests in 0.000s

FAILED (errors=2)
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=1: 
cd /<>/.pybuild/cpython3_3.12_smbc/build; python3.12 -m 
unittest discover -v

Bug#1055559: python3-ruff: Missing dependency on ruff

[Arto Jantunen]

Package: python3-ruff
Severity: serious
Version: 0.0.291+dfsg1-1
Control: block 1054205 by -1

The Python library is entirely useless without the binary, thus there
needs to be a strong dependency between them.

-- 
Arto Jantunen

Bug#1055558: python-gmpy2 ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-gmpy2
Version: 2.1.5-2
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-gmpy2 ftbfs with Python 3.12:

[...]
creating build
creating build/temp.linux-x86_64-cpython-312
creating build/temp.linux-x86_64-cpython-312/src
x86_64-linux-gnu-gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 
-Wall -g -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -g -fwrapv -O2 -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/python-gmpy2-2.1.5-2build1 
-Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I./src -I/usr/include/python3.12 
-c src/gmpy2.c -o build/temp.linux-x86_64-cpython-312/src/gmpy2.o -DSHARED=1

In file included from src/gmpy2.c:613:
src/gmpy2_convert_gmp.c: In function ‘GMPy_MPZ_From_PyIntOrLong’:
src/gmpy2_convert_gmp.c:64:48: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

   64 | mpz_set_si(result->z, -(sdigit)templong->ob_digit[0]);
  |^~
src/gmpy2_convert_gmp.c:70:39: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

   70 | mpz_set_si(result->z, templong->ob_digit[0]);
  |   ^~
src/gmpy2_convert_gmp.c:83:55: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
   83 | mpz_import(result->z, len, -1, 
sizeof(templong->ob_digit[0]), 0,

  |   ^~
src/gmpy2_convert_gmp.c:84:35: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
   84 |sizeof(templong->ob_digit[0])*8 - 
PyLong_SHIFT, templong->ob_digit);

  |   ^~
src/gmpy2_convert_gmp.c:84:76: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
   84 |sizeof(templong->ob_digit[0])*8 - 
PyLong_SHIFT, templong->ob_digit);
  | 
   ^~

src/gmpy2_convert_gmp.c: In function ‘mpz_set_PyIntOrLong’:
src/gmpy2_convert_gmp.c:110:40: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

  110 | mpz_set_si(z, -(sdigit)templong->ob_digit[0]);
  |^~
src/gmpy2_convert_gmp.c:116:31: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

  116 | mpz_set_si(z, templong->ob_digit[0]);
  |   ^~
src/gmpy2_convert_gmp.c:129:47: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

  129 | mpz_import(z, len, -1, sizeof(templong->ob_digit[0]), 0,
  |   ^~
src/gmpy2_convert_gmp.c:130:35: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
  130 |sizeof(templong->ob_digit[0])*8 - 
PyLong_SHIFT, templong->ob_digit);

  |   ^~
src/gmpy2_convert_gmp.c:130:76: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
  130 |sizeof(templong->ob_digit[0])*8 - 
PyLong_SHIFT, templong->ob_digit);
  | 
   ^~

src/gmpy2_convert_gmp.c: In function ‘GMPy_PyLong_From_MPZ’:
src/gmpy2_convert_gmp.c:203:22: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
  203 | mpz_export(result->ob_digit, , -1, 
sizeof(result->ob_digit[0]), 0,

  |  ^~
src/gmpy2_convert_gmp.c:203:59: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
  203 | mpz_export(result->ob_digit, , -1, 
sizeof(result->ob_digit[0]), 0,

  |   ^~
src/gmpy2_convert_gmp.c:204:29: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’
  204 |sizeof(result->ob_digit[0])*8 - PyLong_SHIFT, 
obj->z);

  | ^~
src/gmpy2_convert_gmp.c:207:15: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

  207 | result->ob_digit[0] = 0;
  |   ^~
src/gmpy2_convert_gmp.c:212:31: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

  212 | while ((size>0) && (result->ob_digit[size-1] == 0)) {
  |   ^~
src/gmpy2_convert_gmp.c: In function ‘GMPy_XMPZ_From_PyIntOrLong’:
src/gmpy2_convert_gmp.c:481:48: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no member named ‘ob_digit’

  481 | mpz_set_si(result->z, -(sdigit)templong->ob_digit[0]);
  |^~
src/gmpy2_convert_gmp.c:487:39: error: ‘PyLongObject’ {aka ‘struct 
_longobject’} has no 

Bug#1054853: node-katex: FTBFS: TypeError: Cannot read properties of undefined (reading '.cjs')

[Yadd]

Control: reassign -1 node-postcss-loader
Control: affects -1 node-katex
Control: found -1 7.3.3-1

It seems that node-postcss-loader 7.3.3 needs node-cosmiconfig 8 and "jiti".

Bug#1055556: RFS: diff-pdf-wx/0.5.1-1 [ITP] -- Simple tool for visually comparing two PDF files

[陈 晟祺]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "diff-pdf-wx":

* Package name : diff-pdf-wx
Version : 0.5.1-1
Upstream contact : vac...@slavik.io
* URL : https://vslavik.github.io/diff-pdf/
* License : GPL-2, LGPL-2.1+
* Vcs : https://salsa.debian.org/harry/diff-pdf-wx
Section : utils

The source builds the following binary packages:

diff-pdf-wx - Simple tool for visually comparing two PDF files

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

https://mentors.debian.net/package/diff-pdf-wx/

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/diff-pdf-wx/diff-pdf-wx_0.5.1-1.dsc

Changes for the initial release:

diff-pdf-wx (0.5.1-1) unstable; urgency=medium
.
* Initial packging for upstream version 0.5.1 (closes: #1055543).

You may also find my git repo at:

https://salsa.debian.org/harry/diff-pdf-wx

Regards,
-- 
Shengqi Chen

Bug#1055557: python-hiredis ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-hiredis
Version: 1.0.1-2
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

[...]
 debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:310: python3.12 setup.py clean
Traceback (most recent call last):
  File "/<>/setup.py", line 7, in 
import sys, imp, os, glob, io
ModuleNotFoundError: No module named 'imp'
E: pybuild pybuild:395: clean: plugin distutils failed with: exit 
code=1: python3.12 setup.py clean



and then later fails with:

[...]
==
ERROR: test_status_string (test.reader.ReaderTest.test_status_string)
--
Traceback (most recent call last):
  File "/home/packages/12/python-hiredis-1.0.1/test/reader.py", line 
123, in test_status_string

self.assertEquals(b"ok", self.reply())
^
AttributeError: 'ReaderTest' object has no attribute 'assertEquals'. Did 
you mean: 'assertEqual'?


==
ERROR: test_subclassable (test.reader.ReaderTest.test_subclassable)
--
Traceback (most recent call last):
  File "/home/packages/12/python-hiredis-1.0.1/test/reader.py", line 
219, in test_subclassable

self.assertEquals(b"ok", reader.gets())
^
AttributeError: 'ReaderTest' object has no attribute 'assertEquals'. Did 
you mean: 'assertEqual'?


--
Ran 44 tests in 0.025s

FAILED (errors=30)
E: pybuild pybuild:395: test: plugin custom failed with: exit code=1: 
BUILDDIR=/home/packages/12/python-hiredis-1.0.1/.pybuild/cpython3_3.12_hiredis/build 
python3.12 /home/packages/12/python-hiredis-1.0.1/test.py

Bug#1055555: python-jellyfish fails tests with Python 3.12

[Matthias Klose]

Package: src:python-jellyfish
Version: 0.8.9-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-jellyfish fails tests with Python 3.12

[...]
=== short test summary info 

FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-dixon-dicksonx-0.813]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-martha-marhta-0.961]

FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-dwayne-duane-0.84]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-William-Williams-0.975]
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c--foo-0] - 
TypeError:...
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-a-a-1] - 
TypeError: ...
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-abc-xyz-0] - 
TypeErr...
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c--a-0.96] - T...
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-orangutan-kumquat-orangutan 
kumquat-0.976]
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-jaz-jal-0.822] 
- Typ...
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-@-@@-0.85] - 
TypeErr...
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-0-0@-0.85] - 
TypeErr...
FAILED jellyfish/test.py::test_jaro_winkler_similarity[c-a-ab-0.85] - 
TypeErr...
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-012345-0123456-0.971]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-012abc-012abcd-0.971]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-012abc-013abcd-0.879]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity[c-a1bc-a1be-0.883] - T...
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-dixon-dicksonx-0.830]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-martha-marhta-0.971]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-dwayne-duane-0.869]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-William-Williams-0.980]
FAILED jellyfish/test.py::test_jaro_winkler_similarity_longtol[c--foo-0] 
- Ty...
FAILED jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-a-a-1] 
- Typ...

FAILED jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-abc-xyz-0]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c--a-0.96]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-orangutan-kumquat-orangutan 
kumquat-0.986]
FAILED 
jellyfish/test.py::test_jaro_winkler_similarity_longtol[c-1abcdefg-1abcdefh-0.96]
FAILED jellyfish/test.py::test_jaro_winkler_deprecation[python] - 
TypeError: ...
FAILED jellyfish/test.py::test_jaro_winkler_deprecation[c] - TypeError: 
str a...
FAILED jellyfish/test.py::test_jaro_distance_deprecation - TypeError: 
str arg...
FAILED jellyfish/test.py::test_jaro_similarity[c-dixon-dicksonx-0.767] - 
Type...
FAILED jellyfish/test.py::test_jaro_similarity[c-martha-marhta-0.944] - 
TypeE...
FAILED jellyfish/test.py::test_jaro_similarity[c-dwayne-duane-0.822] - 
TypeEr...
FAILED jellyfish/test.py::test_jaro_similarity[c-0\xf000-0\xf000-1] - 
TypeErr...
FAILED jellyfish/test.py::test_jaro_similarity[c-Sint-Pietersplein 6, 
9000 Gent-Test 10, 1010 Brussel-0.518]
FAILED jellyfish/test.py::test_hamming_distance[c---0] - TypeError: str 
argum...
FAILED jellyfish/test.py::test_hamming_distance[c--abc-3] - TypeError: 
str ar...
FAILED jellyfish/test.py::test_hamming_distance[c-abc-abc-0] - 
TypeError: str...
FAILED jellyfish/test.py::test_hamming_distance[c-acc-abc-1] - 
TypeError: str...
FAILED jellyfish/test.py::test_hamming_distance[c-abcd-abc-1] - 
TypeError: st...
FAILED jellyfish/test.py::test_hamming_distance[c-abc-abcd-1] - 
TypeError: st...

FAILED jellyfish/test.py::test_hamming_distance[c-testing-this is a test-13]
FAILED jellyfish/test.py::test_hamming_distance[c-Saturday-Sunday-7] - 
TypeEr...
FAILED jellyfish/test.py::test_levenshtein_distance[c---0] - TypeError: 
str a...
FAILED jellyfish/test.py::test_levenshtein_distance[c-abc--3] - 
TypeError: st...
FAILED jellyfish/test.py::test_levenshtein_distance[c--abc-3] - 
TypeError: st...
FAILED jellyfish/test.py::test_levenshtein_distance[c-bc-abc-1] - 
TypeError: ...
FAILED jellyfish/test.py::test_levenshtein_distance[c-kitten-sitting-3] 
- Typ...
FAILED jellyfish/test.py::test_levenshtein_distance[c-Saturday-Sunday-3] 
- Ty...
FAILED jellyfish/test.py::test_damerau_levenshtein_distance[c---0] - 
TypeErro...
FAILED jellyfish/test.py::test_damerau_levenshtein_distance[c-abc--3] - 
TypeE...
FAILED jellyfish/test.py::test_damerau_levenshtein_distance[c-bc-abc-1] 
- Typ...
FAILED 
jellyfish/test.py::test_damerau_levenshtein_distance[c-fuor-four-1] - ...
FAILED 
jellyfish/test.py::test_damerau_levenshtein_distance[c-abcd-acb-2] - T...
FAILED jellyfish/test.py::test_damerau_levenshtein_distance[c-cape sand 
recycling -edith ann graham-17]
FAILED 
jellyfish/test.py::test_damerau_levenshtein_distance[c-jellyifhs-jellyfish-2]
FAILED 

Bug#1055554: python-libais ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-libais
Version: 0.17+git.20190917.master.e464cf8-3
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

failing tests with Python 3.12:

[...]
==
ERROR: testMsg1 
(test.compatibility.gpsd_test.SingleMessageTestsTest.testMsg1)

--
Traceback (most recent call last):
  File "/<>/test/compatibility/gpsd_test.py", line 53, in 
testMsg1

self.assertDictContainsSubset(expected, mangled)
^
AttributeError: 'SingleMessageTestsTest' object has no attribute 
'assertDictContainsSubset'


==
ERROR: testMsg5LargeTypeAndCargo 
(test.compatibility.gpsd_test.SingleMessageTestsTest.testMsg5LargeTypeAndCargo)

--
Traceback (most recent call last):
  File "/<>/test/compatibility/gpsd_test.py", line 72, in 
testMsg5LargeTypeAndCargo

self.assertDictContainsSubset(expected, mangled)
^
AttributeError: 'SingleMessageTestsTest' object has no attribute 
'assertDictContainsSubset'


==
ERROR: testTimestamps 
(test.compatibility.gpsd_test.SingleMessageTestsTest.testTimestamps)

--
Traceback (most recent call last):
  File "/<>/test/compatibility/gpsd_test.py", line 92, in 
testTimestamps

self.assertDictContainsSubset(expected, mangled)
^
AttributeError: 'SingleMessageTestsTest' object has no attribute 
'assertDictContainsSubset'


==
ERROR: testDecodeUnknownMessage6 
(test.test_decode.Ais6Decoders.testDecodeUnknownMessage6)

--
Traceback (most recent call last):
  File "/<>/test/test_decode.py", line 36, in 
testDecodeUnknownMessage6

self.assertRaisesRegexp(ais.DecodeError, '6:669:11',
^^^
AttributeError: 'Ais6Decoders' object has no attribute 
'assertRaisesRegexp'. Did you mean: 'assertRaisesRegex'?


--
Ran 87 tests in 0.030s

FAILED (errors=4, skipped=2)
Test failed: 
error: Test failed: failures=0>
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=1: 
python3.12 setup.py test

Bug#1055553: python-lzo ftbfs with Python 3.12

[Matthias Klose]

Package: python-lzo
Version: 1.14-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

[...]
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:310: cd 
/<>/.pybuild/cpython3_3.12_lzo/build; python3.12 -m nose -v 
tests

Traceback (most recent call last):
  File "", line 189, in _run_module_as_main
  File "", line 148, in _get_module_details
  File "", line 112, in _get_module_details
  File "/usr/lib/python3/dist-packages/nose/__init__.py", line 1, in 


from nose.core import collector, main, run, run_exit, runmodule
  File "/usr/lib/python3/dist-packages/nose/core.py", line 12, in 
from nose.loader import defaultTestLoader
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 21, in 


from nose.importer import Importer, add_path, remove_path
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 12, in 


from imp import find_module, load_module, acquire_lock, release_lock
ModuleNotFoundError: No module named 'imp'


and then later fails with:

[...]
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:310: cd 
/home/packages/12/python-lzo-1.14/.pybuild/cpython3_3.12_lzo/build; 
python3.12 -m nose -v tests

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/result.py", line 14, in 


from unittest.runner import _TextTestResult
ImportError: cannot import name '_TextTestResult' from 'unittest.runner' 
(/usr/lib/python3.12/unittest/runner.py). Did you mean: 'TextTestResult'?


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 189, in _run_module_as_main
  File "", line 148, in _get_module_details
  File "", line 112, in _get_module_details
  File "/usr/lib/python3/dist-packages/nose/__init__.py", line 1, in 


from nose.core import collector, main, run, run_exit, runmodule
  File "/usr/lib/python3/dist-packages/nose/core.py", line 15, in 
from nose.result import TextTestResult
  File "/usr/lib/python3/dist-packages/nose/result.py", line 16, in 


from unittest import _TextTestResult
ImportError: cannot import name '_TextTestResult' from 'unittest' 
(/usr/lib/python3.12/unittest/__init__.py). Did you mean: 'TextTestResult'?
E: pybuild pybuild:395: test: plugin distutils failed with: exit code=1: 
cd /home/packages/12/python-lzo-1.14/.pybuild/cpython3_3.12_lzo/build; 
python3.12 -m nose -v tests

Bug#1055552: python-nss ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-nss
Version: 1.0.1-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-nss ftbfs with Python 3.12:

[...]
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:310: /usr/bin/python3.12 setup.py build
/<>/setup.py:42: SyntaxWarning: invalid escape sequence '\s'
  version_re = re.compile("^\s*__version__\s*=\s*['\"]([^'\"]*)['\"]")
/<>/setup.py:216: SyntaxWarning: invalid escape sequence '\.'
  """
/usr/lib/python3/dist-packages/setuptools/dist.py:744: 
SetuptoolsDeprecationWarning: Invalid dash-separated options

!!



Usage of dash-separated 'dist-dir' will not be supported in future
versions. Please use the underscore name 'dist_dir' instead.

This deprecation is overdue, please update your project and 
remove deprecated

calls to avoid build errors in the future.

See 
https://setuptools.pypa.io/en/latest/userguide/declarative_config.html 
for details.




!!
  opt = self.warn_dash_deprecation(opt, section)
src/py_nspr_error.c: In function ‘set_nspr_error’:
src/py_nspr_error.c:189:23: error: macro "va_start" requires 2 
arguments, but only 1 given

  189 | va_start(vargs);
  |   ^
In file included from /usr/include/python3.12/bytesobject.h:10,
 from /usr/include/python3.12/Python.h:50,
 from src/py_nspr_error.c:6:
/usr/lib/gcc/x86_64-linux-gnu/13/include/stdarg.h:50: note: macro 
"va_start" defined here

   50 | #define va_start(v,l)   __builtin_va_start(v,l)
  |
src/py_nspr_error.c:189:9: error: ‘va_start’ undeclared (first use in 
this function)

  189 | va_start(vargs);
  | ^~~~
src/py_nspr_error.c:189:9: note: each undeclared identifier is reported 
only once for each function it appears in

src/py_nspr_error.c: In function ‘set_cert_verify_error’:
src/py_nspr_error.c:225:23: error: macro "va_start" requires 2 
arguments, but only 1 given

  225 | va_start(vargs);
  |   ^
/usr/lib/gcc/x86_64-linux-gnu/13/include/stdarg.h:50: note: macro 
"va_start" defined here

   50 | #define va_start(v,l)   __builtin_va_start(v,l)
  |
src/py_nspr_error.c:225:9: error: ‘va_start’ undeclared (first use in 
this function)

  225 | va_start(vargs);
  | ^~~~
error: command '/usr/bin/x86_64-linux-gnu-gcc' failed with exit code 1
E: pybuild pybuild:395: build: plugin distutils failed with: exit 
code=1: /usr/bin/python3.12 setup.py build

Bug#961598: RFA: sqlcipher -- Command line interface for SQLCipher

[Petter Reinholdtsen]

Control: retitle -1 O: sqlcipher -- Command line interface for SQLCipher

No-one volunteered for three years, so I belive it is time to orphan this
package.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1055551: python-ptrace ftbfs with Python 3.12

[Matthias Klose]

Package: src:python-ptrace
Version: 0.9.8-0.1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

python-ptrace ftbfs with Python 3.12:

[...]
dh clean --with=python3 --buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/<>'
py3versions: no X-Python3-Version in control file, using supported versions
set -e;  python3.12  setup_cptrace.py clean;  python3.11 
setup_cptrace.py clean;

Traceback (most recent call last):
  File "/<>/setup_cptrace.py", line 50, in 
main()
  File "/<>/setup_cptrace.py", line 20, in main
from imp import load_source
ModuleNotFoundError: No module named 'imp'
make[1]: *** [debian/rules:13: override_dh_auto_clean] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:36: clean] Error 2

Bug#1055550: redland-bindings ftbfs with Python 3.12

[Matthias Klose]

Package: src:redland-bindings
Version: 1.0.17.1+dfsg-4
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12


[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory '/<>'
for python in python3.12 python3.11; do \
/usr/bin/make -C $python check-local PYTHON=$python || exit ; \
done
make[2]: Entering directory '/<>/python3.12'
PYTHONPATH=. \
  python3.12 ./redlandtest.py
Traceback (most recent call last):
  File "/<>/python3.12/./redlandtest.py", line 10, in 
from RDF import *
  File "/<>/python3.12/RDF.py", line 126, in 
import Redland
  File "/<>/python3.12/Redland.py", line 26, in 
_Redland = swig_import_helper()
   
  File "/<>/python3.12/Redland.py", line 13, in 
swig_import_helper

import imp
ModuleNotFoundError: No module named 'imp'
make[2]: *** [Makefile:785: unittest-python] Error 1
make[2]: Leaving directory '/<>/python3.12'


Fixing the imp import, the build fails later with:

[...]
   debian/rules override_dh_auto_test
make[1]: Entering directory 
'/home/packages/12/redland-bindings-1.0.17.1+dfsg'

for python in python3.12 python3.11; do \
/usr/bin/make -C $python check-local PYTHON=$python || exit ; \
done
make[2]: Entering directory 
'/home/packages/12/redland-bindings-1.0.17.1+dfsg/python3.12'

PYTHONPATH=. \
  python3.12 ./redlandtest.py
Traceback (most recent call last):
  File 
"/home/packages/12/redland-bindings-1.0.17.1+dfsg/python3.12/./redlandtest.py", 
line 10, in 

from RDF import *
  File 
"/home/packages/12/redland-bindings-1.0.17.1+dfsg/python3.12/RDF.py", 
line 126, in 

import Redland
  File 
"/home/packages/12/redland-bindings-1.0.17.1+dfsg/python3.12/Redland.py", 
line 26, in 

_Redland = swig_import_helper()
   
  File 
"/home/packages/12/redland-bindings-1.0.17.1+dfsg/python3.12/Redland.py", 
line 22, in swig_import_helper

_mod = imp.load_module('_Redland', fp, pathname, description)
   ^^
  File "/usr/lib/python3/dist-packages/zombie_imp/imp_3_11.py", line 
246, in load_module

return load_dynamic(name, filename, file)
   ^^
  File "/usr/lib/python3/dist-packages/zombie_imp/imp_3_11.py", line 
346, in load_dynamic

return _load(spec)
   ^^^
ImportError: 
/home/packages/12/redland-bindings-1.0.17.1+dfsg/python3.12/_Redland.cpython-312-x86_64-linux-gnu.so: 
undefined symbol: PyUnicode_AS_DATA

make[2]: *** [Makefile:785: unittest-python] Error 1

Bug#1055548: gawk: new upstream version (5.3.0) (new features)

[Salvatore Bonaccorso]

Source: gawk
Version: 1:5.2.1-2
Severity: wishlist
X-Debbugs-Cc: car...@debian.org

Hi Adrian,

If your time allows it, can you package gawk/5.3.0 for unstable?
According to the announce:

Changes from 5.2.x to 5.3.0
---

1. Infrastructure changes: Removed the use of libsigsegv. The
   value-add was never very much and it caused problems in some
   environments.

2. In keeping with new features in BWK awk, gawk now has built-in
   CSV file parsing. The behavior is intended to be identical to
   that of the "One True AWK" when --csv is applied. See the
   manual for details.

3. Also in keeping with BWK awk, gawk now supports a new \u escape
   sequence. This should be followed by 1-8 hexadecimal digits. The
   given code point is converted to its corresponding multibyte encoding
   for storage inside gawk. See the manual.

4. If PROCINFO["BUFFERPIPE"] exists, then pipe output is buffered.
   You can also use PROCINFO["command", "BUFFERPIPE"]. See the manual
   for details.

5. Because of the additional `do_csv' variable in the API, which breaks
   binary compatibility, the API major version was updated to 4 and
   the minor version was reset to zero.  The API remains source code
   compatible; that is, existing extensions should only require recompilation.

6. The manual now requires Texinfo 7.1 and its texinfo.tex for formatting.
   As a result, we no longer need to pre-process it, removing the need
   for gawktexi.in and leaving just gawk.texi.

7. And of course, there have been several minor code cleanups and bug fixes.
   See the ChangeLog for details.

Changes from 5.2.2 to 5.2.x
---

1. The readdir extension has been updated with additonal code and
   features, see the manual or its man page. As a result, the
   readdir_test.c extension has been removed.

2. We have a new translation: Ukranian.

3. Several subtle issues related to null regexp matches around
   multibyte characters have been fixed.

Regards,
Salvatore

Bug#1055549: protobuf ftbfs with Python 3.12

[Matthias Klose]

Package: src:protobuf
Version: 3.21.12-7
Severity: important
Tags: sid trixie patch
User: debian-pyt...@lists.debian.org
Usertags: python3.12

protobuf fails it's Python tests with Python 3.12, 3.12 dropped a 
deprecated feature.


Patch at
http://launchpadlibrarian.net/696708840/protobuf_3.21.12-7ubuntu2_3.21.12-7ubuntu3.diff.gz

Bug#1055547: urwid fails one test with Python 3.12

[Matthias Klose]

Package: src:urwid
Version: 2.1.2-4
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

[...]
==
ERROR: test_coroutine_error 
(urwid.tests.test_event_loops.AsyncioEventLoopTest.test_coroutine_error)

--
Traceback (most recent call last):
  File "/<>/urwid/tests/test_event_loops.py", line 211, in 
test_coroutine_error

asyncio.ensure_future(error_coro())
  File "/usr/lib/python3.12/asyncio/tasks.py", line 679, in ensure_future
raise TypeError('An asyncio.Future, a coroutine or an awaitable '
TypeError: An asyncio.Future, a coroutine or an awaitable is required

--
Ran 278 tests in 1.378s

FAILED (errors=1)

Bug#1055546: swiglpk ftbfs with Python 3.12

[Matthias Klose]

Package: src:swiglpk
Version: 5.0.8-1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags python3.12


dh_auto_clean
I: pybuild base:310: python3.12 setup.py clean
/<>/versioneer.py:467: SyntaxWarning: invalid escape 
sequence '\s'

  LONG_VERSION_PY['git'] = '''
==
BUILDING SWIGLPK FROM SOURCE.
If you are installing SWIGLPK via pip, this means that no wheels are 
offered for your platform or Python version yet.

This can be the case if you adopt a new Python version early.
A source build requires GLPK, SWIG, and GMP (Linux/Mac) to be installed!
==
Looking for glpk.h...
Found glpk.h in /usr/include.
Making sure SWIG is available...
Found the swig executable.
Traceback (most recent call last):
  File "/<>/setup.py", line 176, in 
version=versioneer.get_version(),

  File "/<>/versioneer.py", line 1405, in get_version
return get_versions()["version"]
   ^^
  File "/<>/versioneer.py", line 1339, in get_versions
cfg = get_config_from_root(root)
  ^^
  File "/<>/versioneer.py", line 399, in get_config_from_root
parser = configparser.SafeConfigParser()
 ^
AttributeError: module 'configparser' has no attribute 
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
E: pybuild pybuild:395: clean: plugin distutils failed with: exit 
code=1: python3.12 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11" 
returned exit code 13

Bug#1055545: zfec ftbfs with Python 3.12

[Matthias Klose]

Package: src:zfec
Version: 1.5.2-2.1
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:310: python3.12 setup.py clean
/<>/versioneer.py:421: SyntaxWarning: invalid escape 
sequence '\s'

  LONG_VERSION_PY['git'] = '''
Traceback (most recent call last):
  File "/<>/setup.py", line 51, in 
version=versioneer.get_version(),

  File "/<>/versioneer.py", line 1480, in get_version
return get_versions()["version"]
   ^^
  File "/<>/versioneer.py", line 1412, in get_versions
cfg = get_config_from_root(root)
  ^^
  File "/<>/versioneer.py", line 342, in get_config_from_root
parser = configparser.SafeConfigParser()
 ^
AttributeError: module 'configparser' has no attribute 
'SafeConfigParser'. Did you mean: 'RawConfigParser'?
E: pybuild pybuild:395: clean: plugin distutils failed with: exit 
code=1: python3.12 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p "3.12 3.11" 
returned exit code 13

make: *** [debian/rules:7: clean] Error 25

Bug#1052521: debmake-doc: instructions for adding user to sbuild group have a bug and are (maybe) incomplete

[Osamu Aoki]

Hi,

Sent it too early.

On Wed, 2023-11-08 at 15:22 +0900, Osamu Aoki wrote:

Hi,

This is a good point to rethink description.
> On Sat, 2023-09-23 at 15:31 -0400, Jonathan Kamens wrote:
> > > > > Package: debmake-doc
> > > > > Version: 1.17-7
> > > > > Severity: minor
> > > > > 
> > > > > 1) Section 3.6 of the debmake doc says to run `adduser
> > > > > 
> > > > > sbuild` but there should be `sudo` at the beginning of that command.

Yes.

> But a new question is should I use `adduser`? It is not essential. Maybe it's
> time to start using distribution non-dependent `usermod` here.
> 
> > > > > 2) It also says "Logout and login to check you are a member of sbuild
> > > > > group using id command." I don't know how universal this is, but if a
> > > > > user has done `loginctl enable-linger` or has a user-level systemd
> > > > > daemon configured, logging out logging back in won't work; they still
> > > > > won't be in the group. They would need to either reboot or run `kill
> > > > > -TERM -1` (NOT as root) to make all of their processes die and thereby
> > > > > get the user-level systemd to restart. I know you're trying to keep
> > > > > the guide simple so you you may not want to get into the nitty-gritty
> > > > > details, but perhaps it is worth mentioning that if logging out and
> > > > > logging back in doesn't work the user should try restarting their
> > > > > computer.
> 
What I knew were
$ sudo usermod -aG sbuild USER
$ sudo shutdown -r now
-> This hard reboot from UEFI
or
$ sudo usermod -aG sbuild USER
$ killall systemd
-> This is soft reboot only systemd

I don't know the latter has any bad side effects. Otherwise this is quicker.


Your trick seem to be cleaner
$ sudo usermod -aG sbuild USER
$ kill TERM -TERM -1


Considering -TERM is -15, this may be redundant.  Do you need this?
Kill manpage has 
  kill -9 -1
 Kill all processes you can kill.
-9 is SIGKILL.


All these kill commands seem to work without going into hard reboot.

Osamu

Bug#1052521: debmake-doc: instructions for adding user to sbuild group have a bug and are (maybe) incomplete

[Osamu Aoki]

Hi,

This is a good point to rethink description.

On Sat, 2023-09-23 at 15:31 -0400, Jonathan Kamens wrote:
> > > > Package: debmake-doc
> > > > Version: 1.17-7
> > > > Severity: minor
> > > > 
> > > > 1) Section 3.6 of the debmake doc says to run `adduser 
> > > > sbuild` but there should be `sudo` at the beginning of that command.

Yes.

But a new question is should I use `adduser`? It is not essential. Maybe it's
time to start using distribution non-dependent `usermod` here.

> > > > 2) It also says "Logout and login to check you are a member of sbuild
> > > > group using id command." I don't know how universal this is, but if a
> > > > user has done `loginctl enable-linger` or has a user-level systemd
> > > > daemon configured, logging out logging back in won't work; they still
> > > > won't be in the group. They would need to either reboot or run `kill
> > > > -TERM -1` (NOT as root) to make all of their processes die and thereby
> > > > get the user-level systemd to restart. I know you're trying to keep
> > > > the guide simple so you you may not want to get into the nitty-gritty
> > > > details, but perhaps it is worth mentioning that if logging out and
> > > > logging back in doesn't work the user should try restarting their
> > > > computer.

What I knew were

$ sudo usermod -aG sbuild USER
$ sudo shutdown -r now

-> This hard reboot from UEFI

or

$ sudo usermod -aG sbuild USER
$ sudo killall systemd

-> This is soft reboot only systemd

I don't know the latter has any bad side effects. Otherwise this is quicker.


Your trick seem to be cleaner
$ sudo usermod -aG sbuild USER
$ kill TERM -TERM -1


Considering -TERM is -15, this may be redundant.  Do you need this?


Kill manpage has 
  kill -9 -1
 Kill all processes you can kill.

-9 is SIGKILL.

Bug#1055544: libgetdata hardcodes specific python versions in the packaging

[Matthias Klose]

Package: src:libgetdata
Version: 0.11-0-7
Severity: important
Tags: sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

libgetdata hardcodes specific python versions in the packaging, which it 
should not (seen when building with both 3.11 and 3.12 as supported 
Python version)


https://launchpadlibrarian.net/696569970/buildlog_ubuntu-noble-amd64.libgetdata_0.11.0-7build1_BUILDING.txt.gz

dh_missing: warning: 
usr/local/lib/python3.12/dist-packages/pygetdata.cpython-312-x86_64-linux-gnu.so 
exists in debian/tmp but is not installed to anywhere

dh_missing: error: missing files, aborting

$ cat debian/python3-pygetdata.install # 
usr/lib/python3*/site-packages/pygetdata*so

usr/local/lib/python3.11/dist-packages/*  /usr/lib/python3.11/site-packages

Bug#1055429: bind9: iproute2 change ripples through bind9 sysvinit script preventing start

[Bob Proulx]

Ansgar wrote:
> > On systems using sysvinit and not yet UsrMerged this snags a
> > problem in the sysvinit init script.  I know and understand that
> > this is not a combination that you or Debian is officially
> > supporting.  But it would help out interoperability if a one line
> > fix were applied and your kindness would be appreciated.
>
> This approach does not scale: it would require maintainers to continue
> to support split-usr and it will not work very well for shell
> interpreter lines like "#! /bin/bash" when the basy binary gets
> installed to /usr/bin/bash.

That is a straw man argument fallacy as you are trying to refute
something that was not in the original request.  I have not asked for
adding in a hard coded path.  I am asking to have a hard coded path
removed.  That's just good programming practice and should be valid on
any system.  It just happens to be in a shell script.  There was no
request to change anything about script #! interpreters.

> So to me it seems pretty useless to fix singular instances of this
> problem.

I tried to be as clear on the issue as possible that while I
understood that it was not a supported configuration that it would be
of a help if the removal of the hard coded path could occur.  The
removal of five characters from one line of the file.  It is a small
thing but it would help out.  Perhaps for the next time the package
has a normal release?

> It would probably be better for your distribution to fix this. Please
> file a bug with them.
>
> > -- System Information:
> > Debian Release: trixie/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable'), (500, 'testing')
> > Architecture: amd64 (x86_64)
>
> You said elsewhere that this was a bug coming from using a different
> distribution. Please talk to them so they make sure the system
> information says so when people are using it.

No.  I said this was on Debian systems without systemd and that have
not been UsrMerged.  I said that I realized this is not a supported
configuration.  I am a long time user of Debian and have quite a few
variously hacked installations.  Debian used to have the tag line that
it was The Universial Operating System.  We would joke that it would
run on toasters.  It runs on the space station for goodness sakes!
That was because it used to be a flexible system and these types of
local configuration modifications is what made Debian the best choice
for custom systems.

Bob

Bug#1055429: bind9: iproute2 change ripples through bind9 sysvinit script preventing start

[Diarrhea Mcgee]

On Mon, 06 Nov 2023 08:54:39 +0100 Ansgar wrote: > Hi Bob, > > I understand
you are not using Debian. Please indicate that if you file > bugs
encountered on other distributions. > > > On systems using sysvinit and not
yet UsrMerged this snags a problem > > in the sysvinit init script.  I know
and understand that this is not > a > > combination that you or Debian is
officially supporting.  But it > would > > help out interoperability if a
one line fix were applied and your > > kindness would be appreciated. > >
This approach does not scale: it would require maintainers to continue > to
support split-usr and it will not work very well for shell > interpreter
lines like "#! /bin/bash" when the basy binary gets > installed to
/usr/bin/bash. > > So to me it seems pretty useless to fix singular
instances of this > problem. > > It would probably be better for your
distribution to fix this. Please > file a bug with them. > > > -- System
Information: > > Debian Release: trixie/sid > >   APT prefers unstable >
>   APT policy: (500, 'unstable'), (500, 'testing') > > Architecture: amd64
(x86_64) > > You said elsewhere that this was a bug coming from using a
different > distribution. Please talk to them so they make sure the system
> information says so when people are using it. > > Ansgar >

why not /usr/bin/env bash
also its not a problem with the distribution if it doesnt do usrmerge

Bug#1055543: ITP: diff-pdf-wx -- Simple tool for visually comparing two PDF files.

[陈 晟祺]

Package: wnpp
Severity: wishlist
Owner: Shengqi Chen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: diff-pdf-wx
  Version : 0.5.1
  Upstream Contact: Vaclav Slavik 
* URL : http://vslavik.github.io/diff-pdf
* License : GPL-2 mostly with some LGPL-2.1+ files
  Programming Lang: C++
  Description : Simple tool for visually comparing two PDF files.

diff-pdf is a tool for visually comparing two PDFs.
It takes two PDF files as arguments, and generates an output PDF
file that highlights the differences between the two input files.
Besides, it can compare the two files visually in a simple GUI.

The original package name (and the executable name) is diff-pdf.
However there is an existing package called diffpdf, so I rename
it to diff-pdf-wx (for using wxwidgets) to avoid confusion.

Compare to diffpdf: Both two tools can compare PDF files in a
visual way. However this tool is more lightweight (by not
depending on Qt) and can generate the diff result in PDF format.
Thus it is widely adopted in academia to generate revised versions
of submitted manuscripts. Many conferences / journals recommend
this tool in their revision process. Also many LaTeX template authors 
use it to compare LaTeX-rendered PDFs to original Word version.

Currently Fedora / CentOS has officially packed this tool. I plan to
upload it to Debian and maintain this package as my first-time contribution.
My current work is at [1].
A DD as sponsor would be greatly appreciated.

[1]: https://salsa.debian.org/harry/diff-pdf-wx

Bug#1055542: cannot build go packages with golang-github-containers-image-dev

[Miao Wang]

Package: golang-github-containers-image-dev
Version: 5.28.0-3
Severity: normal

In 5.28.0-3 of golang-github-containers-image-dev, a patch is included to 
revert the upstream change updating x-exp-slices. However the package 
golang-golang-x-exp has been updated to 0.0~git20231006.7918f67-1 in debian 
recently, and as a result this package currently contains a function call which 
does not match the definition in golang-golang-x-exp and thus cannot be built.

I suggest the patch `revert-x-exp-slices.patch` should be accordingly removed.

Cheers,

Miao Wang

Bug#1055541: In Trixie, /etc/localtime incorrectly set to UTC in some cases due to the installer including mappings to removed legacy timezones

[Brandon Werner]

package: tzsetup

In bug #1040997 legacy symlinks were moved out of the tzdata package to 
tzdata-legacy. The "post-base-installer.d/05tzsetup" script does not set the 
/etc/localtime symlink because db_get is returning these legacy time zones that 
no longer exist in the tsdata package.

I think the fix is to modify the mappings in debian/common.templates.in to 
remove the legacy time zones and replace them with the versions shipped in the 
new version of tzdata.

Bug#1055540: obs-time-source: FTBFS on several archs: linker input file not found

[Joao Eriberto Mota Filho]

Package: obs-time-source
Version: 0.1-1
Severity: serious
Tags: upstream ftbfs
Justification: Fails to Build from Source
X-Debbugs-Cc: ~krystianch/public-in...@lists.sr.ht

The package fails to build from source on several architectures.

An example for arm64:

cd obj-aarch64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v
[1/2] cc -Itime-source.so.p -I. -I.. -I/usr/include/obs 
-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/aarch64-linux-gnu/glib-2.0/include -I/usr/include/harfbuzz 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo 
-I/usr/include/pixman-1 -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall 
-Winvalid-pch -Wextra -Wpedantic -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -mbranch-protection=standard -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -pthread -DHAVE_OBSCONFIG_H -DSIMDE_ENABLE_OPENMP 
'$<$,$>:-fopenmp-simd>'
 
'$<$,$>:-fopenmp-simd>'
 -MD -MQ time-source.so.p/time-source.c.o -MF 
time-source.so.p/time-source.c.o.d -o time-source.so.p/time-source.c.o -c 
../time-source.c
FAILED: time-source.so.p/time-source.c.o 
cc -Itime-source.so.p -I. -I.. -I/usr/include/obs -I/usr/include/pango-1.0 
-I/usr/include/glib-2.0 -I/usr/lib/aarch64-linux-gnu/glib-2.0/include 
-I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi 
-I/usr/include/cairo -I/usr/include/pixman-1 -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-mbranch-protection=standard -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-DHAVE_OBSCONFIG_H -DSIMDE_ENABLE_OPENMP 
'$<$,$>:-fopenmp-simd>'
 
'$<$,$>:-fopenmp-simd>'
 -MD -MQ time-source.so.p/time-source.c.o -MF 
time-source.so.p/time-source.c.o.d -o time-source.so.p/time-source.c.o -c 
../time-source.c
../time-source.c: In function ‘time_source_update’:
../time-source.c:95:9: warning: ‘__builtin_strncpy’ specified bound 64 equals 
destination size [-Wstringop-truncation]
   95 | strncpy(context->format, obs_data_get_string(settings, 
"format"),
  | ^
cc: warning: 
$<$,$>:-fopenmp-simd>:
 linker input file unused because linking not done
cc: error: 
$<$,$>:-fopenmp-simd>:
 linker input file not found: No such file or directory
cc: warning: 
$<$,$>:-fopenmp-simd>:
 linker input file unused because linking not done
cc: error: 
$<$,$>:-fopenmp-simd>:
 linker input file not found: No such file or directory
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-aarch64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v 
returned exit code 1
make: *** [debian/rules:13: binary-arch] Error 25

Eriberto



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

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

Versions of packages obs-time-source depends on:
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libglib2.0-0 2.74.6-2
ii  libobs0  29.0.2+dfsg-1+b1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  obs-studio   29.0.2+dfsg-1+b1

obs-time-source recommends no packages.

obs-time-source suggests no packages.

-- no debconf information

Bug#1055539: bookworm-pu: package opensc/0.23.0-0.3+deb12u1

[Bastian Germann]

Am 08.11.23 um 02:15 schrieb Bastian Germann:

   [x] attach debdiff against the package in (old)stable


diff -Nru opensc-0.23.0/debian/changelog opensc-0.23.0/debian/changelog
--- opensc-0.23.0/debian/changelog  2023-06-01 20:30:18.0 +
+++ opensc-0.23.0/debian/changelog  2023-11-08 00:26:46.0 +
@@ -1,3 +1,12 @@
+opensc (0.23.0-0.3+deb12u1) bookworm; urgency=medium
+
+  * Team upload
+  * Fix CVE-2023-4535 with two upstream patches (Closes: #1055520)
+  * Fix CVE-2023-40660 with upstream patch (Closes: #1055521)
+  * Fix CVE-2023-40661 with upstream patches (Closes: #1055522)
+
+ -- Bastian Germann   Wed, 08 Nov 2023 01:26:46 +0100
+
 opensc (0.23.0-0.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch 
opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch
--- opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch   1970-01-01 
00:00:00.0 +
+++ opensc-0.23.0/debian/patches/0006-CVE-2023-4535.patch   2023-11-08 
00:26:46.0 +
@@ -0,0 +1,54 @@
+Origin: 
https://github.com/OpenSC/OpenSC/commit/cde2e050ec4f2f1b7db38429aa4e9c0f4656308c
+From: Peter Popovec 
+Date: Wed, 26 Apr 2023 13:22:09 +0200
+Subject: NULL pointer fix
+
+Thanks to the clang analyzer:
+ Null pointer passed to 2nd parameter expecting 'nonnull'
+ [clang-analyzer-core.NonNullParamChecker]
+
+   modified:   src/libopensc/card-myeid.c
+---
+ src/libopensc/card-myeid.c | 15 ++-
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/src/libopensc/card-myeid.c b/src/libopensc/card-myeid.c
+index 31dd209f3e..951c179f1b 100644
+--- a/src/libopensc/card-myeid.c
 b/src/libopensc/card-myeid.c
+@@ -1973,6 +1973,9 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 *data, 
size_t datalen,
+   return_len = block_size - pad_byte;
+   }
+   *outlen = return_len;
++  /* application can request buffer size or actual buffer 
size is too small */
++  if (out == NULL)
++  LOG_FUNC_RETURN(ctx, SC_SUCCESS);
+   if (return_len > *outlen)
+   LOG_FUNC_RETURN(ctx, SC_ERROR_BUFFER_TOO_SMALL);
+   memcpy(out, priv->sym_plain_buffer, return_len);
+@@ -2042,10 +2045,11 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 
*data, size_t datalen,
+   priv->sym_crypt_buffer_len = 0;
+   rest_len = 0;
+   }
+-  memcpy(sdata, data, apdu_datalen);
+-  data += apdu_datalen;
+-  datalen -= apdu_datalen;
+-
++  if (data) {
++  memcpy(sdata, data, apdu_datalen);
++  data += apdu_datalen;
++  datalen -= apdu_datalen;
++  }
+   r = sc_transmit_apdu(card, );
+   LOG_TEST_RET(ctx, r, "APDU transmit failed");
+   r = sc_check_sw(card, apdu.sw1, apdu.sw2);
+@@ -2084,7 +2088,8 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 *data, 
size_t datalen,
+   /* save rest of data for next run */
+   priv->sym_crypt_buffer_len = datalen;
+   sc_log(ctx, "rest data len = %zu", datalen);
+-  memcpy(priv->sym_crypt_buffer, data, datalen);
++  if (data)
++  memcpy(priv->sym_crypt_buffer, data, datalen);
+   sc_log(ctx, "return data len = %zu", return_len);
+   *outlen = return_len;
+   return SC_SUCCESS;
diff -Nru opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch 
opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch
--- opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch   1970-01-01 
00:00:00.0 +
+++ opensc-0.23.0/debian/patches/0007-CVE-2023-4535.patch   2023-11-08 
00:26:46.0 +
@@ -0,0 +1,39 @@
+Origin: 
https://github.com/OpenSC/OpenSC/commit/f1993dc4e0b33050b8f72a3558ee88b24c4063b2
+From: Peter Popovec 
+Date: Tue, 27 Jun 2023 09:50:42 +0200
+Subject: myeid: fixed CID 380538  Out-of-bounds read (OVERRUN)
+
+also fixes output buffer size checking
+---
+ src/libopensc/card-myeid.c | 10 ++
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/src/libopensc/card-myeid.c b/src/libopensc/card-myeid.c
+index 4ee4246840..50e78ff1d8 100644
+--- a/src/libopensc/card-myeid.c
 b/src/libopensc/card-myeid.c
+@@ -1986,18 +1986,20 @@ myeid_enc_dec_sym(struct sc_card *card, const u8 
*data, size_t datalen,
+   sc_log(ctx, "Found padding byte %02x", 
pad_byte);
+   if (pad_byte == 0 || pad_byte > block_size)
+   LOG_FUNC_RETURN(ctx, 
SC_ERROR_WRONG_PADDING);
+-  sdata = priv->sym_plain_buffer + block_size - 
pad_byte;
++  sdata = priv->sym_plain_buffer + block_size;
+

Bug#1055539: bookworm-pu: package opensc/0.23.0-0.3+deb12u1

[Bastian Germann]

Package: release.debian.org
Control: affects -1 + src:opensc
X-Debbugs-Cc: ope...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bookworm
Severity: normal

[ Reason ]
opensc in bookworm is vulnerable for CVE-2023-4535, CVE-2023-40660, 
CVE-2023-40661.

[ Impact ]
User can be attacked via the CVE vectors.

[ Tests ]
No automated tests. I have not exploited the CVEs.

[ Risks ]
I have left out two patches of CVE-2023-40661 because they change code that is not yet available in 
the bookworm release. There might be side effects of not applying them


[ 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

Bug#1055528: dgit: perl warning: variable $date masks earlier declaration

[Ian Jackson]

ControL: severity -1 normal

Étienne Mollier writes ("Bug#1055528: dgit: perl warning: variable $date masks 
earlier declaration"):
>   $ dgit --help
>   "my" variable $date masks earlier declaration in same scope at 
> /usr/bin/dgit line 2188.
>   main usages:
> dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir]
> dgit [dgit-opts] fetch|pull [dgit-opts] [suite]
> dgit [dgit-opts] build [dpkg-buildpackage-opts]
>   […]
> 
> This is repeatable with any other invocation from my typical
> dgit workflow.  This is not visibly impairing the functionality
> of dgit, hence the minor severity.

Thanks for the report.  This seems like it might be discouraging to
users so I think it warrants a higher severity.

I thought I had taken measures to treat warnings as errors, so err,
not sure how this could have esscaped through testsing.  I will
investigate that as well as fixing the underlying slip.

Regards,
Ian.

Bug#1055538: fanwor: Non-free music

[David (Plasma) Paul]

Package: fanwor
Version: 1.16-1
Severity: serious
Justification: Music is ineligible for inclusion in main and is not
 properly attributed in debian/copyright

Dear Maintainer,

The music for fanwor located at /usr/share/fanwor/sounds/backgrnd.mod,
while a jazzed-up remix, is unmistakably the theme tune for Nintendo's
The Legend of Zelda which has not been released by them under a
DFSG-compatible license.

Additionally, the author of the remix is left unattributed in the
package's copyright file. Opening /usr/share/fanwor/sounds/backgrnd.mod
in a tracker such as milkytracker or simply viewing it in a hex editor
reveals this embedded message:
```
ZELDA REMIX
BY MSG (C) MAR 1998
ORIGINAL VERSION BY:
TOODELOO / DHS AND...
 3LE / COMA
```
Judging from https://demozoo.org/music/10/, it appears this music
originates from a demoscene production which debuted at the OrlandoJam
event in 1998.

-- 
Plasma

Bug#1055409: /usr/bin/dpkg-deb: dpkg-deb goes defunct and has to be killed during apt dist-upgrade

[Simon John]

Happened again today, what I noticed is that there seems to be two 
processes doing the same thing, as well as a defunct one:


root 2479916 79.5  0.2 150492 143888 pts/0   Rs+  23:14   2:25 
/usr/bin/dpkg --status-fd 25 --no-triggers --unpack --auto-deconfigure 
--recursive /tmp/apt-dpkg-install-uIkOEw


root 2481666  0.0  0.0   7364  2048 pts/0S+   23:16   0:00 
dpkg-deb --fsys-tarfile 
/tmp/apt-dpkg-install-uIkOEw/44-libgtk-4-doc_4.12.3+ds-2_all.deb


root 2481667  0.0  0.0  0 0 pts/0Z+   23:16   0:00 
[dpkg-deb] 


root 2481668  0.5  0.1 153632 114472 pts/0   Sl+  23:16   0:00 
dpkg-deb --fsys-tarfile 
/tmp/apt-dpkg-install-uIkOEw/44-libgtk-4-doc_4.12.3+ds-2_all.deb


It did eventually complete after 4mins!

--
Simon John

Bug#1055537: colcon: Does not install under bin/

[Yasushi SHOJI]

Package: colcon
Version: 0.15.0-1
Severity: normal
X-Debbugs-Cc: none, Yasushi SHOJI 

Dear Maintainer,

Colcon 0.15.0-1 doesn't install binaries specified by console_scripts of
entry_points in setup.py.  I've only tested with
generate_parameter_library_py[1] but this problem occurs only with the debian
package.  That is, colcon 0.15.0 from git[2] does work fine for me.

I'm attaching both build logs by .deb and the one I've built but this is
the diff:

```
❯ diff -u log/build_2023-11-08_08-08-40/generate_parameter_library_py/stdout.log
log/build_2023-11-08_08-08-47/generate_parameter_library_py/stdout.log
--- log/build_2023-11-08_08-08-40/generate_parameter_library_py/stdout.log
2023-11-08 08:08:41.721502097 +0900
+++ log/build_2023-11-08_08-08-47/generate_parameter_library_py/stdout.log
2023-11-08 08:08:48.293516763 +0900
@@ -11,9 +11,9 @@
 writing manifest file 'generate_parameter_library_py.egg-info/SOURCES.txt'
 running build_ext
 Creating 
/home/yashi/work/yoshida/avatar-ws/install/lib/python3.11/site-packages/generate-parameter-library-py.egg-link
(link to .)
-Installing generate_parameter_library_cpp script to
/home/yashi/work/yoshida/avatar-ws/install/lib/python3.11/site-packages
-Installing generate_parameter_library_markdown script to
/home/yashi/work/yoshida/avatar-ws/install/lib/python3.11/site-packages
-Installing generate_parameter_library_python script to
/home/yashi/work/yoshida/avatar-ws/install/lib/python3.11/site-packages
+Installing generate_parameter_library_cpp script to
/home/yashi/work/yoshida/avatar-ws/install/bin
+Installing generate_parameter_library_markdown script to
/home/yashi/work/yoshida/avatar-ws/install/bin
+Installing generate_parameter_library_python script to
/home/yashi/work/yoshida/avatar-ws/install/bin

 Installed 
/home/yashi/work/yoshida/avatar-ws/build/generate_parameter_library_py
 running install_data
```

The former is the deb, letter is the colcon I've built from the git
repo.

Hope this helps.

[1]: https://github.com/PickNikRobotics/generate_parameter_library
[2]: https://github.com/colcon/colcon-core/releases/tag/0.15.0

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

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

Versions of packages colcon depends on:
ii  python3  3.11.4-5+b1
ii  python3-colcon-core  0.15.0-1

Versions of packages colcon recommends:
ii  python3-colcon-argcomplete  0.3.3+ds-2
ii  python3-colcon-bash 0.5.0-1
ii  python3-colcon-cd   0.1.1-2
ii  python3-colcon-cmake0.2.28-1
ii  python3-colcon-defaults 0.2.8-1
ii  python3-colcon-devtools 0.2.5-1
ii  python3-colcon-library-path 0.2.1-2
ii  python3-colcon-metadata 0.2.5-2
ii  python3-colcon-notification 0.2.15+ds-2
ii  python3-colcon-output   0.2.13-1
ii  python3-colcon-package-information  0.3.3-2
ii  python3-colcon-package-selection0.2.10-2
ii  python3-colcon-parallel-executor0.3.0-1
ii  python3-colcon-python-setup-py  0.2.8-1
ii  python3-colcon-recursive-crawl  0.2.3-1
ii  python3-colcon-ros  0.4.1-1
ii  python3-colcon-test-result  0.3.8-2
ii  python3-colcon-zsh  0.5.0-1

colcon suggests no packages.

-- no debconf information
-- 
 yashi
running develop
running egg_info
creating generate_parameter_library_py.egg-info
writing generate_parameter_library_py.egg-info/PKG-INFO
writing dependency_links to generate_parameter_library_py.egg-info/dependency_links.txt
writing entry points to generate_parameter_library_py.egg-info/entry_points.txt
writing requirements to generate_parameter_library_py.egg-info/requires.txt
writing top-level names to generate_parameter_library_py.egg-info/top_level.txt
writing manifest file 'generate_parameter_library_py.egg-info/SOURCES.txt'
reading manifest file 'generate_parameter_library_py.egg-info/SOURCES.txt'
writing manifest file 'generate_parameter_library_py.egg-info/SOURCES.txt'
running build_ext
Creating /home/yashi/work/yoshida/avatar-ws/install/lib/python3.11/site-packages/generate-parameter-library-py.egg-link (link to .)
Installing generate_parameter_library_cpp script to /home/yashi/work/yoshida/avatar-ws/install/bin
Installing generate_parameter_library_markdown script to /home/yashi/work/yoshida/avatar-ws/install/bin
Installing generate_parameter_library_python script to /home/yashi/work/yoshida/avatar-ws/install/bin

Installed /home/yashi/work/yoshida/avatar-ws/build/generate_parameter_library_py
running 

Bug#1055536: dpkg-dev: dpkg-shlibdeps refuses to print version number in the absence of ./debian/control

[Guillem Jover]

Hi!

On Tue, 2023-11-07 at 23:43:29 +0100, Marc Jeanmougin wrote:
> Package: dpkg-dev
> Version: 1.22.1
> Severity: important

> Since 1.22 (does happen in 1.22.1, did not happen in 1.21.21),
> running "dpkg-shlibdeps --version" prints
> 
> ---
> dpkg-shlibdeps: error: cannot read debian/control: No such file or directory
> ---
> 
> instead of the version string (which can be obtained after a "mkdir debian;
> touch debian/control")
> 
> ---
> Debian dpkg-shlibdeps version 1.22.1.
> 
> This is free software; see the GNU General Public License version 2 or
> later for copying conditions. There is NO warranty.
> ---
> 
> This has downstream effects in tools that attempt to check the version of 
> dpkg-
> shlibdeps, as they can no longer work, e.g. "cpack -G DEB" (the .deb cmake
> generator) does not work anymore.

Ah, indeed! I've fixed this locally (need to add some regression
tests),  will push later today, and will try to do a release during
the week or weekend.

Thanks,
Guillem

Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"

[Hilmar Preuße]

On 9/4/23 22:10, Jeremy Lecour wrote:

Hi Jeremy,


After upgrading to Debian 12, my SFTP client stopped working with
errors when connecting.

I've opened a GitHub issue and the problem has been solved.
https://github.com/proftpd/proftpd/issues/1694

It will even be backported to the 1.3.8 branch, so I hope that it
might be available in an upcoming update in Debian 12.



I've put test packages here [1]. Could you try them and report back if 
they solve the issue?


Hilmar

[1] https://freeshell.de/~hille42/debian_1051236/
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055536: dpkg-dev: dpkg-shlibdeps refuses to print version number in the absence of ./debian/control

[Marc Jeanmougin]

Package: dpkg-dev
Version: 1.22.1
Severity: important

Dear Maintainer,

Since 1.22 (does happen in 1.22.1, did not happen in 1.21.21), running "dpkg-
shlibdeps --version" prints

---
dpkg-shlibdeps: error: cannot read debian/control: No such file or directory
---

instead of the version string (which can be obtained after a "mkdir debian;
touch debian/control")

---
Debian dpkg-shlibdeps version 1.22.1.

This is free software; see the GNU General Public License version 2 or
later for copying conditions. There is NO warranty.
---

This has downstream effects in tools that attempt to check the version of dpkg-
shlibdeps, as they can no longer work, e.g. "cpack -G DEB" (the .deb cmake
generator) does not work anymore.

Thanks a lot,


-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.41-6
ii  bzip2 1.0.8-5+b1
ii  libdpkg-perl  1.22.1
ii  make  4.3-4.1
ii  patch 2.7.6-7
ii  perl  5.36.0-9
ii  tar   1.34+dfsg-1.2
ii  xz-utils  5.4.4-0.1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.10
ii  clang-11 [c-compiler]1:11.1.0-6+b2
ii  clang-16 [c-compiler]1:16.0.6-16
ii  clang-9 [c-compiler] 1:9.0.1-20+b1
ii  fakeroot 1.32.1-1
ii  gcc [c-compiler] 4:13.2.0-1
ii  gcc-11 [c-compiler]  11.4.0-4
ii  gcc-12 [c-compiler]  12.3.0-10
ii  gcc-13 [c-compiler]  13.2.0-5
ii  gcc-8 [c-compiler]   8.4.0-7
ii  gcc-9 [c-compiler]   9.5.0-4
ii  gnupg2.2.40-1.1
ii  gpgv 2.2.40-1.1
ii  libalgorithm-merge-perl  0.08-5

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2023.09.24

-- no debconf information

Bug#1055535: dlt-daemon: Test suite is no parallel safe

[Guillem Jover]

Source: dlt-daemon
Source-Version: 2.18.10-5
Severity: normal

Hi!

The problem in #1054999 was about the test suite not being parallel
safe, as it uses the same log files under /tmp, which means when
executed in parallel causes race conditions.

Each test should get its own test file, ideally under the build tree
and not under /tmp. Also because by default the test suite leaves
behind lots of cruft.

Once this is fixed, the override to set --no-parallel in debian/rules
can be dropped.

Thanks,
Guillem

Bug#1054999: dlt-daemon: FTBFS: 5: /bin/sh: 1: killall: not found

[Gianfranco Costamagna]

Hello Guillem
On Tue, 7 Nov 2023 20:35:43 +0100 Guillem Jover  wrote:

Control: tag -1 patch



Big thanks!!!

Uploaded!

G.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055534: sq-wot - should the binary be dropped.

[Peter Green]

Package: sq-wot
x-debbugs-cc: alexander.kj...@gmail.com, d...@fifthhorseman.net

Since it seems we now (fingers crossed) finally have a version of
ring that should build on all release architectures I decided it was
time to fix sequoia-sq which has been languishing in a rc buggy
state since soon after the bookworm release. As part of doing this
I looked at sequoia-wot.

While checking what was going on, I discovered that the sq-wot binary
had been dropped in a git commit by Alexander Kjäll (capitol), even
more strangely the same commit that disabled building the binaries
added manpages for them.

I discussed this with capitol on irc

 capitol, can you explain e2c9d5396d09ed7d3105dfd2cdf2ac4fbf594926
 because it really doesn't make much sense to me
 It seems to add a bunch of manpages for the binaries, yet disable 
actually building/packaging them!
 and none of the (pretty substantial) changes other than the new 
upstream release are documented in the changelog.
 (sorry if it wasn't clear in my first message, the hex string was a 
debcargo-conf commit ID 
https://salsa.debian.org/rust-team/debcargo-conf/-/commit/e2c9d5396d09ed7d3105dfd2cdf2ac4fbf594926
 )
* hiddenman_ (~and...@broadband-46-242-8-154.ip.moscow.rt.ru) has joined
 plugwash: i followed the pattern of a couple of other binaries with man 
pages here, to add the man pages to the package, and add a .manpages 
file to get them into the correct place
 i have a memory of checking that they got into the package, but let 
me verify that again
 and sorry for not documenting this in the changelog, i'll make an 
effort on being more verbose in that
 +bin = false
  overlay = "."
 -uploaders = ["Daniel Kahn Gillmor "]
 -bin_name = "sq-wot"
 +uploaders = ["Daniel Kahn Gillmor ", "Alexander Kjäll 
"]
 that's the bit I don't get, you seem to be disabling building of 
binaries at all.
 ohh...
 yes, now i realize, the sq-wot binary have been deprecated from 
sequoia, and replace with a 'wot' subcommand to the sq binary
 and since the original package had only gone to experimental i 
thought it best to not get it into debian
 i should have cleaned up the man pages, those where done before i 
talked to sequoia about it and they asked it to not be packaged
 and now the package seem to have bit-rotted and can't be built 
anymore, due to usage of a deprecated function, I can look at that tomorrow
 umm
 sq-wot is in stable, testing and unstable
 i must remember this totally wrong :/

After this conversation I decided to revert the change dropping the binary
package for now.

I don't object to removing the binary package in principle if it is clear
that people fully understand the situation and have decided that is the
best way forward but equally i'm not going to upload a version including
said removal until/unless it is clear to me that there is said consensus.
Especially given that while removing a binary package is easy, adding one
back requires dealing with the random delay and nitpicking of the NEW
queue.

I would particularly like dkg, as the person who initially packaged
sequoia-wot a year and a half ago to weigh in on this.

Bug#1055533: doxygen: Please move mat2 build-dep to build-dep-indep

[Samuel Thibault]

Package: doxygen
Version: 1.9.8+ds-1
Severity: normal
Tags: patch

Hello,

doxygen currently build-depends on mat2, but mat2 build-depends on
gir1.2-poppler-0.18, poppler build-depends on libboost, and libboost
build-depends on doxygen, thus forming a build-dependency loop which
makes bootstrapping new Debian ports tricky.

But actually doxygen uses mat2 only for documentation, whose build is
enabled only for arch-indep builds. Could you thus move the mat2
build-dep to build-dep-indep, as the attached patch does?

Thanks,
Samuel

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

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

Versions of packages doxygen depends on:
ii  libc6   2.37-12
ii  libclang-cpp14  1:14.0.6-16
ii  libclang1-141:14.0.6-16
ii  libgcc-s1   13.2.0-5
ii  libllvm14   1:14.0.6-16
ii  libstdc++6  13.2.0-5
ii  libxapian30 1.4.22-1

doxygen recommends no packages.

Versions of packages doxygen suggests:
ii  doxygen-doc1.9.4-4
pn  doxygen-gui
ii  doxygen-latex  1.9.4-4
ii  graphviz   2.42.2-7+b3

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-07 22:49:05.379745716 +0100
+++ debian/control  2023-11-07 22:49:09.939774255 +0100
@@ -16,8 +16,7 @@
   libclang-dev [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 
ppc64el riscv64 s390x sparc64],
   clang [amd64 armel armhf arm64 i386 mips mipsel mips64el ppc64 ppc64el 
riscv64 s390x sparc64],
   sassc,
-  faketime,
-  mat2
+  faketime
 Build-Depends-Indep: texlive-fonts-recommended,
   texlive-plain-generic,
   texlive-latex-extra,
@@ -26,7 +25,8 @@
   texlive-font-utils,
   ghostscript,
   graphviz,
-  rdfind
+  rdfind,
+  mat2
 Standards-Version: 4.6.1
 Homepage: https://www.doxygen.nl/
 Vcs-Browser: https://salsa.debian.org/debian/doxygen

Bug#1055514: opensysusers: ineffective diversion of /bin/systemd-sysusers due to /usr-merge and DEP17

[Andrea Pappacoda]

Hi Helmut, thanks for your report!

Il giorno mar 7 nov 2023 alle 18:07:56 +01:00:00, Helmut Grohne 
 ha scritto:
opensysusers diverts /bin/systemd-sysusers. systemd has moved this 
file
to /usr/bin/systemd-sysusers in version 255~rc1-1. While this change 
is
not visible in an installation, the diversion no longer matches it. 
Thus

what ends up at systemd-sysusers now depends on the order of unpacks.
The diversion has become ineffective. This is a known problem category
and documented in DEP17[1] as P3.

Usually, the recommended mitigation for this kind of problem is
duplicating the diversion (M18) such that both /bin/systemd-sysusers 
and

/usr/bin/systemd-sysusers are diverted. I'm attaching a patch for this
approach, but I think this is not the preferred solution for this 
case.


I dug deeper as to why opensysusers would divert systemd-sysusers,
talked to systemd maintainers and Thomas Goirand and read about 
#947847

in the process. Given this background, I believe that the use of a
diversion is not a good solution and this was echoed by the CTTE
decision, which declined to overrule and considered diversion a
mechanism for experimentation. Three years later and with two stable
releases including opensysusers I hope we are past the experimentation
phase. The diversion setup bears a significant downside: While the API
existing API of the sysusers interface is relatively stable, systemd
keeps adding features and when systemd calls systemd-sysusers it wants
to be able to rely on its latest features. A diverted systemd-sysusers
may not provide what is needed here. Looking deeper into policy 
sections

7.4 and 7.5, the virtual package systemd-sysusers looks similar to
mail-transport-agent where each implementation
provides+conflicts+replaces mail-transport-agent. I think opensysusers
should do the same. Once doing so, the diversion (and thus this bug)
goes away entirely. The downside is that opensysusers and systemd are 
no

longer coinstallable. I'm also attaching a patch for this.


I do agree with this reasoning. As mentioned in one of the old threads 
about this, in my opinion it would've been better to have a general, 
more restricted "sysusers" alternative command which could've been 
provided by opensysusers and systemd-sysusers, and would be used by 
things like dh_installsysusers and the like. Stepping into the 
"systemd-" namespace without actually supporting all the features *and* 
closely following new feature additions is asking for trouble. And, 
since the upstream developers (i.e. the Artix Linux maintainers) 
stopped development in favour of systemd-standalone-sysusers[1], I'm 
now more inclined to change approach and drop diversions.



I caution that Thomas Goirand disagrees with this approach and
recommends that these packages remain coinstallable and that users may
choose the implementation. On the flip side, a user cannot choose to
have systemd as the provider of systemd-sysusers when opensysusers is
installed.


I get Thomas' point, and I'd really like if I could keep offering 
opensysusers as a valid alternative to systemd-sysusers, but given its 
current state I don't think it's reasonable to keep doing so, 
especially considering that there's systemd-standalone-sysusers. One 
use case which systemd-standalone-sysusers doesn't cover though is 
support for non-Linux OSes, but to be fair opensysusers doesn't either. 
I did start working on a POSIX reimplemetation of the sysusers concept 
so that it could replace opensysusers entirely and also run on (the now 
dead) Debian/kFreeBSD and also Hurd, but never actually finished it.



A possible compromise could be that opensysusers stops diverting
systemd-sysusers and installs the symbolic link without diversion such
that systemd becomes the preferred provider when coinstalled. It could
detect removal of systemd using file triggers and then reinstate the
link. Such a setup also requires little cooperation from systemd
maintainers, but it relies on an symbolic link that is completely
untracked by dpkg, so there is some fragility to be found here whereas
the conflict is conceptually simpler.


I'm not sure I follow, but choosing an approach which isn't tracked by 
dpkg doesn't sound right to me.


In any case, something needs to be done here. The latest systemd 
upload

now declares an unversioned conflict with opensysusers. It can become
versioned once opensysusers has addressed this bug in some way.


I want to fix this too, and I really thank you for the help. I'm 
inclined to drop the diversions, but I'd first like to fully understand 
the consequences (e.g. would something break for someone?).


Bye :D

[1]: https://forum.artixlinux.org/index.php/topic,1839.0.html

Bug#1055531: apt-listbugs: Fails with Input/output error when current working directory is not available

[Jochen Spieker]

Package: apt-listbugs
Version: 0.1.41
Severity: minor

Dear Maintainer,

on my laptop running sid I am often using an NFS mount that is only available
when I am at home.

Today I had the NFS filesystem mounted when I suspended my laptop, moved it
somewhere else and woke it up again. My shell still had the NFS (unavailable)
mount as the current working directory. Then I ran 'apt upgrade'.  The upgrade
failed like this:

$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  libplacebo292
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  libdav1d7 libplacebo338
The following packages will be upgraded:
  aapt android-libaapt android-libandroidfw android-libboringssl avahi-autoipd 
avahi-daemon containerd dmtracedump efibootmgr faad fakeroot ffmpeg 
gir1.2-shumate-1.0
  libavahi-client3 libavahi-common-data libavahi-common3 libavahi-core7 
libavahi-glib1 libavahi-gobject0 libavahi-ui-gtk3-0 libavcodec60 libavdevice60 
libavfilter9
  libavformat60 libavif16 libavutil58 libfaad2 libfakeroot libfuse2 
libheif-plugin-aomdec libheif-plugin-aomenc libheif-plugin-dav1d 
libheif-plugin-libde265
  libheif-plugin-x265 libheif1 libjudydebian1 libmnl0 libmujs3 libostree-1-1 
libpostproc57 libsdl2-2.0-0 libshumate-1.0-1 libshumate-common libswresample4 
libswscale7
  libvlc-bin libvlc5 libvlccore9 node-get-stream python3-zope.interface rpcbind 
split-select vlc vlc-bin vlc-plugin-access-extra vlc-plugin-base 
vlc-plugin-notify
  vlc-plugin-qt vlc-plugin-samba vlc-plugin-skins2 vlc-plugin-video-output 
vlc-plugin-video-splitter vlc-plugin-visualization
63 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/54,1 MB of archives.
After this operation, 11,2 MB of additional disk space will be used.
Do you want to continue? [Y/n]
:220:in `glob': Input/output error - ./locale (Errno::EIO)
from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:64:in `block in 
default_path_rules'
from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:63:in `select'
from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:63:in 
`default_path_rules'
from /usr/lib/ruby/vendor_ruby/gettext/locale_path.rb:80:in `initialize'
from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:52:in `new'
from /usr/lib/ruby/vendor_ruby/gettext/text_domain.rb:52:in `initialize'
from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:226:in 
`new'
from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:226:in 
`create_or_find_text_domain'
from /usr/lib/ruby/vendor_ruby/gettext/text_domain_manager.rb:71:in 
`bind_to'
from /usr/lib/ruby/vendor_ruby/gettext.rb:73:in `bindtextdomain_to'
from /usr/lib/ruby/vendor_ruby/gettext.rb:54:in `bindtextdomain'
from /usr/bin/apt-listbugs:428:in `'
E: Sub-process /usr/bin/apt-listbugs apt returned an error code (1)
E: Failure running script /usr/bin/apt-listbugs apt


It would be great if a problem with the current working directory could be
handled more gracefully. It took me a few minutes to find out what the problem 
was.

Thanks,
Jochen

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

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

Versions of packages apt-listbugs depends on:
ii  apt 2.7.6
ii  ruby1:3.1
ii  ruby-debian 0.3.10+b8
ii  ruby-gettext3.3.3-2
ii  ruby-soap4r 2.0.5-6
ii  ruby-unicode0.4.4.4-1+b5
ii  ruby-xmlparser  0.7.3-4+b4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3+git20211122.4658227-1

Versions of packages apt-listbugs suggests:
ii  firefox [www-browser]   119.0-1
ii  google-chrome-stable [www-browser]  119.0.6045.105-1
ii  konqueror [www-browser] 4:22.12.3-2
ii  lynx [www-browser]  2.9.0dev.12-1
ii  reportbug   12.0.0
ii  sensible-utils  0.0.20
ii  xdg-utils   1.1.3-4.1

-- no debconf information

Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)

[Hilmar Preuße]

On 10/30/23 11:52, Hilmar Preuße wrote:

Hi Stuart,


I was told not to use that URL, so here is a new one 
https://freeshell.de/~hille42/debian_1054218/


Did you find the time to test the fix?

Hilmar
--
Testmail



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055527: [Debian-med-packaging] Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable

[Étienne Mollier]

Étienne Mollier, on 2023-11-07:
>   I'm also tempted by the unversionned llvm
> packages so these kind of version bumps do not go overlooked in
> the future, but need to check why the specific version was
> applied in the first place.

According to commit 4be8e58e4d07bde442b5b118318e8dc2e1ac80c8,
the versionning originated from a need to bump ahead of the
default at llvm-9 to get simde intrinsics support.  It thus
looks now suitable to drop the versionning.

Cheers,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: This Winter Machine - The River (Parts 1 & 2)


signature.asc
Description: PGP signature

Bug#1055530: vala: Please add nographviz profile to avoid build-depend cycle

[Samuel Thibault]

Source: vala
Version: 0.56.13-1
Severity: normal
Tags: patch

Hello,

- vala build-depends on libgraphviz-dev
- graphviz build-depends on librsvg2-dev
- librsvg build-depends on valac

thus forming a build-dependency loop which makes bootstrapping new
Debian ports tricky.

AIUI, vala uses graphviz only for valadoc, so it is easy for it to allow
disabling the dependency through a pkg.vala.nographviz build profile
that just disables building valadoc, as the attached patch does, could
you apply it?

(valadoc is rarely build-depended on, or else mostly as
build-depend-indep or with , so it seems like a good candidate
for bootstrap-skipping)

Thanks,
Samuel

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

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-11-07 20:52:29.0 +
+++ debian/control  2023-11-07 20:54:36.0 +
@@ -10,7 +10,7 @@
 Build-Depends: debhelper-compat (= 13),
dh-sequence-gnome,
libglib2.0-dev (>= 2.48),
-   libgraphviz-dev (>= 2.16),
+   libgraphviz-dev (>= 2.16) ,
bison (>= 2.3),
flex,
libdbus-1-dev ,
@@ -156,6 +156,7 @@
 
 Package: valadoc
 Architecture: any
+Build-Profiles: 
 Depends: ${shlibs:Depends},
  libvaladoc-0.56-0 (= ${binary:Version}),
  libvalacodegen-0.56-0 (= ${binary:Version}),
@@ -171,6 +172,7 @@
 Package: libvaladoc-0.56-0
 Section: libs
 Architecture: any
+Build-Profiles: 
 Multi-Arch: same
 Depends: ${shlibs:Depends},
  libvala-0.56-0 (= ${binary:Version}),
@@ -187,6 +189,7 @@
 Package: libvaladoc-0.56-data
 Section: misc
 Architecture: all
+Build-Profiles: 
 Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: API documentation generator for vala (data)
@@ -199,6 +202,7 @@
 Package: libvaladoc-0.56-dev
 Section: libdevel
 Architecture: any
+Build-Profiles: 
 Multi-Arch: same
 Depends: ${misc:Depends},
  libvala-0.56-dev (= ${binary:Version}),
--- debian/control.in.original  2023-11-07 20:52:46.0 +
+++ debian/control.in   2023-11-07 20:54:16.0 +
@@ -6,7 +6,7 @@
 Build-Depends: debhelper-compat (= 13),
dh-sequence-gnome,
libglib2.0-dev (>= 2.48),
-   libgraphviz-dev (>= 2.16),
+   libgraphviz-dev (>= 2.16) ,
bison (>= 2.3),
flex,
libdbus-1-dev ,
@@ -152,6 +152,7 @@
 
 Package: valadoc
 Architecture: any
+Build-Profiles: 
 Depends: ${shlibs:Depends},
  libvaladoc-0.56-0 (= ${binary:Version}),
  libvalacodegen-0.56-0 (= ${binary:Version}),
@@ -167,6 +168,7 @@
 Package: libvaladoc-0.56-0
 Section: libs
 Architecture: any
+Build-Profiles: 
 Multi-Arch: same
 Depends: ${shlibs:Depends},
  libvala-0.56-0 (= ${binary:Version}),
@@ -183,6 +185,7 @@
 Package: libvaladoc-0.56-data
 Section: misc
 Architecture: all
+Build-Profiles: 
 Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: API documentation generator for vala (data)
@@ -195,6 +198,7 @@
 Package: libvaladoc-0.56-dev
 Section: libdevel
 Architecture: any
+Build-Profiles: 
 Multi-Arch: same
 Depends: ${misc:Depends},
  libvala-0.56-dev (= ${binary:Version}),
--- debian/rules.original   2023-11-07 20:55:30.0 +
+++ debian/rules2023-11-07 21:02:42.0 +
@@ -6,6 +6,10 @@
 export DPKG_GENSYMBOLS_CHECK_LEVEL = 4
 include /usr/share/dpkg/architecture.mk
 
+ifneq (,$(filter pkg.vala.nographviz,$(DEB_BUILD_PROFILES)))
+NOVALADOC=--disable-valadoc
+endif
+
 %:
dh $@
 
@@ -18,7 +22,7 @@
dh_autoreconf --as-needed
 
 configure-bootstrap:
-   dh_auto_configure --builddirectory=bootstrap/build
+   dh_auto_configure --builddirectory=bootstrap/build -- $(NOVALADOC)
 
 bootstrap: configure-bootstrap
dh_auto_build --builddirectory=bootstrap/build
@@ -29,7 +33,7 @@

Bug#1055529: pdns-server: Spams journal after installation because it is configured to automatically restart

[Uwe Kleine-König]

Package: pdns-server
Version: 4.4.1-1
Severity: normal

Hello,

on installation of pdns-server the pdns.service is automatically
started. However in my case port 53 is already bound and so it fails to
start. (That might also happen if port 53 isn't blocked because the
default config isn't suitable to successfully run pdns? I didn't check.)

Because of

Restart=on-failure
RestartSec=1
StartLimitInterval=0

in pdns.service the systemd tries to start pdns once per second and for
each try logs something like:

Nov 07 21:41:55 algol systemd[1]: Starting PowerDNS Authoritative 
Server...
Nov 07 21:41:55 algol pdns_server[2329737]: Loading 
'/usr/lib/x86_64-linux-gnu/pdns/libbindbackend.so'
Nov 07 21:41:55 algol pdns_server[2329737]: This is a standalone pdns
Nov 07 21:41:55 algol pdns_server[2329737]: Listening on controlsocket 
in '/run/pdns/pdns.controlsocket'
Nov 07 21:41:55 algol pdns_server[2329737]: UDP server bound to 
0.0.0.0:53
Nov 07 21:41:55 algol pdns_server[2329737]: UDP server bound to [::]:53
Nov 07 21:41:55 algol pdns_server[2329737]: Unable to bind to TCP 
socket 0.0.0.0:53: Address already in use
Nov 07 21:41:55 algol pdns_server[2329737]: Fatal error: Unable to bind 
to TCP socket
Nov 07 21:41:55 algol systemd[1]: pdns.service: Main process exited, 
code=exited, status=1/FAILURE
Nov 07 21:41:55 algol systemd[1]: pdns.service: Failed with result 
'exit-code'.
Nov 07 21:41:55 algol systemd[1]: Failed to start PowerDNS 
Authoritative Server.
Nov 07 21:41:56 algol systemd[1]: pdns.service: Scheduled restart job, 
restart counter is at 23.
Nov 07 21:41:56 algol systemd[1]: Stopped PowerDNS Authoritative Server.

to the journal. If you don't notice this immediately and stop the
service this effectively spams your journal in a very short time.

IMHO the above mentioned settings are not suitable as a default for a
distribution's package even if the default configuration worked. It
should be an administrator's choice to configure such a behaviour.

Best regards
Uwe

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

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

Versions of packages pdns-server depends on:
ii  adduser 3.118+deb11u1
ii  libboost-program-options1.74.0  1.74.0-9
ii  libc6   2.31-13+deb11u7
ii  libcurl47.74.0-1.3+deb11u10
ii  libgcc-s1   10.2.1-6
ii  libluajit-5.1-2 2.1.0~beta3+dfsg-5.3
ii  libp11-kit0 0.23.22-1
ii  libsodium23 1.0.18-1
ii  libsqlite3-03.34.1-3
ii  libssl1.1   1.1.1w-0+deb11u1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-7+deb11u4

Versions of packages pdns-server recommends:
ii  pdns-backend-bind  4.4.1-1

Versions of packages pdns-server suggests:
ii  pdns-backend-bind [pdns-backend]   4.4.1-1
ii  pdns-backend-pgsql [pdns-backend]  4.4.1-1

-- Configuration Files:
/etc/powerdns/pdns.conf [Errno 13] Permission denied: '/etc/powerdns/pdns.conf'

-- no debconf information

Bug#1055415: Wrong order for the `resolve' option in nsswitch.conf

[Michael Biebl]

On Sun, 5 Nov 2023 20:41:44 +0100 Sylvain Garrigues 
 wrote:

Le dimanche 5 novembre 2023, Michael Biebl  a écrit :

>
> See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162
>
>
This is indeed related. Yet the changes (as of today) do not seem to fix
the order for `resolve'. This merge request seems to be waiting for a
consensus before it can make progress.


Indeed, we don't have a consensus yet what the correct ordering is, if 
there is such a thing.

As for myself, I don't have a strong opinion.

Aspects to consider:
- systemd upstream recommendations
- seeing how other distros are doing it
- our status quo (which sort of works in the absence of bug reports)

Given all involved packages, another problem is the order in which 
packages are installed. I fear, we can't solve this with the current 
setup/infrastructure, where every package on its own mangles 
/etc/resolv.conf


We'd need something like Gioele's idea for dh-nss v2, where 
/etc/resolv.conf is compiled from a list of config files that are 
provided by packages shipping NSS modules.


Gioele has a much more intimate grasp on this matter, so I've CCed him.

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055527: [Debian-med-packaging] Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable

[Étienne Mollier]

Hi Witold,

Witold Baryluk, on 2023-11-07:
> Dear Maintainer,
> 
> castxml is using llvm-14
> 
> would be nice to bump this to 17 in unstable / testing. Unless there is
> some autoupgrade comming in few next weeks.

Thank you for the heads up, llvm-17 looks like it could be a
good option indeed.  I'm also tempted by the unversionned llvm
packages so these kind of version bumps do not go overlooked in
the future, but need to check why the specific version was
applied in the first place.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: Green Lung - The Forest Church


signature.asc
Description: PGP signature

Bug#1055510: Best way to coordinate this fix

[Helmut Grohne]

Hi Francois,

On Tue, Nov 07, 2023 at 08:11:19PM +, Luca Boccassi wrote:
> On Tue, 7 Nov 2023 at 20:04, Francois Marier  wrote:
> > What's the best way to coordinate a fix for this?
> >
> > I assume that we shouldn't upload a new molly-guard packages until the files
> > have actually moved in the systemd package?
> >
> > Should we wait until systemd is in unstable to push a new molly-guard out?

If the workaround is correctly implemented, it can go to unstable
directly. Note that it's not simply changing the diversions from the old
location to the new location. The workaround is duplicating them. At
that point, you can no longer use --rename and have to do the renaming
by hand. I'm happy to review a patch. For opensysusers I sent one, but I
haven't gotten down to molly-guard yet.

Helmut

Bug#1055528: dgit: perl warning: variable $date masks earlier declaration

[Étienne Mollier]

Package: dgit
Version: 11.4
Severity: minor

Dear Maintainer,

Running dgit on Debian sid, I noticed recently that every
invocation started with what looks like a perl warning.  Example
output can be optained with --help flag:

$ dgit --help
"my" variable $date masks earlier declaration in same scope at 
/usr/bin/dgit line 2188.
main usages:
  dgit [dgit-opts] clone [dgit-opts] package [suite] [./dir|/dir]
  dgit [dgit-opts] fetch|pull [dgit-opts] [suite]
  dgit [dgit-opts] build [dpkg-buildpackage-opts]
[…]

This is repeatable with any other invocation from my typical
dgit workflow.  This is not visibly impairing the functionality
of dgit, hence the minor severity.

Have a nice day,  :)
Étienne.


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

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

Versions of packages dgit depends on:
ii  apt2.7.6
ii  ca-certificates20230311
ii  coreutils  9.1-1
ii  curl   8.4.0-2
ii  devscripts 2.23.6
ii  dpkg-dev   1.22.1
ii  dput-ng [dput] 1.37
ii  git [git-core] 1:2.42.0-1
ii  git-buildpackage   0.9.32
ii  libdpkg-perl   1.22.1
ii  libjson-perl   4.1-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-6
ii  libtext-csv-perl   2.03-1
ii  libtext-glob-perl  0.11-3
ii  libtext-iconv-perl 1.7-8
ii  libwww-curl-perl   4.17-10
ii  perl [libdigest-sha-perl]  5.36.0-9

Versions of packages dgit recommends:
ii  distro-info-data 0.59
ii  liburi-perl  5.21-1
ii  openssh-client [ssh-client]  1:9.4p1-1

Versions of packages dgit suggests:
ii  pbuilder  0.231
ii  sbuild0.85.4

-- no debconf information

-- 
  .''`.  Étienne Mollier 
 : :' :  gpg: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/5, please excuse my verbosity
   `-on air: Sky Empire - The Last Days of Planet Fantasy


signature.asc
Description: PGP signature

Bug#1055504: ITP: laz-perf -- LAZperf is an alternative LAZ (Compressed LAS pointclouds) decoding implementation.

[Gürkan Myczko]

Hi Richard,

> On 7 Nov 2023, at 16:33, Richard Duivenvoorde  wrote:
> 
> Hi Gürkan,
> 
> Just found out that LAZperf is not a dependency of PDAL because sources in 
> taken into PDAL itself.
> 
> But I'm still interested in trying to package LAZperf itself too, IF others 
> think it is useful.

Actually I am not sure if cloudcompare really supports it, but if it does (I 
can take a look at it), it’d be very useful
to load LAZ (compressed LAS files), which are common, and I have users that 
need this feature.
> 
> If you say: "I prefer uploads to mentors.d.n" do you mean NOT in the science 
> packaging team or do you mean something else?
> Reason I choose science packaging team is because the former package of PDAL 
> proposed that.

The packaging team is fine. Take a look at mentors.debian.net 
 
It is just about the source package you have, you’d upload it to this place, 
but any url, or even packaging at salsa.debian.org  
is fine,
so tell me if/when you have something.
> 
> I'm very green in this, so please bare with me
Glad to hear, looking forward….
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> On 11/7/23 15:33, Gürkan Myczko wrote:
>> I would be great to help, cloudcompare seems to support it. Find me as 
>> tarzeau_ on irc
>> I prefer uploads to mentors.d.n
>> Maybe you find something useful at
>> Index of /debian/laz-perf/ 
>> sid.ethz.ch 
>> 
>> 
>>> On Nov 7, 2023, at 14:54, Richard Duivenvoorde  wrote:
>>> 
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Richard Duivenvoorde 
>>> X-Debbugs-Cc: debian-de...@lists.debian.org
>>> 
>>> * Package name: laz-perf
>>>  Version : 3.4.0
>>>  Upstream Contact: Howard Butler 
>>> * URL : https://github.com/hobuinc/laz-perf
>>> * License : APLv2
>>>  Programming Lang: C, C++, C#, Python
>>>  Description : LAZperf is an alternative LAZ (Compressed LAS 
>>> pointclouds) decoding implementation.
>>> 
>>> It supports compilation to WASM via Emscripten so that LAZ data can be 
>>> decoded in a browser.
>>> LAZperf is a dependecy for the PDAL library (https://github.com/PDAL/PDAL/).
>>> PDAL can be used as a library for QGIS (https://qgis.org) to be able to 
>>> read/analyze point clouds.
>>> 
>>> I'm planning to maintain both LAZperf and PDAL with the science packaging 
>>> team.
>>> 
>>> If I'm correct I'm also looking for a sponsor. But I'm very new to Debian 
>>> packaging, so every help is appreciated
>>> 
>>> Regards,
>>> 
>>> Richard Duivenvoorde
>>> 
> 

Bug#1055527: castxml: Please update llvm/clang to llvm-17 in unstable

[Witold Baryluk]

Package: castxml
Version: 0.6.2-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

castxml is using llvm-14

would be nice to bump this to 17 in unstable / testing. Unless there is
some autoupgrade comming in few next weeks.

On my system there are still few programs still depending directly on
llvm-14 (afl++, castxml, bpftrace, doxygen and python3-numba via
python3-llvmlite),  (ldc and doxygen in unstable already migrated to
llvm-16)

There is ongoing llvm-14-rm transition going

https://release.debian.org/transitions/html/llvm-14-rm.html


We do have llvm-15 in stable, llvm-16 in testing and unstable, and
llvm-17 in unstable (since 2023-10-30, so few days ago).

llvm-17 will likely migrate to testing in few days. Would be nice to
update castxml to use it. Upstream for version 0.6.2 says llvm 17 is
supported.

If llvm-17 does not migrate, updating to llvm-16 is another option.

(alpha port can be ignored, as it is on ancient version of castxml
anyway, and llvm cannot be bootstreapped on it for a long time anyway).


Regards,
Witold

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

Kernel: Linux 6.6.0 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages castxml depends on:
ii  libc6   2.37-12
ii  libclang-cpp14  1:14.0.6-16
ii  libllvm14   1:14.0.6-16
ii  libstdc++6  13.2.0-5

castxml recommends no packages.

castxml suggests no packages.

-- no debconf information

Bug#1055526: efibootmgr: output broken and shows hex dump after update (can be fixed with -u, which is documented as unrelated)

[наб]

Package: efibootmgr
Version: 18-1
Severity: normal

Dear Maintainer,

-- >8 --
$ efibootmgr
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0005,0004,0001,0002,0003
Boot0001* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0002* UEFI:Removable Device BBS(130,,0x0)
Boot0003* UEFI:Network Device   BBS(131,,0x0)
Boot0004* Debian GNU/Linux trixie/sid with Linux 6.1.0-7-amd64  
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-7-AMD64\VMLINUZ-6.1.0-7-AMD64)69006e0069007400720064003d005c006b006c00610070006b0069005c00370033003100620036003900660030006400610063003100340037006500660061006400660065006400390032006600310032003700310032003700330036005c0036002e0031002e0030002d0037002d0061006d006400360034005c0069006e0069007400720064002e0069006d0067002d0036002e0031002e0030002d0037002d0061006d00640036003400200072006f006f0074003d007a00660073003a004100550054004f0020006600620063006f006e003d0072006f0074006100740065003a003300200069006e00740065006c005f0069006f006d006d0075003d006f006e0020007a00660073002e007a00660073005f006100720063005f006d00610078003d003100320038003800340039003000310038003800380020007100750069006500740020006d006f00640075006c0065002e007300690067005f0065006e0066006f007200630065003d003100
Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64)69006e0069007400720064003d005c006b006c00610070006b0069005c00370033003100620036003900660030006400610063003100340037006500660061006400660065006400390032006600310032003700310032003700330036005c0036002e0031002e0030002d0039002d0061006d006400360034005c0069006e0069007400720064002e0069006d0067002d0036002e0031002e0030002d0039002d0061006d00640036003400200072006f006f0074003d007a00660073003a004100550054004f0020006600620063006f006e003d0072006f0074006100740065003a003300200069006e00740065006c005f0069006f006d006d0075003d006f006e0020007a00660073002e007a00660073005f006100720063005f006d00610078003d003100320038003800340039003000310038003800380020007100750069006500740020006d006f00640075006c0065002e007300690067005f0065006e0066006f007200630065003d003100
-- >8 --

This is very cool and very useful.
Previous versions did something like this:
-- >8 --
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0005,0004,0001,0002,0003
Boot0001* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0002* UEFI:Removable Device BBS(130,,0x0)
Boot0003* UEFI:Network Device   BBS(131,,0x0)
Boot0004* Debian GNU/Linux trixie/sid with Linux 6.1.0-7-amd64  
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-7-AMD64\VMLINUZ-6.1.0-7-AMD64)i.n.i.t.r.d.=.\.k.l.a.p.k.i.\.7.3.1.b.6.9.f.0.d.a.c.1.4.7.e.f.a.d.f.e.d.9.2.f.1.2.7.1.2.7.3.6.\.6...1...0.-.7.-.a.m.d.6.4.\.i.n.i.t.r.d...i.m.g.-.6...1...0.-.7.-.a.m.d.6.4.
 .r.o.o.t.=.z.f.s.:.A.U.T.O. .f.b.c.o.n.=.r.o.t.a.t.e.:.3. 
.i.n.t.e.l._.i.o.m.m.u.=.o.n. 
.z.f.s...z.f.s._.a.r.c._.m.a.x.=.1.2.8.8.4.9.0.1.8.8.8. .q.u.i.e.t. 
.m.o.d.u.l.e...s.i.g._.e.n.f.o.r.c.e.=.1.
Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-9-AMD64\VMLINUZ-6.1.0-9-AMD64).i.n.i.t.r.d.=.\.k.l.a.p.k.i.\.7.3.1.b.6.9.f.0.d.a.c.1.4.7.e.f.a.d.f.e.d.9.2.f.1.2.7.1.2.7.3.6.\.6...1...0.-.9.-.a.m.d.6.4.\.i.n.i.t.r.d...i.m.g.-.6...1...0.-.9.-.a.m.d.6.4.
 .r.o.o.t.=.z.f.s.:.A.U.T.O. .f.b.c.o.n.=.r.o.t.a.t.e.:.3. 
.i.n.t.e.l._.i.o.m.m.u.=.o.n. 
.z.f.s...z.f.s._.a.r.c._.m.a.x.=.1.2.8.8.4.9.0.1.8.8.8. .q.u.i.e.t. 
.m.o.d.u.l.e...s.i.g._.e.n.f.o.r.c.e.=.1.
-- >8 --
which was suboptimal but still okay (as-in "readable").

The manual says:
-- >8 --
   -u | --unicode | --UCS-2
  Handle extra command line arguments as UCS-2 (default is ASCII).
-- >8 --
which reads to me like "arguments are already UCS-2, so don't re-encode
them" (how this works with arguments terminating at NULs is beyond me,
but that's neither here nor there). However:
-- >8 --
$ efibootmgr -u
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0005,0004,0001,0002,0003
Boot0001* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0002* UEFI:Removable Device BBS(130,,0x0)
Boot0003* UEFI:Network Device   BBS(131,,0x0)
Boot0004* Debian GNU/Linux trixie/sid with Linux 6.1.0-7-amd64  
HD(1,GPT,48520351-6c2c-4617-a8d1-f353b750ef98,0x800,0x76800)/File(\KLAPKI\731B69F0DAC147EFADFED92F12712736\6.1.0-7-AMD64\VMLINUZ-6.1.0-7-AMD64)initrd=\klapki\731b69f0dac147efadfed92f12712736\6.1.0-7-amd64\initrd.img-6.1.0-7-amd64
 root=zfs:AUTO fbcon=rotate:3 intel_iommu=on zfs.zfs_arc_max=12884901888 quiet 
module.sig_enforce=1
Boot0005* Debian GNU/Linux trixie/sid with Linux 6.1.0-9-amd64  

Bug#1055510: Best way to coordinate this fix

[Luca Boccassi]

On Tue, 7 Nov 2023 at 20:04, Francois Marier  wrote:
>
> Hi Luca,
>
> What's the best way to coordinate a fix for this?
>
> I assume that we shouldn't upload a new molly-guard packages until the files
> have actually moved in the systemd package?
>
> Should we wait until systemd is in unstable to push a new molly-guard out?

Hi,

I believe you can upload to unstable straight away, as it would be
adding new diversions which should be fine if nothing is there. For
confirmation CC'ing Helmut.

Kind regards,
Luca Boccassi

Bug#1055525: cryptojs: CVE-2023-46233

[Salvatore Bonaccorso]

Source: cryptojs
Version: 3.1.2+dfsg-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for cryptojs.

CVE-2023-46233[0]:
| crypto-js is a JavaScript library of crypto standards. Prior to
| version 4.2.0, crypto-js PBKDF2 is 1,000 times weaker than
| originally specified in 1993, and at least 1,300,000 times weaker
| than current industry standard. This is because it both defaults to
| SHA1, a cryptographic hash algorithm considered insecure since at
| least 2005, and defaults to one single iteration, a 'strength' or
| 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2
| relies on iteration count as a countermeasure to preimage and
| collision attacks. If used to protect passwords, the impact is high.
| If used to generate signatures, the impact is high. Version 4.2.0
| contains a patch for this issue. As a workaround, configure crypto-
| js to use SHA256 with at least 250,000 iterations.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-46233
https://www.cve.org/CVERecord?id=CVE-2023-46233
[1] https://github.com/brix/crypto-js/security/advisories/GHSA-xwcq-pm8m-c4vf
[2] 
https://github.com/brix/crypto-js/commit/421dd538b2d34e7c24a5b72cc64dc2b9167db40a

Regards,
Salvatore

Bug#1055524: bugs.debian.org: Wacom stylus input does not rotate when screen rotates

[Daniel Boyd]

Package: bugs.debian.org
Severity: important
X-Debbugs-Cc: danieljb...@icloud.com

Dear Maintainer,

I upgraded my Lenovo Thinkpad X201 Tablet from Debian 11 to Debian 12 and
noticed this issue.

When I rotate my screen using the physical rotate screen button on the bezel of
my monitor, the screen rotates by 90 degrees just as it always has. But the
stylus input does not rotate with the screen. So when I use the stylus, it
draws on the wrong part of the screen.

One workaround for this issue that I have found is if I execute the following
command while in an x.org session:

> xinput map-to-output 13 LVDS-1

where "13" is the device ID of my stylus and "LVDS-1" is the id of my screen.

The issue occurs in both X.org and in Wayland. But I have only discovered a
workaround that works in X.org.

It's not clear to me where exactly the bug occurs, but it's probably in Mutter,
the wacom_w8001 driver, libinput, or some misconfigured udev rule.

Bug#1055510: Best way to coordinate this fix

[Francois Marier]

Hi Luca,

What's the best way to coordinate a fix for this?

I assume that we shouldn't upload a new molly-guard packages until the files
have actually moved in the systemd package?

Should we wait until systemd is in unstable to push a new molly-guard out?

Francois

-- 
https://fmarier.org/

Bug#1055522: opensc: CVE-2023-40661

[Salvatore Bonaccorso]

Source: opensc
Version: 0.23.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opensc.

CVE-2023-40661[0]:
| Several memory vulnerabilities were identified within the OpenSC
| packages, particularly in the card enrollment process using
| pkcs15-init when a user or administrator enrolls cards. To take
| advantage of these flaws, an attacker must have physical access to
| the computer system and employ a custom-crafted USB device or smart
| card to manipulate responses to APDUs. This manipulation can
| potentially allow   compromise key generation, certificate loading,
| and other card management operations during enrollment.

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

Note that this CVE covers various of the oss-fuzz related issues
reported since the 0.23.0 release.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-40661
https://www.cve.org/CVERecord?id=CVE-2023-40661
[1] https://github.com/OpenSC/OpenSC/wiki/CVE-2023-40661

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055523: audacity: mod-opus fails to load

[Paul Martin]

Package: audacity
Version: 3.4.0+dfsg-1
Severity: normal

On first startup after update, audacity pops up a dialog saying that the 
new mod-opus failed to load due to "Inappropriate ioctl for device".

I've cleared ~/.audacity-data/ and ~/.config/audacity/ and the error 
persists.

Logs:

19:15:05: Audacity 3.4.0
19:15:05: FFmpeg libraries loaded successfully from: 
/lib/x86_64-linux-gnu/libavformat.so.60.3.100
19:15:08: Unable to load the module "/usr/lib/audacity/modules/mod-opus.so". 
Error: Inappropriate ioctl for device
19:16:01: sqlite3 message: (1) no such table: project in "SELECT 1 FROM project 
LIMIT 1;"
19:16:02: FFmpeg libraries loaded successfully from: 
/lib/x86_64-linux-gnu/libavformat.so.60.3.100


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

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

Versions of packages audacity depends on:
ii  audacity-data3.4.0+dfsg-1
ii  libasound2   1.2.10-1
ii  libc62.37-12
ii  libexpat12.5.0-2
ii  libflac++10  1.4.3+ds-2
ii  libflac121.4.3+ds-2
ii  libgcc-s113.2.0-6
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-2
ii  libglib2.0-0 2.78.1-2
ii  libgtk-3-0   3.24.38-5
ii  libid3tag0   0.15.1b-14
ii  liblilv-0-0  0.24.22-1
ii  libmpg123-0  1.32.3-1
ii  libogg0  1.3.5-3
ii  libopus0 1.4-1
ii  libportaudio219.6.0-1.2
ii  libportmidi0 1:217-6.1
ii  libportsmf0  0.1~svn20101010-6
ii  libsbsms10   2.3.0-1
ii  libsndfile1  1.2.2-1
ii  libsoundtouch1   2.3.2+ds1-1
ii  libsoxr0 0.1.3-4
ii  libsqlite3-0 3.44.0-1
ii  libstdc++6   13.2.0-6
ii  libsuil-0-0  0.10.18-1
ii  libtwolame0  0.4.0-2
ii  libuuid1 2.39.2-5
ii  libvamp-hostsdk3v5   2.10.0-4
ii  libvorbis0a  1.3.7-1
ii  libvorbisenc21.3.7-1
ii  libvorbisfile3   1.3.7-1
ii  libwavpack1  5.6.0-1
ii  libwxbase3.2-1   3.2.3+dfsg-3
ii  libwxgtk3.2-13.2.3+dfsg-3

audacity recommends no packages.

Versions of packages audacity suggests:
ii  amb-plugins [ladspa-plugin]   0.8.1-8
ii  bs2b-ladspa [ladspa-plugin]   0.9.1-3+b1
ii  calf-ladspa [ladspa-plugin]   1.1.3-8.1
ii  cmt [ladspa-plugin]   1.18-1
ii  invada-studio-plugins-ladspa [ladspa-plugin]  0.3.1-7
ii  lsp-plugins-ladspa [ladspa-plugin]1.2.13-1
ii  ste-plugins [ladspa-plugin]   0.0.2-7
ii  swh-plugins [ladspa-plugin]   0.4.17-3
ii  tap-plugins [ladspa-plugin]   1.0.0-2
ii  zam-plugins [ladspa-plugin]   4.1+ds-3

-- no debconf information

Bug#1054657: transition: r-bioc-biocgenerics

[Andreas Tille]

Hi Dirk,

Am Tue, Nov 07, 2023 at 12:28:22PM -0600 schrieb Dirk Eddelbuettel:
> 
> "Kinda. Sorta. Not fully." I have written related code doing most of this
> during the many attempt for 'turning CRAN into .deb packages'.
> ...

Sounds like another idea how this problem can be turned into code
(alternatively we could re-use some code from dh-r or rewrite in
Python to parse previously downloaded DESCRIPTION files).  But all
final code needs time and testing ... which I'd like to avoid (but
for sure working code contributions are welcome).
 
> So for all packages you are interested in (here I look just at
> 'SingleCellExperiment') you construct the BioC (or maybe CRAN and BioC)
> dependencies, and then create an aggregate list of the unique
> combination. Those are the packages you need and apt-cache and related will
> tell you if they exist.

Thanks a lot for your ideas anyway
 Andreas. 

-- 
http://fam-tille.de

Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Alexandre Ferrieux]

On Tue, 7 Nov 2023 16:14:58 + patrick.a...@orange.com wrote:
>
> So it means that the kind of code below in anyone's script will have an
opposite result depending on whether we use dash of the Bookworm version or
dash of the Bullseye version and that this same command interpreted by Bash
or dash will always have an opposite result ? Not at all sure it's serious
>
> - Dash Bullseye and bash
># case "A" in [^A]) echo "character not accepted" ;;esac
>
> - Dash bookworm
># case "A" in [^A]) echo "character not accepted" ;;esac
>character not accepted
>
> thanks for reconsideration,
> Patrick

+1000!

The fact that one year has elapsed with that terrible regression in sid
without any complaint does NOT mean that it is "okay"; it only means that a
huge population of Debian sysadmins only ever stick to stable.
In this huge population, how many might be using #! /bin/sh as a shebang ?
And among them, how many use caret-negation in "case..esac" ?
And within this (still hefty IMO) subset, how many are operating stuff like
nuclear facilities, planes or brain surgery tools ?

Does this perspective make it sound reasonable to break decade-old
semantics in the most central piece of modern software after the Linux
kernel ?

TL;DR: please please please NO, don't freakin' break the Shell !

-Alex

Bug#1055521: opensc: CVE-2023-40660

[Salvatore Bonaccorso]

Source: opensc
Version: 0.23.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opensc.

CVE-2023-40660[0]:
| A flaw was found in OpenSC packages that allow a potential PIN
| bypass. When a token/card is authenticated by one process, it can
| perform cryptographic operations in other processes when an empty
| zero-length pin is passed. This issue poses a security risk,
| particularly for OS logon/screen unlock and for small, permanently
| connected tokens to computers. Additionally, the token can
| internally track login status. This flaw allows an attacker to gain
| unauthorized access, carry out malicious actions, or compromise the
| system without the user's awareness.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-40660
https://www.cve.org/CVERecord?id=CVE-2023-40660
[1] https://github.com/OpenSC/OpenSC/issues/2792#issuecomment-1674806651
[2] https://github.com/OpenSC/OpenSC/wiki/CVE-2023-40660
[3] 
https://github.com/OpenSC/OpenSC/commit/868f76fb31255fd3fdacfc3e476452efeb61c3e7

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1055520: opensc: CVE-2023-4535

[Salvatore Bonaccorso]

Source: opensc
Version: 0.23.0-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for opensc.

CVE-2023-4535[0]:
| An out-of-bounds read vulnerability was found in OpenSC packages
| within the MyEID driver when handling symmetric key encryption.
| Exploiting this flaw requires an attacker to have physical access to
| the computer and a specially crafted USB device or smart card. This
| flaw allows the attacker to manipulate APDU responses and
| potentially gain unauthorized access to sensitive data, compromising
| the system's security.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-4535
https://www.cve.org/CVERecord?id=CVE-2023-4535
[1] https://github.com/OpenSC/OpenSC/wiki/CVE-2023-4535
[2] 
https://github.com/OpenSC/OpenSC/commit/f1993dc4e0b33050b8f72a3558ee88b24c4063b2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1054999: dlt-daemon: FTBFS: 5: /bin/sh: 1: killall: not found

[Guillem Jover]

Control: tag -1 patch

Hi!

On Sun, 2023-10-29 at 06:55:23 +0100, Lucas Nussbaum wrote:
> Source: dlt-daemon
> Version: 2.18.10-5
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231028 ftbfs-trixie

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > 89% tests passed, 1 tests failed out of 9
> > 
> > Total Test time (real) =   6.07 sec
> > 
> > The following tests FAILED:
> >   8 - gtest_dlt_daemon_multiple_files_logging (SIGTRAP)
> > Errors while running CTest
> > make[1]: *** [Makefile:74: test] Error 8
> > make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> > dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j8 test 
> > ARGS\+=--verbose ARGS\+=-j8 returned exit code 2

So the problem is that the test suite is no parallel safe, as various
test cases use the same files under /tmp (!) and incur into race
conditions. The missing killall is not a cause of failure (!), but for
me is what helped me trigger this issue locally. (I'm filing another
report for the /tmp stuff.)

Attached a series of patches that "fix" this (and some of other
cleanups. The only ones needed to workaround this problem are patch 2
and 3. Although ideally the test suite would be made parallel safe by
using different files for each test case.

Thanks,
Guillem
From 509a491ddbb36d8312a0c4db3eb5b0778aa9c7f7 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 7 Nov 2023 18:47:45 +0100
Subject: [PATCH 1/5] Run wrap-and-sort -sat

This makes changes when diffing sources minimal. As a side effect it
also removes a duplicate dependency on libsystemd-dev.
---
 debian/control | 44 ++
 debian/dlt-daemon.install  |  1 +
 debian/dlt-tools.install   |  8 +++
 debian/libdlt-dev.dirs |  2 +-
 debian/libdlt-dev.install  |  2 +-
 debian/libdlt-examples.install |  8 +++
 6 files changed, 45 insertions(+), 20 deletions(-)

diff --git a/debian/control b/debian/control
index 7cf89c9..e9e47b4 100644
--- a/debian/control
+++ b/debian/control
@@ -1,8 +1,19 @@
 Source: dlt-daemon
 Priority: optional
 Maintainer: Aigars Mahinovs 
-Uploaders: Gianfranco Costamagna 
-Build-Depends: debhelper-compat (= 13), cmake, zlib1g-dev, libdbus-1-dev, doxygen, libgtest-dev, libsystemd-dev, pandoc, systemd, libsystemd-dev, libjson-c-dev
+Uploaders:
+ Gianfranco Costamagna ,
+Build-Depends:
+ cmake,
+ debhelper-compat (= 13),
+ doxygen,
+ libdbus-1-dev,
+ libgtest-dev,
+ libjson-c-dev,
+ libsystemd-dev,
+ pandoc,
+ systemd,
+ zlib1g-dev,
 Standards-Version: 4.6.2
 Section: libs
 Rules-Requires-Root: no
@@ -12,7 +23,9 @@ Package: libdlt-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libdlt2 (= ${binary:Version}), ${misc:Depends}
+Depends:
+ libdlt2 (= ${binary:Version}),
+ ${misc:Depends},
 Description: Diagnostic Log and Trace (DLT) library (development)
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -25,7 +38,9 @@ Description: Diagnostic Log and Trace (DLT) library (development)
 Package: libdlt2
 Architecture: any
 Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: Diagnostic Log and Trace (DLT) library
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -37,8 +52,11 @@ Description: Diagnostic Log and Trace (DLT) library
 Package: dlt-daemon
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: dlt-tools
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Suggests:
+ dlt-tools,
 Description: Diagnostic Log and Trace logging daemon
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -55,8 +73,11 @@ Description: Diagnostic Log and Trace logging daemon
 Package: dlt-tools
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: dlt-daemon
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Suggests:
+ dlt-daemon,
 Description: Diagnostic Log and Trace (DLT) (documentation)
  This component provides a log and trace interface, based on the standardised
  protocol specified in the AUTOSAR standard 4.0 DLT. This software can be used
@@ -70,8 +91,11 @@ Description: Diagnostic Log and Trace (DLT) (documentation)
 Package: libdlt-examples
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: dlt-daemon
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Suggests:
+ dlt-daemon,
 Description: Diagnostic Log and Trace (DLT) (documentation)
  This component provides a log and trace interface, based on the standardised
  

Bug#1040416: linux-image-6.1.0-9-amd64: Under heavy load Debian V12 and V11 causes data corruption on XFS filesystems.

[Diederik de Haas]

Control: found -1 6.1~rc3-1~exp1
Control: found -1 6.1.55-1

On Saturday, 4 November 2023 20:35:43 CET Jose M Calhariz wrote:
> > Ok. Please test (when you have time) 6.1.55-1.
> 
> Fail : Linux afs31 6.1.0-0-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.1~rc3-1~exp1 (2022-11-02) x86_64 GNU/Linux
> 
> Fail : Linux afs31 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1
> (2023-09-29) x86_64 GNU/Linux
> 
> Done.  I tested even the first 6.1 on Debian.  Both of them failed.

Thanks, updated metadata accordingly.
So now we know it's indeed present in the whole 6.1 series.

> > Unfortunately there isn't a 6.2 kernel uploaded to the Debian archive and
> > thus not available on snapshot.d.o, but testing 6.3.1-1~exp1 should be
> > useful.

Please test with with 6.3.1-1~exp1 to make sure it was fixed then (too).

Unfortunately, the commit list between 6.1 and 6.3.1 is quite large:
me@pc:~/dev/kernel.org/linux$ git log --oneline v6.1..v6.3.1 -- fs/xfs | wc -l
159

If that list was small, I could've suggested to try 'backporting' a couple of 
patches, but that avenue seems rather pointless in this case.

It's probably also useful to verify whether it's also present in the whole 
5.10 series, which should give (even) more data points.

I think the next step should be to 'forward' this bug report to the upstream 
mailing list at linux-...@vger.kernel.org

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

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Sebastian Andrzej Siewior]

control: tags -1 patch fixed-upstream

On 2023-10-02 17:12:53 [+0200], Julian Andres Klode wrote:
> Being subscribed to the mailing list, grabbing the patch and applying
> it and shipping it isn't hard, but if you were wondering why it's

There are different views here. But Daniel was nice enough to Cc me so I
had all I needed to test it.

> not fixed, it hasn't been merged or received a Reviewed-By yet;
> and I don't really want to carry file system (parser) patches
> outside of upstream for security reasons, needing separate
> revocation if that is broken.

The following patches were merged into grub upstream:
  ad7fb8e2e02bb ("fs/xfs: Incorrect short form directory data boundary check")
  07318ee7e11a0 ("fs/xfs: Fix XFS directory extent parsing")

would you mind to cherry pick those for the next upload?

Sebastian

Bug#981618: libdrm: reduce Build-Depends

[Diederik de Haas]

On Tuesday, 7 November 2023 14:06:23 CET Helmut Grohne wrote:
> On Tue, Nov 07, 2023 at 11:35:28AM +0100, Diederik de Haas wrote:
> > > I am not sure what you mean with heavy-handed here and why that would be
> > > an issue.
> > 
> > Not fully understanding it, it felt like "some tests may be problematic,
> > let's disable all them"
> 
> Do I understand correctly that this no longer is your understanding?

Yep, it adds the option to not do the test and in that case you also don't 
need the build dependency. Thus it doesn't unconditionally disable (all) the 
test, but gives the option/flexibility to do so.

Thinking about it some more, I actually use it myself a lot when building 
kernels. I pretty much always use the 'nodoc' profile, which saves ~1 GB of 
dependencies to install (IIRC, mostly due to texlive-latex-extra).
Or use the 'cross' profile when cross-compiling a kernel.

There's still a lot of magic (to me) involved and I don't fully/properly 
understand how it works (yet), but I do use it.

> > While I'm now less clueless about this then before, I don't feel
> > comfortable enough that I would be able to 'defend' the inclusion of the
> >  annotation, so I won't include that part in the MR I'm working
> > on.
> Fair enough. I can offer you two ways forward. You may add me as
> reviewer, so I can do the defending part if it becomes necessary. The
> correctness of a nocheck build profile can be technically validated. If
> you locally perform a build with and without nocheck and both produce
> the same artifacts (the reproducible bit-identical ense), then that's a
> very strong clue that the dependency wasn't used for building (but maybe
> used for testing). And since "nocheck" really means disabling all tests,
> you're right in thus annotating the dependency.

I actually have now build libdrm locally, but I usually let Salsa's CI do that 
for me. And I'm compiling it on my main PC and have yet to learn how to do it 
with tools like sbuild. It's on my TODO, but I'm not there yet.
I also want to learn tools like diffoscope (I think R-B is amazing), but I 
don't understand (its output) one bit. One day I will, but that will not be in 
the near future.

Did I miss option 2?

Thanks again,
  Diederik


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

Bug#1055519: libsass: Fix hurd-amd64 build

[Samuel Thibault]

Source: libsass
Version: 3.6.5+20220909-3
Severity: important
Tags: patch

Hello,

libsass is missing symbols for hurd-amd64, which are essentially like
the amd64 symbols. The attached patch fixes this.

Samuel

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

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/libsass1.symbols.original2023-11-07 18:56:35.0 +
+++ debian/libsass1.symbols 2023-11-07 18:58:11.0 +
@@ -347,13 +347,13 @@
  _ZN4Sass10SourceFileD2Ev@Base 3.6.4-2~
  
_ZN4Sass10SourceSpanC1ENS_10SharedImplINS_10SourceDataEEERKNS_6OffsetES6_@Base 
3.6.4-2~
  _ZN4Sass10SourceSpanC1EPKc@Base 3.6.4-2~
- (arch=!amd64 !arm64 !hppa !sh4 !x32)_ZN4Sass10SourceSpanC1ERKS0_@Base 
3.6.4+20201122
+ (arch=!any-amd64 !arm64 !hppa !sh4 !x32)_ZN4Sass10SourceSpanC1ERKS0_@Base 
3.6.4+20201122
  
_ZN4Sass10SourceSpanC2ENS_10SharedImplINS_10SourceDataEEERKNS_6OffsetES6_@Base 
3.6.4-2~
  _ZN4Sass10SourceSpanC2EPKc@Base 3.6.4-2~
- (arch=!amd64 !arm64 !hppa !sh4 !x32)_ZN4Sass10SourceSpanC2ERKS0_@Base 
3.6.4+20201122
+ (arch=!any-amd64 !arm64 !hppa !sh4 !x32)_ZN4Sass10SourceSpanC2ERKS0_@Base 
3.6.4+20201122
  _ZN4Sass10SourceSpanD1Ev@Base 3.6.4-2~
  _ZN4Sass10SourceSpanD2Ev@Base 3.6.4-2~
- (arch=!amd64 !arm64 !hppa !sh4 !x32)_ZN4Sass10SourceSpanaSERKS0_@Base 
3.6.4+20201122
+ (arch=!any-amd64 !arm64 !hppa !sh4 !x32)_ZN4Sass10SourceSpanaSERKS0_@Base 
3.6.4+20201122
  _ZN4Sass10StyleSheetC1ERKNS_8ResourceENS_10SharedImplINS_5BlockEEE@Base 
3.6.4-2~
  _ZN4Sass10StyleSheetC1ERKS0_@Base 3.6.4-2~
  _ZN4Sass10StyleSheetC2ERKNS_8ResourceENS_10SharedImplINS_5BlockEEE@Base 
3.6.4-2~
@@ -2514,7 +2514,7 @@
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer22kwd_supports_directiveEPKcS4_bb@Base
 3.6.4-2~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer4hexaEPKcS4_bb@Base
 3.6.4-2~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer6numberEPKcS4_bb@Base
 3.5.5-4~
- (optional=templinst|arch=amd64 hppa hurd-i386 i386 m68k sh4 
x32)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc38EEEPKcS5_S5_bb@Base 
3.6.4-4~
+ (optional=templinst|arch=any-amd64 hppa any-i386 m68k sh4 
x32)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc38EEEPKcS5_S5_bb@Base 
3.6.4-4~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc40EEEPKcS5_S5_bb@Base
 3.5.5-4~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc41EEEPKcS5_S5_bb@Base
 3.5.5-4~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc43EEEPKcS5_S5_bb@Base
 3.5.5-4~
@@ -2523,7 +2523,7 @@
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc58EEEPKcS5_S5_bb@Base
 3.6.4-2~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyILc91EEEPKcS5_S5_bb@Base
 3.6.4-2~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyIXadL_ZNS_9Constants8ellipsisEPKcS6_S6_bb@Base
 3.6.4-2~
- (optional=templinst|arch=!alpha !armel !armhf !hurd-i386 !i386 !mipsel 
!powerpc !ppc64 
!s390x)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyIXadL_ZNS_9Constants8else_kwdEPKcS6_S6_bb@Base
 3.6.4-4~
+ (optional=templinst|arch=!alpha !armel !armhf !any-i386 !mipsel !powerpc 
!ppc64 
!s390x)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7exactlyIXadL_ZNS_9Constants8else_kwdEPKcS6_S6_bb@Base
 3.6.4-4~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer7kwd_andEPKcS4_bb@Base
 3.6.4-2~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer8kwd_nullEPKcS4_bb@Base
 3.6.4-2~
  
(optional=templinst)_ZN4Sass6Parser3lexIXadL_ZNS_8Prelexer8sequenceIXadL_ZNS2_12alternativesIXadL_ZNS2_3hexEPKcEEXadL_ZNS2_4hex0ES6_EEJEEES6_S6_EEXadL_ZNS2_6negateIXadL_ZNS2_7exactlyILc45EEES6_S6_S6_S6_EEJEEES6_S6_S6_bb@Base
 3.6.4-2~
@@ -2944,7 +2944,7 @@
  
(optional=templinst)_ZN4Sass8Prelexer12alternativesIXadL_ZNS0_11end_of_fileEPKcEEXadL_ZNS0_7exactlyILc123EEES3_S3_EEJEEES3_S3_@Base
 3.5.5-4~
  

Bug#1055518: ITP: satdump -- SatDump is a general purpose satellite data processing software.

[Apostolos]

Package: wnpp
Severity: wishlist
Owner: Apostolos 
X-Debbugs-Cc: debian-de...@lists.debian.org, sv1...@raag.org

* Package name: satdump
  Version : 1.1.1
  Upstream Contact: Aang23 
* URL : https://www.satdump.org/
* License : GPL-3.0
  Programming Lang: C, C++
  Description : SatDump is a general purpose satellite data processing 
software.

SatDump is a general purpose satellite data processing software. It is a 
one-stop-shop 
that provides all the necessary stages to get from the satellite transmission 
to actual products

Features

Support of many SDRs such as RTL-SDR, Airspy, HackRF, BladeRF, LimeSDR, 
PlutoSDR, etc.
Recording of radio basebands from your SDR
Decoding and processing the data from over 90 different satellites and even 
space probes.
Live decoding of supported satellite links such as APT, LRPT, HRPT, LRIT, 
HRIT and many more.
Image and data decoding from satellites such as NOAA 15-18-19, Meteor-M, 
GOES, Elektro-L, 
Metop, FengYun, etc.
Calibrated and georefrenced L1b products output on select satellites, such 
as Sea Surface 
Temperature, Microphysics, etc. ready to use for scientific applications 
such as numerical weather 
forecasts.
Support for projecting the satellite imagery over a map, including layering 
with other instruments 
or satellites.
Inmarsat Aero and STD-C EGC messages decoding.
Scheduler and rotator control for automated satellite stations.
Ingestor for automated geostationary weather satellites reception.

Bug#1055463: sysvinit-core: Please entirely remove SysVinit

[Patrik Schindler]

Am 07.11.2023 um 19:50 schrieb Thorsten Glaser :

>> Small but important. A system without (a running) logging daemon is not
> 
> Hmh, but…
> “From bookworm, rsyslog is no longer installed by default.”

I'm solely talking about system upgrades. Which — at last in my world — happen 
much more frequently than new installs.

>> Should I open up another bug report for making o-s-s a hard dependency for 
>> (one of) the SysVinit packages?
> 
> Hm, I don’t know if that would be helpful at the moment. And if SRM need one 
> we could just repurpose/retitle this one, as that would be the better outcome.

OK, thanks for clarifying.

:wq! PoC

Bug#1055463: sysvinit-core: Please entirely remove SysVinit

[Thorsten Glaser]

(getting OT…)

On Tue, 7 Nov 2023, Ottavio Caruso wrote:
>Am Mo., 6. Nov. 2023 um 21:09 Uhr schrieb Axel Beckert :

>> Debian is about choice, not about spoon-feeding users and leaving them
>> without choice in many places like at least one well-known Debian
>> derivative does.

Yeah, I wish.

>You must be stuck at 2004. Debian has been Canonical's changing room since 
>then.

The mksh package is STILL suffering from Canonical’s dash package
and its maintainers and the release managers ignoring RC bugs in
that that prevent mksh from sanely taking over /bin/sh for way
too long ☹

>A: Because it messes up the order in which people normally read text.
>Q: Why is top-posting such a bad thing?
>A: Top-posting.
>Q: What is the most annoying thing in e-mail?

So indeed!

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (429 (458) bugs: 0 RC, 295 (315) I, 134 (143) M, 0 F) + 210
‣ src:dash (87 (101) bugs: 0 RC, 48 (51) I, 39 (50) M, 0 F) + 62 ubu
‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F)
dash has two RC bugs they just closed because they don’t care about quality…

Bug#1055463: sysvinit-core: Please entirely remove SysVinit

[Thorsten Glaser]

On Tue, 7 Nov 2023, Patrik Schindler wrote:

>Reiterating what I've stated in #1055466 in other words… leaving aside
>recommends-are-default, missing recommends IMHO should not half-break a
>system at upgrade time.

Yes… but, again, that was a rather new thing back then.

>> In trixie, o-s-s definitely should be a Depends of one of the
>> packages (sysvinit? sysv-rc? or what?) but it was too late for
>> bookworm, and it only affected users of a small number of packages
>> there, IIRC.
>
>Small but important. A system without (a running) logging daemon is not

Hmh, but…
“From bookworm, rsyslog is no longer installed by default.”
… is in the release notes at least, and the init script thing
is annoying, yeah… but inetutils-syslogd works.

>Should I open up another bug report for making o-s-s a hard dependency
>for (one of) the SysVinit packages?

Hm, I don’t know if that would be helpful at the moment. And
if SRM need one we could just repurpose/retitle this one, as
that would be the better outcome.

Mark, do you already have a plan for this? Talk to SRM and see
whether we can get that Depends into the next point release at
least? Is o-s-s stable enough in bookworm to do that?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1053511: Opened an issue at cups

[Thorsten Alteholz]

On 07.11.23 17:55, Debian wrote:


Is it possible to get somewhere the packages before the upgrade?


https://snapshot.debian.org/  might help you.

Bug#1055517: opensysusers: modifies host system instead of target environment

[Ansgar]

Package: opensysusers
Version: 0.7.3-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

opensysusers doesn't really implement the `--root` option (though it
pretends a bit).  Functions like `add_group` always access
`/etc/group` and use tools like `groupadd`:

```sh
grep -q "^$1:" /etc/group || groupadd -r "$1"
```

So they will always modify the host system, even when supposed to
operate on some chroot environment.

Applying changes intended for some other environment to the host
system looks like a potential security issue.

AFAIR there are other incompatibilities with systemd-sysusers so that
opensysusers should arguably not claim to be a compatible drop-in
replacement.

Ansgar

Bug#1054657: transition: r-bioc-biocgenerics

[Dirk Eddelbuettel]

On 7 November 2023 at 14:58, Andreas Tille wrote:
| Do you see any way to answer the question that is discussed in this
| thread by r2u how to know whether new Bioconductor packages might have
| new dependencies not yet packaged for Debian?

"Kinda. Sorta. Not fully." I have written related code doing most of this
during the many attempt for 'turning CRAN into .deb packages'.

I.e. when I recompile BioC packages in r2u as I did this weekend I start from
all BioC packages I have already built within r2u (same for you here for a
'within Debian' check), use available.packages() etc to get the package
database (in the R sense) and use that to map out dependencies.  In my case I
sort strip off CRAN (already built) and base R packages to get a count of
'pure BioC depends'. I then sort and first build all of these with a
dependency count of zero, refresh the index so that these become available,
then all with a count of one and so. (Max count this weekend was 41.)

The one step I did not do (as I didn't need it) was to check 'is package X
already available'. When it wasn't I just built it :) But you can do all that
from either shell into apt-cache, or R via my RcppAPT package, or via
python-apt and friends.

My code is in R with use of data.table for the mangling so it is somewhat
'internal'. It is based on R's own 'tools::package_dependencies()'. There
must also be suitable code in R itself which I never pulled out because R can
run a package's reverse dependencies.  But anyway here is a minimal sketch
using R and its data.table package.

> AP <- suppressMessages( data.table(available.packages(repos = 
> BiocManager::repositories())) )
> AP[, lcpkg := tolower(Package)]
> basePkgs <- c("base", "class", "codetools", "datasets", "graphics", "grid", 
> "lattice",
+ "Matrix", "mgcv", "nnet", "rpart", "splines", "stats4", "tcltk", 
"translations",
+ "boot", "cluster", "compiler", "foreign", "grDevices", "KernSmooth", "MASS",
+ "methods", "nlme", "parallel", "spatial", "stats", "survival", "tools", 
"utils")
> cranPkgs <- AP[Repository=="https://cloud.r-project.org/src/contrib;, Package]
> biocPkgs <- AP[Repository!="https://cloud.r-project.org/src/contrib;, Package]
> 
> pkg <- "SingleCellExperiment"
> deps <- tools::package_dependencies(pkg, AP, recursive=TRUE)[[1]]
> nAll <- length(deps)
> nBase <- length(intersect(deps, basePkgs))
> nCran <- length(intersect(deps, cranPkgs))
> nBioc <- length(intersect(deps, biocPkgs))
> 
> intersect(deps, biocPkgs)
 [1] "SummarizedExperiment" "S4Vectors""BiocGenerics" 
"GenomicRanges"   
 [5] "DelayedArray" "MatrixGenerics"   "IRanges"  
"S4Arrays"
 [9] "GenomeInfoDb" "XVector"  "Biobase"  
"GenomeInfoDbData"
[13] "zlibbioc"
> 

So for all packages you are interested in (here I look just at
'SingleCellExperiment') you construct the BioC (or maybe CRAN and BioC)
dependencies, and then create an aggregate list of the unique
combination. Those are the packages you need and apt-cache and related will
tell you if they exist.

Dirk

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

Bug#1040373: collecting info so far

[Michael Tokarev]

On Mon, 06 Nov 2023 12:41:27 -0500 Andres Salomon  wrote:
On Thu, 2 Nov 2023 13:54:44 +0300 Michael Tokarev  
wrote:
 > Control: retitle -1 lsof does not work correctly with btrfs 
subvolumes

 >
 > So it turned out the whole thing is about btrfs subvolumes.
 >

I'm wondering if this is a regression in lsof (ie, did it begin with 
bookworm's lsof), or has it been there all along? An easy way to test 
this would be to rebuild bullseye/oldstable's lsof on bookworm, install 
it on your machine with that subvolume, and see if it does the same 
thing.


No, this is not a regression. It is a property of btrfs and zfs - both
support multiple devices behind a single filesystem and both support
multiple filesystem roots, so there's no 1:1 device:filesystem mapping
anymore.  It's been this way for multiple debian releases.

See also:

https://unix.stackexchange.com/questions/345220/btrfs-how-to-get-real-device-id
http://www.sabi.co.uk/blog/21-two.html?210804#210804 (linked to from above)
https://github.com/util-linux/util-linux/issues/2349#issuecomment-1615854709

/mjt

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[James McCoy]

On Tue, Nov 07, 2023 at 10:35:56PM +0530, Nilesh Patra wrote:
> There's a patch in[1] that gets things moving.
> 
> @James: Since you agreed to maintain this package as I offer my help for
> the go stuff, do you think it makes sense to convert this into an RFH
> instead of RFA/ITA?

That offer was in the absence of someone else willing to take over
primary maintenance.  If Maytham is willing to do that, then maybe
Mytham can work with you to maintain it going forward?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1053511: Opened an issue at cups

[Debian]

Please refer to https://github.com/apple/cups/issues/6155

A solution is needed now. A desktop PC without printer is unusable.

Is it possible to get somewhere the packages before the upgrade?

How it is possible to install packages of cups from Debian 10?

Bug#1055516: python3-jsonschema: New upstream version available

[Roland Mas]

Package: python3-jsonschema
Version: 4.10.3-1
Severity: wishlist

Dear Maintainer,

There's a new upstream version (4.19) available, with at least one
change in API (in the Draft*Validator constructors); jupyter-events, a
package I'm working on, uses the new API, and therefore fails to run
with the current 4.10 version.

Could you provide an updated package?

Thanks,

Roland.

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

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

Versions of packages python3-jsonschema depends on:
ii  python3 3.11.2-1+b1
ii  python3-attr22.2.0-1
ii  python3-importlib-metadata  4.12.0-1
ii  python3-pyrsistent  0.18.1-1+b3
ii  python3-typing-extensions   4.4.0-1

Versions of packages python3-jsonschema recommends:
ii  python3-idna  3.3-1
ii  python3-json-pointer  2.3-2
ii  python3-rfc3987   1.3.8-2
ii  python3-uritemplate   4.1.1-2
ii  python3-webcolors 1.11.1-1

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

-- no debconf information

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Tue, 07 Nov 2023 16:33:42 +0800 Maytham Alsudany  
wrote:
> I'd like to adopt the kitty package if that's ok.
> 
> I've been able to upgrade the package to the latest version and get the
> Go part of the package to build successfully (the new 'kittens'
> feature). My efforts can be found at
> https://salsa.debian.org/Maytha8/kitty

Looks like we ended up with some duplicate effort here.

I tried avoiding:

| mkdir -p $(BUILDDIR)/src
| ln -s /usr/share/gocode/src/* $(BUILDDIR)/src
| ln -s $(CURDIR) $(BUILDDIR)/src/kitty

With the call to go-specific dh_auto_configure. I did some other changes of
similar sort on the lines of dh-golang toolchain as well.

However your changes to setup.py are probably more sensible than mine :)

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1055515: ldc: diff for NMU version 1:1.35.0-1.1

[Gianfranco Costamagna]

Package: ldc
Version: 1:1.35.0-1
Severity: normal
Tags: patch

Dear maintainer,

I found the application FTBFS if bash-completion is installed due to a wrong 
check and assumption
about its presence on CMakeLists.txt.

I propose to add the dependency and let cmake do the correct job, resulting in 
a simplification of install target


diff -Nru ldc-1.35.0/debian/changelog ldc-1.35.0/debian/changelog
--- ldc-1.35.0/debian/changelog 2023-11-04 18:40:54.0 +0100
+++ ldc-1.35.0/debian/changelog 2023-11-07 16:15:22.0 +0100
@@ -1,3 +1,9 @@
+ldc (1:1.35.0-1.1) unstable; urgency=medium
+
+  * Add bash-completion dependency to let cmake helper do the right job 
(Closes: #-1)
+
+ -- Gianfranco Costamagna   Tue, 07 Nov 2023 
16:15:22 +0100
+
 ldc (1:1.35.0-1) unstable; urgency=medium

   [ Matthias Klumpp ]
diff -Nru ldc-1.35.0/debian/control ldc-1.35.0/debian/control
--- ldc-1.35.0/debian/control   2023-11-04 18:40:54.0 +0100
+++ ldc-1.35.0/debian/control   2023-11-07 16:15:22.0 +0100
@@ -4,7 +4,8 @@
 Maintainer: Debian D Language Group 
 Uploaders: Konstantinos Margaritis ,
Matthias Klumpp 
-Build-Depends: cmake,
+Build-Depends: bash-completion,
+   cmake,
debhelper-compat (= 12),
dh-exec,
gdmd,
diff -Nru ldc-1.35.0/debian/ldc.install ldc-1.35.0/debian/ldc.install
--- ldc-1.35.0/debian/ldc.install   2022-08-12 18:36:13.0 +0200
+++ ldc-1.35.0/debian/ldc.install   2023-11-07 16:15:20.0 +0100
@@ -1,4 +1,4 @@
-etc/bash_completion.d/*usr/share/bash-completion/completions/
+usr/share/bash-completion/completions/
 etc/ldc2.conf
 usr/bin/*
 usr/lib/ldc_rt.dso.o


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055514: opensysusers: ineffective diversion of /bin/systemd-sysusers due to /usr-merge and DEP17

[Helmut Grohne]

Package: opensysusers
Version: 0.7.3-2
Severity: serious
Tags: patch
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + systemd

Hi,

opensysusers diverts /bin/systemd-sysusers. systemd has moved this file
to /usr/bin/systemd-sysusers in version 255~rc1-1. While this change is
not visible in an installation, the diversion no longer matches it. Thus
what ends up at systemd-sysusers now depends on the order of unpacks.
The diversion has become ineffective. This is a known problem category
and documented in DEP17[1] as P3.

Usually, the recommended mitigation for this kind of problem is
duplicating the diversion (M18) such that both /bin/systemd-sysusers and
/usr/bin/systemd-sysusers are diverted. I'm attaching a patch for this
approach, but I think this is not the preferred solution for this case.

I dug deeper as to why opensysusers would divert systemd-sysusers,
talked to systemd maintainers and Thomas Goirand and read about #947847
in the process. Given this background, I believe that the use of a
diversion is not a good solution and this was echoed by the CTTE
decision, which declined to overrule and considered diversion a
mechanism for experimentation. Three years later and with two stable
releases including opensysusers I hope we are past the experimentation
phase. The diversion setup bears a significant downside: While the API
existing API of the sysusers interface is relatively stable, systemd
keeps adding features and when systemd calls systemd-sysusers it wants
to be able to rely on its latest features. A diverted systemd-sysusers
may not provide what is needed here. Looking deeper into policy sections
7.4 and 7.5, the virtual package systemd-sysusers looks similar to
mail-transport-agent where each implementation
provides+conflicts+replaces mail-transport-agent. I think opensysusers
should do the same. Once doing so, the diversion (and thus this bug)
goes away entirely. The downside is that opensysusers and systemd are no
longer coinstallable. I'm also attaching a patch for this.

I caution that Thomas Goirand disagrees with this approach and
recommends that these packages remain coinstallable and that users may
choose the implementation. On the flip side, a user cannot choose to
have systemd as the provider of systemd-sysusers when opensysusers is
installed.

A possible compromise could be that opensysusers stops diverting
systemd-sysusers and installs the symbolic link without diversion such
that systemd becomes the preferred provider when coinstalled. It could
detect removal of systemd using file triggers and then reinstate the
link. Such a setup also requires little cooperation from systemd
maintainers, but it relies on an symbolic link that is completely
untracked by dpkg, so there is some fragility to be found here whereas
the conflict is conceptually simpler.

In any case, something needs to be done here. The latest systemd upload
now declares an unversioned conflict with opensysusers. It can become
versioned once opensysusers has addressed this bug in some way.

Helmut

[1] https://subdivi.de/~helmut/dep17.html
diff --minimal -Nru opensysusers-0.7.3/debian/changelog 
opensysusers-0.7.3/debian/changelog
--- opensysusers-0.7.3/debian/changelog 2022-11-20 16:18:16.0 +0100
+++ opensysusers-0.7.3/debian/changelog 2023-11-07 08:38:13.0 +0100
@@ -1,3 +1,11 @@
+opensysusers (0.7.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Duplicate diversion to mitigate DEP17 P3 via M18. (Closes: #-1)
+  * Move to /usr.
+
+ -- Helmut Grohne   Tue, 07 Nov 2023 08:38:13 +0100
+
 opensysusers (0.7.3-2) unstable; urgency=medium
 
   * d/preinst: remove -u option.
diff --minimal -Nru opensysusers-0.7.3/debian/opensysusers.links 
opensysusers-0.7.3/debian/opensysusers.links
--- opensysusers-0.7.3/debian/opensysusers.links2022-11-20 
16:11:31.0 +0100
+++ opensysusers-0.7.3/debian/opensysusers.links2023-11-07 
08:38:13.0 +0100
@@ -1 +1 @@
-/usr/bin/opensysusers-sysusers   /bin/systemd-sysusers
+/usr/bin/opensysusers-sysusers   /usr/bin/systemd-sysusers
diff --minimal -Nru opensysusers-0.7.3/debian/opensysusers.lintian-overrides 
opensysusers-0.7.3/debian/opensysusers.lintian-overrides
--- opensysusers-0.7.3/debian/opensysusers.lintian-overrides2022-11-20 
16:11:31.0 +0100
+++ opensysusers-0.7.3/debian/opensysusers.lintian-overrides2023-11-07 
08:38:13.0 +0100
@@ -4,4 +4,6 @@
 # Creating sysusers.d is intentional
 opensysusers: package-contains-empty-directory [usr/lib/sysusers.d/]
 # The manpage is provided by the systemd package
-opensysusers: no-manual-page [bin/systemd-sysusers]
+opensysusers: no-manual-page [usr/bin/systemd-sysusers]
+# DEP17 M18 not recognized by lintian
+opensysusers: diversion-for-unknown-file bin/systemd-sysusers [preinst:*]
diff --minimal -Nru opensysusers-0.7.3/debian/opensysusers.postrm 
opensysusers-0.7.3/debian/opensysusers.postrm
--- opensysusers-0.7.3/debian/opensysusers.postrm

Bug#1055347: ITA: kitty -- fast, featureful, GPU based terminal

[Nilesh Patra]

On Tue, 07 Nov 2023 16:45:18 +0800 Maytham Alsudany  
wrote:
> Hi,
> 
> Firstly, I'd like to apologise for the duplicate mail, which was an
> accident on my part.
> 
>OTOH, I did take a look at the errors and I see two ways. Either >
>patch out all the go build related code and use debian's go build
>toolchain (which takes care of a bunch of things) or hack around the
>way upstream builds to somehow fit out usecase (this is consuming
>quite some cycles).
> 
> I'll outline what method I've used:
> 
> What I've done is setup all the correct environment variables for the
> Go compiler, as well as patch the setup.py file to work with
> GO111MODULE=off. (I did this by looking at the dh-golang source code
> and copying what it does.)
> 
> I'm worried about using dh-golang directly, since passing --
> buildsystem=golang may break the other parts of the build.

There's a patch in[1] that gets things moving.

@James: Since you agreed to maintain this package as I offer my help for
the go stuff, do you think it makes sense to convert this into an RFH
instead of RFA/ITA?

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037440#37
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055347#19

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1049388: rust-rusqlite: Please upgrade to v0.29

[Peter Green]

Please upgrade to (or separately provide) newer upstream branch v0.29.


Preliminary analysis looks pretty good in general, but parsec-service
has some issues with it's migration to testing that need to be sorted
before going ahead with this in unstable. I've just made some uploads
that will hopefully sort them, but may need to wait a while to see if
they have worked due to the mips64el buildd issues.

One of the rdeps "settle" is yours, i've done a test build and it
seems to build fine after updating the dependency. Ive uploaded the
new rusqlite to experimenta. Feel free to do any further testing.

Bug#1054657: transition: r-bioc-biocgenerics

[Andreas Tille]

Hi Sebastian,

Am Tue, Nov 07, 2023 at 03:12:39PM +0100 schrieb Sebastian Ramacher:
> > Charles and I tried to explain in different ways: We do not have simple
> > means to answer this question.
> 
> Picking a random r-bioc-* package:
> https://salsa.debian.org/r-pkg-team/r-bioc-aroma.light/-/blob/master/DESCRIPTION
> has an "Imports" field. Those are mapped to dependencies in the package.
> So I presume that when importing those packages into the packaging
> repository, changes to this field can be identified and checked. I would
> excpect this information to be enough to identify any currently missing
> packages.

Well, I'm one of the authors of dh-r.  I know where to find the
dependencies since we are parsing this file.  We even go further:  When
trying to build an R package and find a missing dependency this will be
nearly ready packaged automatically.  This is NOT the problem.  The
point is that this workflow is completely automated.  Parsing 170
DESCRIPTION files of not yet packaged versions is not automated and thus
quite some manual work.  And I would really like to hear better reasons
why you want us to do this manual work in addition to something which is
done automatically.
 
> > But I had a different question;  What
> > exactly is the problem of a transition taking about 1 month due to some
> > delay by waiting for packages in new?
> >  
> > I somehow have the feeling that this transition is currently delayed by
> > some bug-mail / tagging ping-pong which is demotivating for both sides.
> > You make a request to some volunteers to do some extra work that was not
> > requested before and we volunteers explained that it is really hard
> > work.  I think it is fair to ask for the reasons you want us to do some
> > work which is definitely hard to do and for us painful and unproductive.
> 
> We should have requested this information for all transitions in the
> past. We did not and thus had the same problems for the last couple of
> transitions including missing packages and a significant number of
> autopkgtest regressions.

The autopkgtest regressions are not caused due to missing new packages.
They are mostly due to issues on some architectures.  We can stop those
by restricting Bioconductor packages to those tested by upstream by
loosing the advantages Debian provides to the community.  In fact
dealing with the regressions has taken us usually longer than the
missing packages.  I'm not proud on it that it takes so long to deal
with the regressions but cutting from our time constraints even more
will not help at all.
 
> The r-bioc-* transition is special in the sense that it requires all
> involved packages to be ready to migrate at the same time. This is where
> delays become an issue. It essentially blocks all other transitions that
> could potentially overlap (e.g., auto-hdf5) from being started or
> progressing.

We can wait until auto-hdf5 transition is done.
 
> All of that binds resources on our side to track down the remaining bits
> and pieces to make everything migrate at the same time. This is usually
> not an issue with a typical shared library transition. Hence we are
> asking you to identify possible NEW packages that will be required to
> complete the transition.

You did not yet answered the question I asked twice whether we can find
a compromise by simply removing packages with missing new dependencies
from testing.  I consider this a compromise which I would really love to
discuss honestly.

I try to repeat:  Please trust me that finding those packages is not as
simple as picking a random DESCRIPTION.  We need time for it, time were
other packages (RC bugs, autopkgtest regressions etc. are suffering).
I'm not yet convinced that we should do this extra work for a couple of
days win.  If you insist on your position I will escalate the issue to
the technical committee.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"

[Christoph Berg]

Re: Gregor Riepl
> > During boot, I get a warning about a missing username "ultimaker".

> @myon, could we release a backported fix to bookworm, or should we leave it
> as it is? I don't have much experience with stable packaging policies.

Since it's just a warning, I wouldn't touch it. Stable updates are
possible, but need poking the stable release managers who have more
interesting problems to fix.

Christoph

Bug#1032104: Status update

[Timothy Pearson]

I have traced this to a regression in the Linux kernel.  The issue appears to 
be a type of data race that is more likely to occur on ppc64el than on other 
architectures, but is also likely to affect other architectures.  The issue 
remains in the latest GIT version of the Linux kernel, and I am working with 
both upstream and our internal resources to try to isolate the root cause and 
generate a fix.

In the interim, disabling the io_uring subsystem will allow mariadb to function 
normally.  Given the nature of the kernel bug, I would recommend disabling 
io_uring entirely in the kernel configuration for affected systems, as other 
applications may also be impacted by the data corruption.

Bug#1055513: asciio: ITP for asciio package, package was removed

[nadim]

Package: asciio
Severity: normal
Tags: d-i

Dear Maintainer,

I'm the author of Asciio, which debian package was removed 2 years ago.
It did use the deprecated GTK2 so it was a good thing.

https://tracker.debian.org/pkg/asciio

Asciio is back, It's been ported to a GTK3 and a prototype terminal
interface has been added.

The module is still on CPAN but it now has a repo at
https://github.com/nkh/P5-App-Asciio.


I just released version 1.9.02 which I tested in a container with
debian and ubuntu, which uses debian packages if I am not wrong. Apart
from the list of modules App:Ascii needs, make and gcc are also
required for modules that contain XS code.

The installation procedure is at
https://github.com/nkh/P5-App-Asciio#install. I've tried to use as
many debian packages as possible. Data::Tree::Dumper::GTK exists in the
debian package repo but it's a GTK2 version so a new version is needed
till it's also updated in the debian repo.


Could you please re-introduce the package?

Cheers, Nadim.

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

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

Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[patrick . anat]

Hi,

On Thu, 13 Apr 2023 11:48:10 +0200 Paul Gevers  wrote: 
> Control: clone -1 -2 
> Control: reassign -2 release-notes 
> 
> On 12-04-2023 16:57, Santiago Ruano Rincón wrote: 
> > If the current behaviour 
> > would be part of bookworm, a NEWS entry would be great. 
> 
> And a release note would be worth it too I guess. 
> 
> Paul 

So it means that the kind of code below in anyone's script will have an 
opposite result depending on whether we use dash of the Bookworm version or 
dash of the Bullseye version and that this same command interpreted by Bash or 
dash will always have an opposite result ? Not at all sure it's serious

- Dash Bullseye and bash
   # case "A" in [^A]) echo "character not accepted" ;;esac

- Dash bookworm
   # case "A" in [^A]) echo "character not accepted" ;;esac
   character not accepted

thanks for reconsideration,
Patrick

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Bug#1055468: [3dprinter-general] Bug#1055468: python3-charon: Warning during boot about "Unknown username "ultimaker" in message bus configuration file"

[Gregor Riepl]

Hi Dave,


During boot, I get a warning about a missing username "ultimaker". As far as I 
can tell this stems from the dbus configuration file packaged with python3-charon 
(/usr/share/dbus-1/system.d/nl.ultimaker.charon.conf) (I don't think it's the systemd 
configuration file that mentions the same user (/lib/systemd/system/charon.service), as 
I'm running Devuan with OpenRC).
I guess the easy fix for this would be to add the username - maybe that should 
be part of the package installation scripts though?


Actually, this should no longer be an issue and is fixed in 
python3-charon 5.0.0-4. But we didn't backport it, so it still affects 
Cura in bookworm.


We have confirmation from Ultimaker that the daemon/dbus/systemd stuff 
in libCharon is only used on Ultimaker devices and shouldn't even be 
installed with Cura: https://github.com/Ultimaker/libCharon/issues/45


@myon, could we release a backported fix to bookworm, or should we leave 
it as it is? I don't have much experience with stable packaging policies.


Regards,
Greg

Bug#1055022: bullseye-pu: package distro-info-data/0.51+deb11u5

[Stefano Rivera]

Hi David (2023.11.03_18:59:13_+0200)
> Short version:
> Would you consider modifying this bullseye-pu for
> distro-info-data/0.51+deb11u5 into a bullseye-pu for a
> distro-info-data/0.59~deb11u1 instead?

That may make more sense in the future. But in the past, it wasn't
really an option, and consistency is useful.

We have had some format changes in the last few years that have made new
versions not as backportable as one would have hoped. And data changes
that broke test suites in other packages.

Both of these were addressed in the most recent round of updates. So,
the data should be fully backportable right now (provided sufficient
Breaks).

> I recently independently discovered Debian bug #711238[2] with
> devscripts and I would would like to see it fixed in unstable and
> my desired fix of adding to it a Build-Depends on
> ```
> distro-info-data (>= 0.58~) 
> ```

I don't really see the point in bumping Build-Depends like that. You
aren't requiring any format change or anything like that, just a version
that has the *current* stable (or development, not sure of the specifics
of that bug) versions.

We ensure that distro-info-data is kept up to date in all supported
releases.

Probably devscripts should become a little more tolerant about outdated
data?

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1055512: RM: python-pypowervm -- ROM; Not maintained upstream, not needed anymore, buggy, no reverse depends

[Thomas Goirand]

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

Hi,

Upstream support for pypowervm was dropped in OpenStack Nova (ie: compute),
and therefore, we don't need this package in Debian anymore too. Let's
remove it.

Cheers,

Thomas Goirand (zigo)

Bug#1055504: ITP: laz-perf -- LAZperf is an alternative LAZ (Compressed LAS pointclouds) decoding implementation.

[Richard Duivenvoorde]

Hi Gürkan,

Just found out that LAZperf is not a dependency of PDAL because sources in 
taken into PDAL itself.

But I'm still interested in trying to package LAZperf itself too, IF others 
think it is useful.

If you say: "I prefer uploads to mentors.d.n" do you mean NOT in the science 
packaging team or do you mean something else?
Reason I choose science packaging team is because the former package of PDAL 
proposed that.

I'm very green in this, so please bare with me

Regards,

Richard Duivenvoorde

On 11/7/23 15:33, Gürkan Myczko wrote:

I would be great to help, cloudcompare seems to support it. Find me as tarzeau_ 
on irc
I prefer uploads to mentors.d.n

Maybe you find something useful at
Index of /debian/laz-perf/ 
sid.ethz.ch 







On Nov 7, 2023, at 14:54, Richard Duivenvoorde  wrote:

Package: wnpp
Severity: wishlist
Owner: Richard Duivenvoorde 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name    : laz-perf
 Version : 3.4.0
 Upstream Contact: Howard Butler 
* URL : https://github.com/hobuinc/laz-perf
* License : APLv2
 Programming Lang: C, C++, C#, Python
 Description : LAZperf is an alternative LAZ (Compressed LAS pointclouds) 
decoding implementation.

It supports compilation to WASM via Emscripten so that LAZ data can be decoded 
in a browser.
LAZperf is a dependecy for the PDAL library (https://github.com/PDAL/PDAL/).
PDAL can be used as a library for QGIS (https://qgis.org) to be able to 
read/analyze point clouds.

I'm planning to maintain both LAZperf and PDAL with the science packaging team.

If I'm correct I'm also looking for a sponsor. But I'm very new to Debian 
packaging, so every help is appreciated

Regards,

Richard Duivenvoorde

Bug#1055511: progress-linux-container: diversions need to be updated to deal with DEP17 P3

[Luca Boccassi]

Package: progress-linux-container
Severity: serious
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + systemd-sysv

Dear Maintainer(s),

systemd-sysv 255~rc1-3, currently in experimental, moves
halt/poweroff/reboot/shutdown from /sbin/ to /usr/sbin/, and thus
diversions employed by this package fall afoul of DEP17 P3. Please
update the diversions as needed. For now, systemd-sysv has an
unversioned conflict to avoid data losses. This will be uploaded to
unstable this week. As soon as a fixed version of this package is
uploaded, the conflict will be changed to versioned.

For more details, see:

https://subdivi.de/~helmut/dep17.html
https://subdivi.de/~helmut/dumat.yaml

-- 
Kind regards,
Luca Boccassi


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