date:20220622

Package: wnpp
Severity: normal
X-Debbugs-Cc: Matrix Packaging Team 
, Debian Qt/KDE Maintainers 

Control: affects -1 src:matrix-mirage

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I intend to orphan the matrix-mirage package.

The package description is:
 Mirage is a fancy, customizable, keyboard-operable chat client
 for the Matrix protocol,
 written in Qt/QML and Python.
 .
 Notable Matrix features supported:
  * Markdown parsing when sending messages
  * End-to-end encryption
  * Multiple concurrent accounts
  * Session administration
  * Room administration
 .
 Notable Matrix features missing:
  * Communities (a.k.a. groups of rooms)
  * Audio/video chat
 .
 Matrix is an open, federated communications protocol.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK0DRoACgkQLHwxRsGg
ASHqpQ//T6NfeFXCmQAprWBCkEvPwfdmFFUmsSH9Y+UribdF2bY1TttFSCsuX82e
DJClBj2eV4k05QDlPC5T0L3k3b8sAzQducg9g6HnOH6vkd9QPQBfxJFq97CIB9UX
n8/URgpib853hPb95CxMQ1i9Y1DmZvnjH69iyXfbLYP1sIcz1kub6+/WbxVBPXiL
0DojZNW3pBpLlAtlS2K39N/jyFOLeaTpaIe0YPO1+fsAlE2UY6xPWRWQjDGCuqg8
QRYTcBUi3vP3plSNFUDdHnhwOIaRb4e/vRMkjVoCmOYGvPUe3R26d/hxy/gJa7du
1qoB65I4TlXJ4v7DAPKbDZ5x4Lv2eoCgd06eNhXOwEb43Md1acjAVk1DPopx1KmD
Qe+3HfbNLbiMoyYtLJ5roRO8Cz7yN/PHHmbtpZqasxm9fvmKgTtvvpMkBcg1ONCy
JAvrWNfydcHFFFwBCrKol2vgioCFmNpt1fzveSMAUGYhtmr7U6ZfYoH+7LpykPQc
atbHuusbh8CAZN6IF8zrmTSMDPgVI2Bl+n+sIR6nqTjMp1mVEZDQM2je4wsMwItw
g0FrXpeFtxIeFc6uJU1cULtCuUbziBmTWxd8FEeWyQJf45NDsRvW2kuM8fuqX33m
wb3yMxpaSN2oP0LCNYVlEgjikPKQzjCNNBTmass90zWtkbwEKOo=
=XTWy
-END PGP SIGNATURE-

Bug#1013408: macsyfinder: FTBFS with Sphinx 5.0, docutils 0.18: dh_auto_test: error: pybuild --test -i python{version} -p 3.10 returned exit code 13

Source: macsyfinder
Version: 2.0~rc7-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

macsyfinder fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3,sphinxdoc --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:239: python3.10 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:239: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/package.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/solution.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/model.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/definition_parser.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/report.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/model_conf_parser.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/hit.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/profile.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/registries.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/gene.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/system.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/cluster.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/config.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/serialization.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/search_genes.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/database.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/error.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> copying macsypy/utils.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy
> creating /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/__init__.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/macsydata.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/macsyfinder.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/macsyprofile.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/macsy_gembase_split.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/macsy_merge_results.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
> copying macsypy/scripts/macsyconfig.py -> 
> /<>/.pybuild/cpython3_3.10/build/macsypy/scripts
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:239: python3.10 setup.py test 
> running test
> WARNING: Testing via this command is deprecated and will be removed in a 
> future version. Users looking for a generic test entry point independent of 
> test runner are encouraged to use tox.
> running egg_info
> creating MacSyFinder.egg-info
> writing MacSyFinder.egg-info/PKG-INFO
> writing dependency_links to MacSyFinder.egg-info/dependency_links.txt
> writing entry points to MacSyFinder.egg-info/entry_points.txt
> writing requirements to MacSyFinder.egg-info/requires.txt
> writing top-level names to MacSyFinder.egg-info/top_level.txt
> writing manifest file 'MacSyFinder.egg-info/SOURCES.txt'
> reading manifest file 'MacSyFinder.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no previously-included files matching '*' found under directory 
> 'data'
> warning: no files found matching '*' under directory 'doc/build/html'
> warning: no files found matching 'doc/build/latex/macsyfinder.pdf'
> warning: no files found matching 'etc/macsyfinder.conf'
> warning: no previously-included files matching '*' found under directory 
> 'tests/__pycache__/'
> warning: no previously-included files found matching 'tests/__init__.pyc'
> warning: no previously-included files found matching '.coverage'
> warning: no previously-included files found matching 'coverage_html/'
> warning: no previously-included files found matching '.gitignore'
> warning: no previously-included files found matching '.travis.yml'
> warning: no files found matching 'CONTRIBUTORS'
> warning: no files found matching 'NEWS'
> adding license file 'COPYING'
> writing manifest file 'MacSyFinder.egg-info/SOURCES.txt'
> running build_ext
> test_Config (test_Config.TestConfig) ... ok
> test_Config_args (test_Config.TestConfig) ... ok
> test_Config_conf_file_virtualenv (test_Config.TestConfig) ... ok
> test_Config_default_conf_file (test_Config.TestConfig) ... ok
> test_Config_file_bad_values (test_Config.TestConfig) ... ok

Bug#1013406: python-os-api-ref: FTBFS with Sphinx 5.0, docutils 0.18: FAIL: os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_response

Source: python-os-api-ref
Version: 2.1.0+ds1-4
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-os-api-ref fails to build with Sphinx 5.0 and docutils 0.18, both of 
which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> pkgos-dh_auto_test --no-py2
> + PKGOS_USE_PY2=yes
> + PKGOS_USE_PY3=yes
> + PKGOS_TEST_PARALLEL=yes
> + PKGOS_TEST_SERIAL=no
> + PYTHONS=disabled
> + PYTHON3S=disabled
> + TEST_PARALLEL_OPT=--parallel
> + TEST_SERIAL_OPT=
> + PKGOS_USE_PY2=no
> + shift
> + [ no = yes ]
> + [ yes = yes ]
> + py3versions -vr
> + PYTHON3S=3.9 3.10
> + [ yes = no ]
> + [ no = yes ]
> + [ disabled = disabled ]
> + continue
> + [ 3.9 = disabled ]
> + echo 3.9
> + cut -d. -f1
> + PYMAJOR=3
> + echo ===> Testing with python (python3)
> ===> Testing with python (python3)
> + [ 3 = 3 ]
> + pwd
> + [ -d /<>/debian/tmp/usr/lib/python3/dist-packages ]
> + [ -e .stestr.conf ]
> + [ -x /usr/bin/python3-stestr ]
> + STESTR=stestr
> + rm -rf .stestr
> + PYTHON=python3.9 stestr run --parallel --subunit
> + subunit2pyunit
> os_api_ref.tests.test_os_api_ref.TestOs_api_ref.test_something
> os_api_ref.tests.test_os_api_ref.TestOs_api_ref.test_something ... ok
> os_api_ref.tests.test_microversions.TestMicroversions.test_js_declares
> os_api_ref.tests.test_microversions.TestMicroversions.test_js_declares ... ok
> os_api_ref.tests.test_basic_example.TestBasicExample.test_expand_all
> os_api_ref.tests.test_basic_example.TestBasicExample.test_expand_all ... ok
> os_api_ref.tests.test_microversions.TestMicroversions.test_mv_selector
> os_api_ref.tests.test_microversions.TestMicroversions.test_mv_selector ... ok
> os_api_ref.tests.test_basic_example.TestBasicExample.test_parameters
> os_api_ref.tests.test_basic_example.TestBasicExample.test_parameters ... FAIL
> os_api_ref.tests.test_warnings.TestWarnings.test_empty_parameter_file
> os_api_ref.tests.test_warnings.TestWarnings.test_empty_parameter_file ... ok
> os_api_ref.tests.test_microversions.TestMicroversions.test_rest_method
> os_api_ref.tests.test_microversions.TestMicroversions.test_rest_method ... ok
> os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method
> os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_method ... ok
> os_api_ref.tests.test_warnings.TestWarnings.test_invalid_parameter_definition
> os_api_ref.tests.test_warnings.TestWarnings.test_invalid_parameter_definition 
> ... ok
> os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_response
> os_api_ref.tests.test_basic_example.TestBasicExample.test_rest_response ... 
> FAIL
> os_api_ref.tests.test_warnings.TestWarnings.test_missing_field
> os_api_ref.tests.test_warnings.TestWarnings.test_missing_field ... ok
> os_api_ref.tests.test_warnings.TestWarnings.test_missing_lookup_name
> os_api_ref.tests.test_warnings.TestWarnings.test_missing_lookup_name ... ok
> os_api_ref.tests.test_warnings.TestWarnings.test_missing_path_parameter_in_stanza
> os_api_ref.tests.test_warnings.TestWarnings.test_missing_path_parameter_in_stanza
>  ... ok
> os_api_ref.tests.test_warnings.TestWarnings.test_no_parameters_set
> os_api_ref.tests.test_warnings.TestWarnings.test_no_parameters_set ... ok
> os_api_ref.tests.test_warnings.TestWarnings.test_out_of_order
> os_api_ref.tests.test_warnings.TestWarnings.test_out_of_order ... ok
> os_api_ref.tests.test_warnings.TestWarnings.test_parameter_file_not_exist
> os_api_ref.tests.test_warnings.TestWarnings.test_parameter_file_not_exist ... 
> ok
> 
> ==
> FAIL: os_api_ref.tests.test_basic_example.TestBasicExample.test_parameters
> os_api_ref.tests.test_basic_example.TestBasicExample.test_parameters
> --
> testtools.testresult.real._StringException: Traceback (most recent call last):
>   File "/<>/os_api_ref/tests/test_basic_example.py", line 144, 
> in test_parameters
> self.assertIn(table, self.content)
>   File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 399, in 
> assertIn
> self.assertThat(haystack, Contains(needle), message)
>   File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 480, in 
> assertThat
> raise mismatch_error
> testtools.matchers._impl.MismatchError: '\n\n\n\n\n\n\n\n class="head">Name\nIn\n class="head">Type\n class="head">Description\n\n\n\n class="row-even">name\nbody\nstring\nThe
>  name of things\n\n\n' not in ' PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>\n\n xml:lang="en" xmlns="http://www.w3.org/1999/xhtml";>\n\n content="text/html; charset=utf-8" 
> http-equiv="Content-Type"/>\nOpenStack Docs: List 
> Servers\n\n http-equiv="X-UA-Compatible"/>\n\nhttp://docutils.sourceforge.net/"; na

Bug#1013407: isc-kea: FTBFS with Sphinx 5.0, docutils 0.18: make[4]: *** [Makefile:902: html] Error 2

Source: isc-kea
Version: 2.0.2-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

isc-kea fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[4]: Entering directory '/<>/doc/sphinx'
> rm -f ./arm/platforms.rst
> cp ./../../platforms.rst ./arm/platforms.rst
> /usr/bin/sphinx-build -M html . ./_build -v -E -a -W -j 2 -c 
> "/<>/doc/sphinx"
> Running Sphinx v5.0.2
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 272, in 
> build_main
> app = Sphinx(args.sourcedir, args.confdir, args.outputdir,
>   File "/usr/lib/python3/dist-packages/sphinx/application.py", line 196, in 
> __init__
> self.config = Config.read(self.confdir, confoverrides or {}, self.tags)
>   File "/usr/lib/python3/dist-packages/sphinx/config.py", line 172, in read
> logger.warning(__("Invalid configuration value found: 'language = None'. "
>   File "/usr/lib/python3.10/logging/__init__.py", line 1847, in warning
> self.log(WARNING, msg, *args, **kwargs)
>   File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 122, in 
> log
> super().log(level, msg, *args, **kwargs)
>   File "/usr/lib/python3.10/logging/__init__.py", line 1879, in log
> self.logger.log(level, msg, *args, **kwargs)
>   File "/usr/lib/python3.10/logging/__init__.py", line 1547, in log
> self._log(level, msg, args, **kwargs)
>   File "/usr/lib/python3.10/logging/__init__.py", line 1624, in _log
> self.handle(record)
>   File "/usr/lib/python3.10/logging/__init__.py", line 1634, in handle
> self.callHandlers(record)
>   File "/usr/lib/python3.10/logging/__init__.py", line 1696, in callHandlers
> hdlr.handle(record)
>   File "/usr/lib/python3.10/logging/__init__.py", line 964, in handle
> rv = self.filter(record)
>   File "/usr/lib/python3.10/logging/__init__.py", line 821, in filter
> result = f.filter(record)
>   File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 425, in 
> filter
> raise exc
> sphinx.errors.SphinxWarning: Invalid configuration value found: 'language = 
> None'. Update your configuration to a valid langauge code. Falling back to 
> 'en' (English).
> 
> Warning, treated as error:
> Invalid configuration value found: 'language = None'. Update your 
> configuration to a valid langauge code. Falling back to 'en' (English).
> make[4]: *** [Makefile:902: html] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/isc-kea_2.0.2-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013405: sympy: FTBFS with Sphinx 5.0, docutils 0.18: AttributeError: 'Text' object has no attribute 'rawsource'

Source: sympy
Version: 1.10.1-3
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

sympy fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/doc'
> mkdir -p _build/logo
> python3 ./generate_logos.py -d
> INFO:root: File saved: /<>/doc/./_build/logo/sympy-notail.svg
> INFO:root: File saved: /<>/doc/./_build/logo/sympy-notailtext.svg
> INFO:root: File saved: /<>/doc/./_build/logo/sympy-notext.svg
> DEBUG:root:command: rsvg-convert /<>/doc/./src/logo/sympy.svg -f 
> png -o /<>/doc/./_build/logo/sympy-160px.png -h 160 -w 160
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert /<>/doc/./src/logo/sympy.svg -f 
> png -o /<>/doc/./_build/logo/sympy-500px.png -h 500 -w 500
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notail.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notail-160px.png -h 160 -w 160
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notail.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notail-500px.png -h 500 -w 500
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notailtext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notailtext-160px.png -h 160 -w 160
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notailtext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notailtext-500px.png -h 500 -w 500
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notext-160px.png -h 160 -w 160
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notext-500px.png -h 500 -w 500
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert /<>/doc/./src/logo/sympy.svg -f 
> png -o /<>/doc/./_build/logo/sympy-16px.png -h 16 -w 16
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert /<>/doc/./src/logo/sympy.svg -f 
> png -o /<>/doc/./_build/logo/sympy-32px.png -h 32 -w 32
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert /<>/doc/./src/logo/sympy.svg -f 
> png -o /<>/doc/./_build/logo/sympy-48px.png -h 48 -w 48
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert /<>/doc/./src/logo/sympy.svg -f 
> png -o /<>/doc/./_build/logo/sympy-64px.png -h 64 -w 64
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notail.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notail-16px.png -h 16 -w 16
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notail.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notail-32px.png -h 32 -w 32
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notail.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notail-48px.png -h 48 -w 48
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notail.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notail-64px.png -h 64 -w 64
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notailtext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notailtext-16px.png -h 16 -w 16
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notailtext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notailtext-32px.png -h 32 -w 32
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notailtext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notailtext-48px.png -h 48 -w 48
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notailtext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notailtext-64px.png -h 64 -w 64
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notext-16px.png -h 16 -w 16
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notext-32px.png -h 32 -w 32
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notext-48px.png -h 48 -w 48
> DEBUG:root:return code: 0
> DEBUG:root:command: rsvg-convert 
> /<>/doc/./_build/logo/sympy-notext.svg -f png -o 
> /<>/doc/./_build/logo/sympy-notext-64px.png -h 64 -w 64
> DEBUG:root:return code: 0
> DEBUG:root:command: convert /<>/doc/./_build/logo/sympy-16px.png 
> /<>/doc/./_build/logo/sympy-32px.png 
> /<>/doc/./_build/logo/sympy-48px.png 
> /<>/doc/./_build/logo/sympy-64px.png 
> /<>/doc/./_build/logo/sympy-favicon.ico
> DEBUG:root:return code: 0
> DEBUG:root:command: convert 
> /<>/doc/./_build/logo/sympy-notail

Bug#1013403: mako: FTBFS with Sphinx 5.0, docutils 0.18: AttributeError: 'Text' object has no attribute 'rawsource'

Source: mako
Version: 1.1.3+ds1-3
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

mako fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
>  debian/rules binary
> python3.9 setup.py build_scripts  --executable=/usr/bin/python3
> running build_scripts
> python3.9 setup.py install  \
>   --root /<>/debian/python3-mako --prefix=/usr
> running install
> /usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
> SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and 
> pip and other standards-based tools.
>   warnings.warn(
> running build
> running build_py
> creating build
> creating build/lib
> creating build/lib/mako
> copying mako/__init__.py -> build/lib/mako
> copying mako/template.py -> build/lib/mako
> copying mako/codegen.py -> build/lib/mako
> copying mako/ast.py -> build/lib/mako
> copying mako/util.py -> build/lib/mako
> copying mako/lexer.py -> build/lib/mako
> copying mako/pyparser.py -> build/lib/mako
> copying mako/parsetree.py -> build/lib/mako
> copying mako/exceptions.py -> build/lib/mako
> copying mako/_ast_util.py -> build/lib/mako
> copying mako/filters.py -> build/lib/mako
> copying mako/cache.py -> build/lib/mako
> copying mako/lookup.py -> build/lib/mako
> copying mako/pygen.py -> build/lib/mako
> copying mako/compat.py -> build/lib/mako
> copying mako/cmd.py -> build/lib/mako
> copying mako/runtime.py -> build/lib/mako
> creating build/lib/mako/ext
> copying mako/ext/__init__.py -> build/lib/mako/ext
> copying mako/ext/preprocessors.py -> build/lib/mako/ext
> copying mako/ext/extract.py -> build/lib/mako/ext
> copying mako/ext/linguaplugin.py -> build/lib/mako/ext
> copying mako/ext/babelplugin.py -> build/lib/mako/ext
> copying mako/ext/pygmentplugin.py -> build/lib/mako/ext
> copying mako/ext/turbogears.py -> build/lib/mako/ext
> copying mako/ext/beaker_cache.py -> build/lib/mako/ext
> copying mako/ext/autohandler.py -> build/lib/mako/ext
> running install_lib
> creating /<>/debian/python3-mako
> creating /<>/debian/python3-mako/usr
> creating /<>/debian/python3-mako/usr/lib
> creating /<>/debian/python3-mako/usr/lib/python3.9
> creating /<>/debian/python3-mako/usr/lib/python3.9/site-packages
> creating 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/__init__.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/template.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/codegen.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/ast.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/util.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/lexer.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/pyparser.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/parsetree.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/exceptions.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/_ast_util.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/filters.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/cache.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/lookup.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/pygen.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/compat.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/cmd.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> copying build/lib/mako/runtime.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako
> creating 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/__init__.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/preprocessors.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/extract.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/linguaplugin.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/babelplugin.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/pygmentplugin.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/mako/ext
> copying build/lib/mako/ext/turbogears.py -> 
> /<>/debian/python3-mako/usr/lib/python3.9/site-packages/m

Bug#1013401: liblognorm: FTBFS with Sphinx 5.0, docutils 0.18: make[4]: *** [Makefile:488: html-local] Error 2

Source: liblognorm
Version: 2.0.6-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

liblognorm fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[4]: Entering directory '/<>/doc'
> sphinx-build -b html -d _build/doctrees -n -W -c . . _build/html
> Running Sphinx v5.0.2
> 
> Warning, treated as error:
> Invalid configuration value found: 'language = None'. Update your 
> configuration to a valid langauge code. Falling back to 'en' (English).
> make[4]: *** [Makefile:488: html-local] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/liblognorm_2.0.6-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013400: h5py: FTBFS with Sphinx 5.0, docutils 0.18: make[2]: *** [Makefile:53: html] Error 2

Source: h5py
Version: 3.6.0-2
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

h5py fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/docs'
> sphinx-build -b html -d _build/doctrees  -W . _build/html
> Running Sphinx v5.0.2
> making output directory... done
> 
> Warning, treated as error:
> extlinks: Sphinx-6.0 will require a caption string to contain exactly one 
> '%s' and all other '%' need to be escaped as '%%'.
> make[2]: Leaving directory '/<>/docs'
> make[2]: *** [Makefile:53: html] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/h5py_3.6.0-2_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013399: sagemath: FTBFS with Sphinx 5.0, docutils 0.18: ln: failed to create symbolic link '*/_static': No such file or directory

Source: sagemath
Version: 9.5-4
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

sagemath fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[3]: Entering directory '/<>'
> cd sage && SAGE_ROOT=/<>/sage 
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/<>/sage/build/bin
>  src/doc/bootstrap
> mv sage/src/sage sage/src/sage.bak # Use the installed sage, not the one from 
> the source tree
> cd sage/src && \
> export 
> PYTHONPATH=/<>/debian/tmp/usr/lib/python3.10/dist-packages \
>SAGE_SRC=/<>/sage/src \
>SAGE_DOC_SRC=/<>/sage/src/doc \
>SAGE_DOC=/<>/sage/src/doc \
>MATHJAX_DIR=/usr/share/javascript/mathjax \
>LANG=C && \
> python3 -m sage_docbuild --no-pdf-links --mathjax all html
> /<>/sage/src/sage_docbuild/__init__.py:1728: DeprecationWarning: 
> avoid using "sage --docbuild all html" and "sage --docbuild all pdf"; use 
> "make doc" and "make doc-pdf" instead, if available.
> See https://trac.sagemath.org/31948 for details.
>   builder = getattr(get_builder(name), typ)
> 
> Building reference manual, first pass.
> 
> [reference] Extension error:
> [reference] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/references
> [spkg ] Extension error:
> [spkg ] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/spkg
> [dynamics ] Extension error:
> [dynamics ] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/dynamics
> [tensor_fr] Extension error:
> [tensor_fr] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/tensor_free_modules
> [algebras ] Extension error:
> [algebras ] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/algebras
> [combinat ] Extension error:
> [combinat ] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/combinat
> /<>/sage/src/sage_docbuild/__init__.py:1022: DeprecationWarning: 
> the package sage.media is deprecated
> See http://trac.sagemath.org/12673 for details.
>   __import__(module_name)
> [repl ] Extension error:
> [repl ] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/repl
> [polynomia] Extension error:
> [polynomia] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/polynomial_rings
> /<>/sage/src/sage_docbuild/__init__.py:1022: FutureWarning: 
> EllipticCurveHom_composite is experimental code.
> See https://trac.sagemath.org/32744 for details.
>   __import__(module_name)
> [arithgrou] Extension error:
> [arithgrou] Could not import extension sage_docbuild.ext.sage_autodoc 
> (exception: cannot import name 'get_module_members' from 
> 'sphinx.ext.autodoc.importer' 
> (/usr/lib/python3/dist-packages/sphinx/ext/autodoc/importer.py))
> Build finished. The built documents can be found in 
> /<>/sage/src/doc/inventory/en/reference/arithgroup
> [plot3d   ] Extension error:
> [plot3d   ] Could

Bug#1013398: petsc: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:591: override_dh_sphinxdoc-indep] Error 255

Source: petsc
Version: 3.16.6+dfsg1-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

petsc fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> # various js scripts provided with upstream source were built with a 
> different sphinx version not recognized by dh_sphinxdoc
> dh_sphinxdoc -i -Xjquery -Xsearchtools -Xunderscore -Xdoctools
> unexpected end of string while parsing JSON string, at character offset 2 
> (before "ocnames:["community/...") at /usr/bin/dh_sphinxdoc line 245.
> make[1]: *** [debian/rules:591: override_dh_sphinxdoc-indep] Error 255


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/petsc_3.16.6+dfsg1-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013397: python-gevent: FTBFS with Sphinx 5.0, docutils 0.18: Could not import extension repoze.sphinx.autointerface (exception: cannot import name 'force_decode' from 'sphinx.util' (/usr/lib/pyth

Source: python-gevent
Version: 21.8.0-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-gevent fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/docs'
> /usr/share/sphinx/scripts/python3/sphinx-build -b html -d _build/doctrees   . 
> _build/html
> Running Sphinx v5.0.2
> 
> Extension error:
> Could not import extension repoze.sphinx.autointerface (exception: cannot 
> import name 'force_decode' from 'sphinx.util' 
> (/usr/lib/python3/dist-packages/sphinx/util/__init__.py))
> make[2]: *** [Makefile:34: html] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/python-gevent_21.8.0-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013396: python-btrees: FTBFS with Sphinx 5.0, docutils 0.18: Could not import extension repoze.sphinx.autointerface (exception: cannot import name 'force_decode' from 'sphinx.util' (/usr/lib/pyth

Source: python-btrees
Version: 4.3.1-3
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-btrees fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/IIBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/OIBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/IOBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/LLBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/LFBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/OLBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/_base.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/_compat.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/fsBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/Length.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/check.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/Interfaces.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/OOBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/IFBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/utils.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/LOBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> creating /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_OIBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_Length.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_LOBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/testBTrees.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_OOBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_check.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_IFBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_LFBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_IOBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_btreesubclass.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_utils.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/testConflict.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/common.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/testBTreesUnicode.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_OLBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test__base.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_IIBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_fsBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> copying BTrees/tests/test_LLBTree.py -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees/tests
> running egg_info
> writing BTrees.egg-info/PKG-INFO
> writing dependency_links to BTrees.egg-info/dependency_links.txt
> writing entry points to BTrees.egg-info/entry_points.txt
> writing requirements to BTrees.egg-info/requires.txt
> writing top-level names to BTrees.egg-info/top_level.txt
> reading manifest file 'BTrees.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no previously-included files matching '*.dll' found anywhere in 
> distribution
> warning: no previously-included files matching '*.pyc' found anywhere in 
> distribution
> warning: no previously-included files matching '*.pyo' found anywhere in 
> distribution
> warning: no previously-included files matching '*.so' found anywhere in 
> distribution
> warning: no previously-included files matching 'coverage.xml' found anywhere 
> in distribution
> no previously-included directories found matching 'docs/_build'
> adding license file 'LICENSE.txt'
> writing manifest file 'BTrees.egg-info/SOURCES.txt'
> copying BTrees/BTreeItemsTemplate.c -> 
> /<>/.pybuild/cpython3_3.9_btrees/build/BTrees
> copying BTrees/BTreeModuleTemplate.c -> 
> /<>/.pybuild/cpython3_3.9_btrees/b

Bug#1013390: sphinx-autoapi: FTBFS with Sphinx 5.0, docutils 0.18: E FileNotFoundError: [Errno 2] No such file or directory: '_build'

Source: sphinx-autoapi
Version: 1.8.4-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

sphinx-autoapi fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3,sphinxdoc --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:239: python3.9 setup.py config 
> running config
> I: pybuild base:239: python3.10 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/toctree.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/extension.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/settings.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/inheritance_diagrams.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/directives.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/documenters.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> copying autoapi/backends.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi
> creating 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/go.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/base.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/javascript.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers
> copying autoapi/mappers/dotnet.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers
> creating 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/parser.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/astroid_utils.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/objects.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers/python
> copying autoapi/mappers/python/mapper.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/mappers/python
> running egg_info
> creating sphinx_autoapi.egg-info
> writing sphinx_autoapi.egg-info/PKG-INFO
> writing dependency_links to sphinx_autoapi.egg-info/dependency_links.txt
> writing requirements to sphinx_autoapi.egg-info/requires.txt
> writing top-level names to sphinx_autoapi.egg-info/top_level.txt
> writing manifest file 'sphinx_autoapi.egg-info/SOURCES.txt'
> reading manifest file 'sphinx_autoapi.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no files found matching 'LICENSE.mit'
> adding license file 'LICENSE.rst'
> writing manifest file 'sphinx_autoapi.egg-info/SOURCES.txt'
> creating 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates
> copying autoapi/templates/index.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates
> creating 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/base
> copying autoapi/templates/base/base.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/base
> creating 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/base_detail.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/base_embed.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/base_list.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/class.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/constructor.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/delegate.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/enum.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/dotnet/event.rst -> 
> /<>/.pybuild/cpython3_3.9_sphinx-autoapi/build/autoapi/templates/dotnet
> copying autoapi/templates/d

Bug#1013394: python-dogpile.cache: FTBFS with Sphinx 5.0, docutils 0.18: AttributeError: 'Text' object has no attribute 'rawsource'

Source: python-dogpile.cache
Version: 1.1.5-2
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-dogpile.cache fails to build with Sphinx 5.0 and docutils 0.18, both of 
which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> PYTHONPATH=. python3 -m sphinx -b html docs/build 
> /<>/debian/python-dogpile.cache-doc/usr/share/doc/python-dogpile.cache-doc/html
> Running Sphinx v5.0.2
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 7 source files that are out of date
> updating environment: [new config] 7 added, 0 changed, 0 removed
> reading sources... [ 14%] api
> reading sources... [ 28%] changelog
> /<>/dogpile/cache/backends/redis.py:docstring of 
> dogpile.cache.backends.redis.RedisSentinelBackend:71: WARNING: Duplicate 
> explicit target name: "redis".
> /<>/dogpile/cache/backends/redis.py:docstring of 
> dogpile.cache.backends.redis.RedisSentinelBackend:71: WARNING: Duplicate 
> explicit target name: "redis".
> The name of the builder is: htmlThe name of the builder is: html
> Exception occurred:
>   File "/usr/lib/python3/dist-packages/changelog/docutils.py", line 338, in 
> _text_rawsource_from_node
> src.append(n.rawsource)
> AttributeError: 'Text' object has no attribute 'rawsource'
> The full traceback has been saved in /tmp/sphinx-err-c0j5i8yj.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> make[1]: *** [debian/rules:25: override_dh_sphinxdoc] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/python-dogpile.cache_1.1.5-2_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013395: mpdecimal: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:60: override_dh_sphinxdoc] Error 255

Source: mpdecimal
Version: 2.5.1-2
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

mpdecimal fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> rm -rf debian/tmp/usr/share/doc/mpdecimal/libmpdec++/_static
> ln -sf ../libmpdec/_static 
> debian/tmp/usr/share/doc/mpdecimal/libmpdec++/_static
> rm -f 
> debian/tmp/usr/share/doc/mpdecimal/libmpdec/_static/{doctools,jquery,searchtools,sidebar,underscore}.js
> cp -p 
> /usr/share/javascript/sphinxdoc/1.0/{doctools,jquery,searchtools,sidebar,underscore}.js
>  \
>   debian/tmp/usr/share/doc/mpdecimal/libmpdec/_static/.
> cp -a debian/tmp/usr/share/doc/mpdecimal/* \
>   debian/libmpdec-doc/usr/share/doc/libmpdec-doc
> rm -f debian/libmpdec-doc/usr/share/doc/libmpdec-doc/LICENSE*
> rm -f debian/libmpdec-doc/usr/share/doc/libmpdec-doc/INSTALL*
> dh_sphinxdoc
> unexpected end of string while parsing JSON string, at character offset 2 
> (before "ocnames:["arithmetic...") at /usr/bin/dh_sphinxdoc line 245.
> make[1]: *** [debian/rules:60: override_dh_sphinxdoc] Error 255


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/mpdecimal_2.5.1-2_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013391: sphinx-tabs: FTBFS with Sphinx 5.0, docutils 0.18: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.10" returned exit code 13

Source: sphinx-tabs
Version: 3.2.0-3
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

sphinx-tabs fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> python3 -m sphinx -b html -d docs/.build/.doctrees -N docs docs/.build/html
> Running Sphinx v5.0.2
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 1 source files that are out of date
> updating environment: [new config] 1 added, 0 changed, 0 removed
> reading sources... [100%] index
> 
> looking for now-outdated files... none found
> pickling environment... done
> checking consistency... done
> preparing documents... done
> writing output... [100%] index
> 
> generating indices... genindex done
> writing additional pages... search done
> copying static files... done
> copying extra files... done
> dumping search index in English (code: en)... done
> dumping object inventory... done
> build succeeded.
> 
> The HTML pages are in docs/.build/html.
> dh_auto_build
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.9_sphinx-tabs/build/sphinx_tabs
> copying sphinx_tabs/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-tabs/build/sphinx_tabs
> copying sphinx_tabs/tabs.py -> 
> /<>/.pybuild/cpython3_3.9_sphinx-tabs/build/sphinx_tabs
> running egg_info
> creating sphinx_tabs.egg-info
> writing sphinx_tabs.egg-info/PKG-INFO
> writing dependency_links to sphinx_tabs.egg-info/dependency_links.txt
> writing requirements to sphinx_tabs.egg-info/requires.txt
> writing top-level names to sphinx_tabs.egg-info/top_level.txt
> writing manifest file 'sphinx_tabs.egg-info/SOURCES.txt'
> reading manifest file 'sphinx_tabs.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no previously-included files found matching 'docs'
> warning: no previously-included files matching '*' found under directory 
> 'docs'
> warning: no previously-included files found matching 'tests'
> warning: no previously-included files matching '*' found under directory 
> 'tests'
> warning: no previously-included files found matching 'images'
> warning: no previously-included files matching '*' found under directory 
> 'images'
> warning: no previously-included files found matching '.pre-commit-config.yaml'
> warning: no previously-included files found matching '.readthedocs.yml'
> warning: no previously-included files found matching 'pylint.cfg'
> warning: no previously-included files found matching 'tox.ini'
> warning: no previously-included files found matching 'codecov.yml'
> adding license file 'LICENSE'
> writing manifest file 'sphinx_tabs.egg-info/SOURCES.txt'
> creating 
> /<>/.pybuild/cpython3_3.9_sphinx-tabs/build/sphinx_tabs/static
> copying sphinx_tabs/static/tabs.css -> 
> /<>/.pybuild/cpython3_3.9_sphinx-tabs/build/sphinx_tabs/static
> copying sphinx_tabs/static/tabs.js -> 
> /<>/.pybuild/cpython3_3.9_sphinx-tabs/build/sphinx_tabs/static
> I: pybuild base:239: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.10_sphinx-tabs/build/sphinx_tabs
> copying sphinx_tabs/__init__.py -> 
> /<>/.pybuild/cpython3_3.10_sphinx-tabs/build/sphinx_tabs
> copying sphinx_tabs/tabs.py -> 
> /<>/.pybuild/cpython3_3.10_sphinx-tabs/build/sphinx_tabs
> running egg_info
> writing sphinx_tabs.egg-info/PKG-INFO
> writing dependency_links to sphinx_tabs.egg-info/dependency_links.txt
> writing requirements to sphinx_tabs.egg-info/requires.txt
> writing top-level names to sphinx_tabs.egg-info/top_level.txt
> reading manifest file 'sphinx_tabs.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no previously-included files found matching 'docs'
> warning: no previously-included files matching '*' found under directory 
> 'docs'
> warning: no previously-included files found matching 'tests'
> warning: no previously-included files matching '*' found under directory 
> 'tests'
> warning: no previously-included files found matching 'images'
> warning: no previously-included files matching '*' found under directory 
> 'images'
> warning: no previously-included files found matching '.pre-commit-config.yaml'
> warning: no previously-included files found matching '.readthedocs.yml'
> warning: no previously-included files found matching 'pylint.cfg'
> warning: no previously-included files found matching 'tox.ini'
> warning: no previously-included files found matching 'codecov.yml'
> adding license file 'LICENSE'
> writing manifest file 'sphinx_tabs.egg-info/SOURCES.txt'
> creating 
> /<>/.pybuild/cpython3_3.10_sphinx-tabs/build/sphinx_tabs/static
> copying sphinx_tabs/static/tabs.css -> 
> /<>/.pybuild/cpython3_3.10_sphinx-tabs/build/sphinx_tabs/static
> copying sphinx_tabs/static/tabs.js -> 
> /<>/.pybuild/cpython3_3.10_sphinx-tab

Bug#1013393: python-repoze.who: FTBFS with Sphinx 5.0, docutils 0.18: Could not import extension repoze.sphinx.autointerface (exception: cannot import name 'force_decode' from 'sphinx.util' (/usr/lib/

Source: python-repoze.who
Version: 2.2-4
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-repoze.who fails to build with Sphinx 5.0 and docutils 0.18, both of 
which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> PYTHONPATH=. python3 -m sphinx -b html -D today="September 10, 2019" docs 
> /<>/debian/python-repoze.who/usr/share/doc/python-repoze.who/html
> Running Sphinx v5.0.2
> running test
> WARNING: Testing via this command is deprecated and will be removed in a 
> future version. Users looking for a generic test entry point independent of 
> test runner are encouraged to use tox.
> running egg_info
> writing repoze.who.egg-info/PKG-INFO
> writing dependency_links to repoze.who.egg-info/dependency_links.txt
> writing entry points to repoze.who.egg-info/entry_points.txt
> writing namespace_packages to repoze.who.egg-info/namespace_packages.txt
> writing requirements to repoze.who.egg-info/requires.txt
> writing top-level names to repoze.who.egg-info/top_level.txt
> reading manifest file 'repoze.who.egg-info/SOURCES.txt'
> adding license file 'LICENSE.txt'
> writing manifest file 'repoze.who.egg-info/SOURCES.txt'
> running build_ext
> ../<>/repoze/who/utils.py:5: 
> PkgResourcesDeprecationWarning: Parameters to load are deprecated.  Call 
> .resolve and .require separately.
>   return EntryPoint.parse('x=%s' % dotted_or_ep).load(False)
> E../<>/repoze/who/config.py:74:
>  DeprecationWarning: The SafeConfigParser class has been renamed to 
> ConfigParser in Python 3.2. This alias will be removed in Python 3.12. Use 
> ConfigParser directly instead.
>   cp = SafeConfigParser(defaults={'here': self.here})
> /<>/repoze/who/config.py:23: PkgResourcesDeprecationWarning: 
> Parameters to load are deprecated.  Call .resolve and .require separately.
>   return EntryPoint.parse('x=%s' % name).load(False)
> ../<>/repoze/who/config.py:74: 
> DeprecationWarning: The SafeConfigParser class has been renamed to 
> ConfigParser in Python 3.2. This alias will be removed in Python 3.12. Use 
> ConfigParser directly instead.
>   cp = SafeConfigParser(defaults={'here': self.here})
> /<>/repoze/who/config.py:23: PkgResourcesDeprecationWarning: 
> Parameters to load are deprecated.  Call .resolve and .require separately.
>   return EntryPoint.parse('x=%s' % name).load(False)
> /<>/repoze/who/utils.py:5: PkgResourcesDeprecationWarning: 
> Parameters to load are deprecated.  Call .resolve and .require separately.
>   return EntryPoint.parse('x=%s' % dotted_or_ep).load(False)
> .../<>/repoze/who/restrict.py:32: 
> PkgResourcesDeprecationWarning: Parameters to load are deprecated.  Call 
> .resolve and .require separately.
>   predicate = EntryPoint.parse('x=%s' % predicate).load(False)
> .
> ==
> ERROR: test_brokenimpl (repoze.who.tests.test_api.TestMakeRegistries)
> --
> Traceback (most recent call last):
>   File "/<>/repoze/who/tests/test_api.py", line 114, in 
> test_brokenimpl
> self.assertRaises(ValueError, self._callFUT,
>   File "/usr/lib/python3.10/unittest/case.py", line 738, in assertRaises
> return context.handle('assertRaises', args, kwargs)
>   File "/usr/lib/python3.10/unittest/case.py", line 201, in handle
> callable_obj(*args, **kwargs)
>   File "/<>/repoze/who/tests/test_api.py", line 105, in _callFUT
> return make_registries(identifiers, authenticators,
>   File "/<>/repoze/who/api.py", line 72, in make_registries
> verify(value, iface)
>   File "/<>/repoze/who/api.py", line 57, in verify
> verifyObject(iface, plugin, tentative=True)
>   File "/usr/lib/python3/dist-packages/zope/interface/verify.py", line 172, 
> in verifyObject
> return _verify(iface, candidate, tentative, vtype='o')
>   File "/usr/lib/python3/dist-packages/zope/interface/verify.py", line 92, in 
> _verify
> raise MultipleInvalid(iface, candidate, excs)
> zope.interface.exceptions.MultipleInvalid: The object  0x7f11daa0eab0> has failed to implement interface 
> repoze.who.interfaces.IIdentifier:
> The repoze.who.interfaces.IIdentifier.identify(environ) attribute was not 
> provided
> The repoze.who.interfaces.IIdentifier.remember(environ, identity) 
> attribute was not provided
> The repoze.who.interfaces.IIdentifier.forget(environ, identity) attribute 
> was not provided
> 
> --
> Ran 287 tests in 0.071s
> 
> FAILED (errors=1)
> Test failed: 
> error: Test failed:  failures=0>
> 
> Extension error:
> Could not import extension rep

Bug#1013392: python-repoze.sphinx.autointerface: FTBFS with Sphinx 5.0, docutils 0.18: ImportError: cannot import name 'force_decode' from 'sphinx.util' (/usr/lib/python3/dist-packages/sphinx/util/__i

Source: python-repoze.sphinx.autointerface
Version: 0.8-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-repoze.sphinx.autointerface fails to build with Sphinx 5.0 and docutils 
0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
>  debian/rules build
> dh build  --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:239: python3.9 setup.py config 
> running config
> I: pybuild base:239: python3.10 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> creating 
> /<>/.pybuild/cpython3_3.9_repoze.sphinx.autointerface/build/repoze
> copying repoze/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_repoze.sphinx.autointerface/build/repoze
> creating 
> /<>/.pybuild/cpython3_3.9_repoze.sphinx.autointerface/build/repoze/sphinx
> copying repoze/sphinx/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_repoze.sphinx.autointerface/build/repoze/sphinx
> copying repoze/sphinx/autointerface.py -> 
> /<>/.pybuild/cpython3_3.9_repoze.sphinx.autointerface/build/repoze/sphinx
> running egg_info
> writing repoze.sphinx.autointerface.egg-info/PKG-INFO
> writing dependency_links to 
> repoze.sphinx.autointerface.egg-info/dependency_links.txt
> writing namespace_packages to 
> repoze.sphinx.autointerface.egg-info/namespace_packages.txt
> writing requirements to repoze.sphinx.autointerface.egg-info/requires.txt
> writing top-level names to repoze.sphinx.autointerface.egg-info/top_level.txt
> reading manifest file 'repoze.sphinx.autointerface.egg-info/SOURCES.txt'
> adding license file 'LICENSE.txt'
> writing manifest file 'repoze.sphinx.autointerface.egg-info/SOURCES.txt'
> I: pybuild base:239: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating 
> /<>/.pybuild/cpython3_3.10_repoze.sphinx.autointerface/build/repoze
> copying repoze/__init__.py -> 
> /<>/.pybuild/cpython3_3.10_repoze.sphinx.autointerface/build/repoze
> creating 
> /<>/.pybuild/cpython3_3.10_repoze.sphinx.autointerface/build/repoze/sphinx
> copying repoze/sphinx/__init__.py -> 
> /<>/.pybuild/cpython3_3.10_repoze.sphinx.autointerface/build/repoze/sphinx
> copying repoze/sphinx/autointerface.py -> 
> /<>/.pybuild/cpython3_3.10_repoze.sphinx.autointerface/build/repoze/sphinx
> running egg_info
> writing repoze.sphinx.autointerface.egg-info/PKG-INFO
> writing dependency_links to 
> repoze.sphinx.autointerface.egg-info/dependency_links.txt
> writing namespace_packages to 
> repoze.sphinx.autointerface.egg-info/namespace_packages.txt
> writing requirements to repoze.sphinx.autointerface.egg-info/requires.txt
> writing top-level names to repoze.sphinx.autointerface.egg-info/top_level.txt
> reading manifest file 'repoze.sphinx.autointerface.egg-info/SOURCES.txt'
> adding license file 'LICENSE.txt'
> writing manifest file 'repoze.sphinx.autointerface.egg-info/SOURCES.txt'
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:239: python3.9 setup.py test 
> running test
> WARNING: Testing via this command is deprecated and will be removed in a 
> future version. Users looking for a generic test entry point independent of 
> test runner are encouraged to use tox.
> running egg_info
> writing repoze.sphinx.autointerface.egg-info/PKG-INFO
> writing dependency_links to 
> repoze.sphinx.autointerface.egg-info/dependency_links.txt
> writing namespace_packages to 
> repoze.sphinx.autointerface.egg-info/namespace_packages.txt
> writing requirements to repoze.sphinx.autointerface.egg-info/requires.txt
> writing top-level names to repoze.sphinx.autointerface.egg-info/top_level.txt
> reading manifest file 'repoze.sphinx.autointerface.egg-info/SOURCES.txt'
> adding license file 'LICENSE.txt'
> writing manifest file 'repoze.sphinx.autointerface.egg-info/SOURCES.txt'
> running build_ext
> autointerface (unittest.loader._FailedTest) ... ERROR
> 
> ==
> ERROR: autointerface (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: autointerface
> Traceback (most recent call last):
>   File "/usr/lib/python3.9/unittest/loader.py", line 154, in loadTestsFromName
> module = __import__(module_name)
>   File "/<>/repoze/sphinx/autointerface.py", line 3, in 
> from sphinx.util import force_decode
> ImportError: cannot import name 'force_decode' from 'sphinx.util' 
> (/usr/lib/python3/dist-packages/sphinx/util/__init__.py)
> 
> 
> --
> Ran 1 test in 0.000s
> 
> FAILED (errors=1)
> Test failed: 
> error: Test failed: 
> E: pybuild pybuild:369: test: plugin distutils failed with: exit code=1: 
> python3.9 set

Bug#1013389: python-persistent: FTBFS with Sphinx 5.0, docutils 0.18: Could not import extension repoze.sphinx.autointerface (exception: cannot import name 'force_decode' from 'sphinx.util' (/usr/lib/

Source: python-persistent
Version: 4.6.4-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-persistent fails to build with Sphinx 5.0 and docutils 0.18, both of 
which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/persistence.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/interfaces.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/mapping.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/timestamp.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/ring.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/_compat.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/picklecache.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/list.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/_ring_build.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/wref.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/dict.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> running egg_info
> writing persistent.egg-info/PKG-INFO
> writing dependency_links to persistent.egg-info/dependency_links.txt
> writing requirements to persistent.egg-info/requires.txt
> writing top-level names to persistent.egg-info/top_level.txt
> reading manifest file 'persistent.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> no previously-included directories found matching 'terryfy'
> warning: no previously-included files matching '*.dll' found anywhere in 
> distribution
> warning: no previously-included files matching '*.pyc' found anywhere in 
> distribution
> warning: no previously-included files matching '*.pyo' found anywhere in 
> distribution
> warning: no previously-included files matching '*.so' found anywhere in 
> distribution
> warning: no previously-included files matching 'coverage.xml' found anywhere 
> in distribution
> no previously-included directories found matching 'docs/_build'
> no previously-included directories found matching 'persistent/__pycache__'
> adding license file 'LICENSE.txt'
> writing manifest file 'persistent.egg-info/SOURCES.txt'
> copying persistent/_compat.h -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/_timestamp.c -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/cPersistence.c -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/cPersistence.h -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/cPickleCache.c -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/ring.c -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> copying persistent/ring.h -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent
> creating 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/attrhooks.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/cucumbers.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test__compat.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_docs.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_list.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_mapping.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_persistence.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_picklecache.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_ring.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_timestamp.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/test_wref.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> copying persistent/tests/utils.py -> 
> /<>/.pybuild/cpython3_3.9_persistent/build/persistent/tests
> running build_ext
> generating cffi module 'build/temp.linux-x86_64-3.9/persistent._ring.c'
> creating build
> creating build/temp.linux-x86_64-3.9
> building 'persist

Bug#1013387: sphinxcontrib-qthelp: FTBFS with Sphinx 5.0, docutils 0.18: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.10" returned exit code 13

Source: sphinxcontrib-qthelp
Version: 1.0.3-3
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

sphinxcontrib-qthelp fails to build with Sphinx 5.0 and docutils 0.18, both of 
which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> python3 setup.py compile_catalog
> running compile_catalog
> compiling catalog 
> sphinxcontrib/qthelp/locales/sv/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/sv/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/he/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/he/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/mk/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/mk/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/zh_TW/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/zh_TW/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/sk/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/sk/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/cy/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/cy/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/cs/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/cs/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/tr/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/tr/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/lv/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/lv/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/ca/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/ca/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/it/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/it/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/nl/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/nl/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/fi/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/fi/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/eo/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/eo/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/uk_UA/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/uk_UA/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/ru/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/ru/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/pt_BR/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/pt_BR/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/pl/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/pl/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/id/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/id/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/fa/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/fa/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/hu/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/hu/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/ro/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/ro/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/ar/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/ar/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/es/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/es/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/et/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/et/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/lt/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/lt/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/ta/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/ta/LC_MESSAGES/sphinxcontrib.qthelp.mo
> compiling catalog 
> sphinxcontrib/qthelp/locales/sr/LC_MESSAGES/sphinxcontrib.qthelp.po to 
> sphinxcontrib/qthelp/locales/sr/LC_MESSAGES/sphi

Bug#1013386: alembic: FTBFS with Sphinx 5.0, docutils 0.18: AttributeError: 'Text' object has no attribute 'rawsource'

Source: alembic
Version: 1.7.6-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

alembic fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> python3 -m sphinx -b html docs/build 
> /<>/debian/alembic/usr/share/doc/alembic/html
> Running Sphinx v5.0.2
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 20 source files that are out of date
> updating environment: [new config] 20 added, 0 changed, 0 removed
> reading sources... [  5%] api/autogenerate
> reading sources... [ 10%] api/commands
> reading sources... [ 15%] api/config
> reading sources... [ 20%] api/ddl
> reading sources... [ 25%] api/index
> reading sources... [ 30%] api/operations
> reading sources... [ 35%] api/overview
> reading sources... [ 40%] api/runtime
> reading sources... [ 45%] api/script
> reading sources... [ 50%] autogenerate
> reading sources... [ 55%] batch
> reading sources... [ 60%] branches
> reading sources... [ 65%] changelog
> The name of the builder is: htmlThe name of the builder is: html
> Exception occurred:
>   File "/usr/lib/python3/dist-packages/changelog/docutils.py", line 338, in 
> _text_rawsource_from_node
> src.append(n.rawsource)
> AttributeError: 'Text' object has no attribute 'rawsource'
> The full traceback has been saved in /tmp/sphinx-err-qdnsd3au.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> make[1]: *** [debian/rules:13: override_dh_sphinxdoc] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/alembic_1.7.6-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013383: ruby-github-markup: FTBFS with Sphinx 5.0, docutils 0.18: ERROR: Test "ruby3.0" failed.

Source: ruby-github-markup
Version: 1.7.0+dfsg-4
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

ruby-github-markup fails to build with Sphinx 5.0 and docutils 0.18, both of 
which
are currently available in experimental.

Relevant part (hopefully):
> /usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner
> 
> ┌──┐
> │ Checking Rubygems dependency resolution on ruby3.0  
>  │
> └──┘
> 
> GEM_PATH=/<>/debian/ruby-github-markup/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -e gem\ \"github-markup\"
> 
> ┌──┐
> │ Run tests for ruby3.0 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=. 
> GEM_PATH=/<>/debian/ruby-github-markup/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0
>  ruby3.0 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby3.0 -w -I"test" 
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
>  "test/markup_test.rb" -v
> :85: 
> warning: 
> :85: 
> warning: loading in progress, circular require considered harmful - 
> /usr/lib/ruby/vendor_ruby/posix/spawn.rb
>   from 
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in
>   `'
>   from 
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in
>   `select'
>   from 
> /usr/share/rubygems-integration/all/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in
>   `block in '
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
>   from /<>/test/markup_test.rb:5:in  `'
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
>   from /<>/lib/github/markup.rb:7:in  `'
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
>   from /<>/lib/github/markup/command_implementation.rb:2:in  
> `'
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
>   from /usr/lib/ruby/vendor_ruby/posix-spawn.rb:1:in  `'
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
>   from /usr/lib/ruby/vendor_ruby/posix/spawn.rb:6:in  `'
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
>   from /usr/lib/ruby/vendor_ruby/posix/spawn/child.rb:1:in  ` (required)>'
>   from 
> :85:in
>   `require'
>   from 
> :85:in
>   `require'
> 
> /usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0/gems/nokogiri-1.13.5/lib/nokogiri/version/info.rb:85:
>  warning: possibly useless use of a variable in void context
> Run options: -v --seed 45311
> 
> # Running:
> 
> MarkupTest#test_pod = /usr/lib/ruby/vendor_ruby/posix/spawn.rb:532: warning: 
> deprecated Object#=~ is called on Array; it always returns nil
> 0.06 s = .
> MarkupTest#test_litcoffee = 0.03 s = .
> MarkupTest#test_asciidoc = 0.09 s = .
> MarkupTest#test_preserve_markup = 0.20 s = .
> MarkupTest#test_textile = 0.06 s = .
> MarkupTest#test_org = 
> /usr/lib/ruby/vendor_ruby/org-ruby/output_buffer.rb:291: warning: method 
> redefined; discarding old output_footnotes!
> /usr/lib/ruby/vendor_ruby/org-ruby/output_buffer.rb:249: warning: previous 
> definition of output_footnotes! was here
> /usr/lib/ruby/vendor_ruby/org-ruby/html_output_buffer.rb:243: warning: 
> ambiguity between regexp and two divisions: wrap regexp in parentheses or add 
> a space after `/' operator
> /usr/lib/ruby/vendor_ruby/org-ruby/html_output_buffer.rb:246: warning: 
> ambiguity between regexp and two divisions: wrap regexp in parentheses or add 
> a space after `/' operator
> /usr/lib/ruby/vendor_ruby/org-ruby/html_output_buffer.rb:249: warning: 
> ambiguity between regexp and two divisions: wrap regexp in parentheses or add 
> a space after `/' operator
> /usr/lib/ruby/vendor_ruby/org-ruby/html_output_buffer.rb:253: warning: 
> ambiguity between regexp and two divisions: wrap regexp in parentheses or add 
> a space after `/' operator
> /usr/lib/ruby/vendor_ruby/org-ruby/html_output_buffer.rb:322: warning: 
> ambiguity between regexp and two divisions: wrap regexp in parentheses or add 
> a space after `/' operator
> /usr

Bug#1013384: petsc4py: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:77: override_dh_sphinxdoc-indep] Error 255

Source: petsc4py
Version: 3.16.6-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

petsc4py fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_installdocs -i
> dh_installdocs: warning: Cannot auto-detect main package for 
> python-petsc4py-doc.  If the default is wrong, please use --doc-main-package
> rm 
> debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/jquery*.js
> ln -sf /usr/share/javascript/jquery/jquery.js 
> debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/jquery.js
> rm 
> debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/underscore*.js
> ln -sf /usr/share/javascript/underscore/underscore.js 
> debian/python-petsc4py-doc/usr/share/doc/python-petsc4py-doc/usrman/_static/underscore.js
> make[1]: Leaving directory '/<>'
>dh_installdocs -O--buildsystem=pybuild -Npython3-petsc4py 
> -Npython3-petsc4py-real -Npython3-petsc4py-complex -Npython3-petsc4py-64-real 
> -Npython3-petsc4py-64-complex -Npython-petsc4py-doc
>debian/rules override_dh_sphinxdoc-indep
> make[1]: Entering directory '/<>'
> dh_sphinxdoc -i --exclude=searchtools.js --exclude=doctools.js
> unexpected end of string while parsing JSON string, at character offset 2 
> (before "ocnames:["citing","i...") at /usr/bin/dh_sphinxdoc line 245.
> make[1]: *** [debian/rules:77: override_dh_sphinxdoc-indep] Error 255


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/petsc4py_3.16.6-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013382: cloudkitty: FTBFS with Sphinx 5.0, docutils 0.18: touch: cannot touch '/<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js': No such file or directo

Source: cloudkitty
Version: 16.0.0-2
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

cloudkitty fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> make[1]: pyversions: No such file or directory
> py3versions: no X-Python3-Version in control file, using supported versions
> # Warning: building doc fails.
> PYTHON=python3 python3 -m sphinx  -b html doc/source 
> /<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html || 
> true
> Running Sphinx v5.0.2
> loading stevedore.sphinxext
> connecting events for openstackdocstheme
> making output directory... done
> [oslo_config.sphinxconfiggen] reading config generator instructions from 
> /<>/doc/source/../../etc/oslo-config-generator/cloudkitty.conf
> [oslo_config.sphinxconfiggen] writing sample configuration to 
> /<>/doc/source/_static/cloudkitty.conf.sample
> Using openstackdocstheme Sphinx theme from 
> /usr/lib/python3/dist-packages/openstackdocstheme/theme
> [oslo_policy.sphinxpolicygen] reading config generator instructions from 
> /<>/doc/source/../../etc/oslo-policy-generator/cloudkitty.conf
> [oslo_policy.sphinxpolicygen] writing sample policy to 
> /<>/doc/source/_static/cloudkitty.policy.yaml.sample
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 39 source files that are out of date
> updating environment: [new config] 39 added, 0 changed, 0 removed
> reading sources... [  2%] admin/architecture
> reading sources... [  5%] admin/cli/cloudkitty-status
> reading sources... [  7%] admin/cli/index
> reading sources... [ 10%] admin/configuration/collector
> reading sources... [ 12%] admin/configuration/configuration
> reading sources... [ 15%] admin/configuration/fetcher
> reading sources... [ 17%] admin/configuration/index
> reading sources... [ 20%] admin/configuration/policy
> reading sources... [ 23%] admin/configuration/samples/cloudkitty-conf
> reading sources... [ 25%] admin/configuration/samples/policy-yaml
> reading sources... [ 28%] admin/configuration/storage
> reading sources... [ 30%] admin/devstack
> reading sources... [ 33%] admin/index
> reading sources... [ 35%] admin/install/index
> reading sources... [ 38%] admin/install/install-rdo
> reading sources... [ 41%] admin/install/install-source
> reading sources... [ 43%] admin/install/install-ubuntu
> reading sources... [ 46%] admin/install/mod_wsgi
> reading sources... [ 48%] api-reference/index
> reading sources... [ 51%] api-reference/v1/rating/hashmap
> 
> Exception occurred:
>   File "/usr/lib/python3/dist-packages/wsmeext/sphinxext.py", line 231, in 
> add_docstring
> super(TypeDocumenter, self).add_content(
> TypeError: ClassDocumenter.add_content() takes 2 positional arguments but 3 
> were given
> The full traceback has been saved in /tmp/sphinx-err-p4z_y97l.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> rm -rf 
> /<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/.doctrees
> touch 
> /<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js
> touch: cannot touch 
> '/<>/debian/cloudkitty-doc/usr/share/doc/cloudkitty-doc/html/_static/toggle.js':
>  No such file or directory
> make[1]: *** [debian/rules:99: override_dh_sphinxdoc] Error 1


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/cloudkitty_16.0.0-2_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013381: buildbot: FTBFS with Sphinx 5.0, docutils 0.18: make[2]: *** [Makefile:67: singlehtml] Error 2

Source: buildbot
Version: 3.5.0-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

buildbot fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/master/docs'
> rm -rf _build/*
> sphinx-build -b html -d _build/doctrees  -q -W -j 8 . _build/html
> sphinx-build -b singlehtml -d _build/doctrees  -q -W -j 8 . _build/singlehtml
> enchant module import failed:
> No module named 'enchant'
> Spell checking disabled.
> enchant module import failed:
> No module named 'enchant'
> Spell checking disabled.
> 
> Warning, treated as error:
> extlinks: Sphinx-6.0 will require a caption string to contain exactly one 
> '%s' and all other '%' need to be escaped as '%%'.
> 
> Warning, treated as error:
> extlinks: Sphinx-6.0 will require a caption string to contain exactly one 
> '%s' and all other '%' need to be escaped as '%%'.
> make[2]: *** [Makefile:67: singlehtml] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/buildbot_3.5.0-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013380: pybtex-docutils: FTBFS with Sphinx 5.0, docutils 0.18: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.10" returned exit code 13

Source: pybtex-docutils
Version: 1.0.1-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

pybtex-docutils fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/doc'
> sphinx-build -b html -d _build/doctrees   . _build/html
> Running Sphinx v5.0.2
> making output directory... done
> loading intersphinx inventory from http://docs.python.org/objects.inv...
> WARNING: failed to reach any of the inventories with the following issues:
> intersphinx inventory 'http://docs.python.org/objects.inv' not fetchable due 
> to : 
> HTTPConnectionPool(host='127.0.0.1', port=9): Max retries exceeded with url: 
> http://docs.python.org/objects.inv (Caused by ProxyError('Cannot connect to 
> proxy.', NewConnectionError(' 0x7ff2dd04a2c0>: Failed to establish a new connection: [Errno 111] Connection 
> refused')))
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 5 source files that are out of date
> updating environment: [new config] 5 added, 0 changed, 0 removed
> reading sources... [ 20%] api
> reading sources... [ 40%] changes
> reading sources... [ 60%] index
> reading sources... [ 80%] license
> reading sources... [100%] quickstart
> 
> looking for now-outdated files... none found
> pickling environment... done
> checking consistency... done
> preparing documents... done
> writing output... [ 20%] api
> writing output... [ 40%] changes
> writing output... [ 60%] index
> writing output... [ 80%] license
> writing output... [100%] quickstart
> 
> generating indices... genindex py-modindex done
> highlighting module code... [ 50%] builtins
> highlighting module code... [100%] pybtex_docutils
> 
> writing additional pages... search done
> copying static files... done
> copying extra files... done
> dumping search index in English (code: en)... done
> dumping object inventory... done
> build succeeded, 1 warning.
> 
> The HTML pages are in _build/html.
> 
> Build finished. The HTML pages are in _build/html.
> make[2]: Leaving directory '/<>/doc'
> make[1]: Leaving directory '/<>'
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild pybuild:300: python3 setup.py egg_info
> running egg_info
> creating src/pybtex_docutils.egg-info
> writing src/pybtex_docutils.egg-info/PKG-INFO
> writing dependency_links to src/pybtex_docutils.egg-info/dependency_links.txt
> writing entry points to src/pybtex_docutils.egg-info/entry_points.txt
> writing requirements to src/pybtex_docutils.egg-info/requires.txt
> writing top-level names to src/pybtex_docutils.egg-info/top_level.txt
> writing manifest file 'src/pybtex_docutils.egg-info/SOURCES.txt'
> reading manifest file 'src/pybtex_docutils.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> warning: no previously-included files matching '*.pyc' found anywhere in 
> distribution
> adding license file 'LICENSE.rst'
> writing manifest file 'src/pybtex_docutils.egg-info/SOURCES.txt'
> I: pybuild base:239: cd 
> /<>/.pybuild/cpython3_3.9_pybtex-docutils/build; python3.9 -m 
> pytest test
> = test session starts 
> ==
> platform linux -- Python 3.9.13, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
> rootdir: /<>, configfile: pytest.ini
> collected 23 items
> 
> test/test_backend.py ..F.F.F.[ 
> 86%]
> test/test_find_plugin.py ..  [ 
> 95%]
> test/test_install_example.py .   
> [100%]
> 
> === FAILURES 
> ===
> ___ test_citation_reference 
> 
> 
> entry = 
> document = 
> 
> def test_citation_reference(entry, document):
> node = Backend().citation_reference(entry, document)
> >   assert str(node) == (
> ''
> 'hongquin1997'
> '')
> E   assert '' == 
> ''
> E -  refname="hongquin1997">hongquin1997
> E ?   ^
> E +  refname="hongquin1997">hongquin1997
> E ?  + ^
> 
> test/test_backend.py:130: AssertionError
> __ test_citation_reference_use_label 
> ___
> 
> entry = 
> document = 
> 
> def test_citation_reference_use_label(entry, document):
> node = Backend().citation_reference(
> entry, document, use_key_as_label=False)
> >   assert str(node) == (
> ''
> '1'
> '')
> E   assert '' == 
> ''
> E -  refname="hongquin1997">1
> E ?   ^
> E +  refname="hongquin1997">1
> E ?  + ^
> 
> test/test_backend.py:154: AssertionError
> ___ test_footnote_referen

Bug#1013379: sqlalchemy: FTBFS with Sphinx 5.0, docutils 0.18: AttributeError: 'Text' object has no attribute 'rawsource'

Source: sqlalchemy
Version: 1.4.31+ds1-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

sqlalchemy fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> cd doc/build && python3 -m sphinx -N -E -b html . 
> ../../debian/python-sqlalchemy-doc/usr/share/doc/python-sqlalchemy-doc/html/
> Running Sphinx v5.0.2
> making output directory... done
> building [mo]: targets for 0 po files that are out of date
> building [html]: targets for 161 source files that are out of date
> updating environment: [new config] 161 added, 0 changed, 0 removed
> reading sources... [  0%] changelog/changelog_01
> The name of the builder is: htmlThe name of the builder is: html
> Exception occurred:
>   File "/usr/lib/python3/dist-packages/changelog/docutils.py", line 338, in 
> _text_rawsource_from_node
> src.append(n.rawsource)
> AttributeError: 'Text' object has no attribute 'rawsource'
> The full traceback has been saved in /tmp/sphinx-err-qyhbxzp_.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> make[1]: *** [debian/rules:40: override_dh_sphinxdoc] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/sqlalchemy_1.4.31+ds1-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013377: python-pyramid-chameleon: FTBFS with Sphinx 5.0, docutils 0.18: Could not import extension repoze.sphinx.autointerface (exception: cannot import name 'force_decode' from 'sphinx.util' (/u

Source: python-pyramid-chameleon
Version: 0.3-5
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

python-pyramid-chameleon fails to build with Sphinx 5.0 and docutils 0.18, both 
of which
are currently available in experimental.

Relevant part (hopefully):
> make[2]: Entering directory '/<>/docs'
> mkdir -p _build/html _build/doctrees
> sphinx-build -b html -d _build/doctrees   . _build/html
> Running Sphinx v5.0.2
> 
> Extension error:
> Could not import extension repoze.sphinx.autointerface (exception: cannot 
> import name 'force_decode' from 'sphinx.util' 
> (/usr/lib/python3/dist-packages/sphinx/util/__init__.py))
> make[2]: *** [Makefile:30: html] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/python-pyramid-chameleon_0.3-5_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013376: numpydoc: FTBFS with Sphinx 5.0, docutils 0.18: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.10" returned exit code 13

Source: numpydoc
Version: 1.2.1-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

numpydoc fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:239: python3.9 setup.py config 
> running config
> I: pybuild base:239: python3.10 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/__init__.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/__main__.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/xref.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/numpydoc.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/validate.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/docscrape.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> copying numpydoc/docscrape_sphinx.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc
> creating /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_docscrape.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_full.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_xref.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_main.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_validate.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_numpydoc.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests
> creating 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/Makefile -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/index.rst -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/numpydoc_test_module.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/conf.py -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/tests/tinybuild
> creating 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/templates
> copying numpydoc/templates/numpydoc_docstring.rst -> 
> /<>/.pybuild/cpython3_3.9_numpydoc/build/numpydoc/templates
> I: pybuild base:239: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/__init__.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/__main__.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/xref.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/numpydoc.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/validate.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/docscrape.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> copying numpydoc/docscrape_sphinx.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc
> creating /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_docscrape.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_full.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_xref.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_main.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_validate.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> copying numpydoc/tests/test_numpydoc.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests
> creating 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/Makefile -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/index.rst -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/numpydoc_test_module.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests/tinybuild
> copying numpydoc/tests/tinybuild/conf.py -> 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/tests/tinybuild
> creating 
> /<>/.pybuild/cpython3_3.10_numpydoc/build/numpydoc/templates
> copying numpydoc/templates/numpydoc_docstri

Bug#1013378: txtorcon: FTBFS with Sphinx 5.0, docutils 0.18: Could not import extension repoze.sphinx.autointerface (exception: cannot import name 'force_decode' from 'sphinx.util' (/usr/lib/python3/d

Source: txtorcon
Version: 22.0.0-1
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

txtorcon fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ 
> docs/_build/html # HTML generator
> Running Sphinx v5.0.2
> 
> Extension error:
> Could not import extension repoze.sphinx.autointerface (exception: cannot 
> import name 'force_decode' from 'sphinx.util' 
> (/usr/lib/python3/dist-packages/sphinx/util/__init__.py))
> make[1]: *** [debian/rules:9: override_dh_auto_build] Error 2


The full build log is available from:
http://qa-logs.debian.net/2022/06/23/txtorcon_22.0.0-1_unstable_sphinx-exp.log

Please see [1] for Sphinx changelog and [2] for Docutils changelog.

Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
alternatives to them.

In case you have questions, please Cc sph...@packages.debian.org on reply.

[1]: https://www.sphinx-doc.org/en/master/changes.html
[2]: 
https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.18.1:/RELEASE-NOTES.txt
[3]: 
https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx5.0;users=mity...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=sphinx5.0&fusertaguser=mity...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

Bug#1013375: pandas: FTBFS with Sphinx 5.0, docutils 0.18: ImportError: cannot import name 'rpartition' from 'sphinx.util' (/usr/lib/python3/dist-packages/sphinx/util/init.py)

Source: pandas
Version: 1.3.5+dfsg-4
Severity: important
Tags: ftbfs
User: mity...@debian.org
Usertags: sphinx5.0

Hi,

pandas fails to build with Sphinx 5.0 and docutils 0.18, both of which
are currently available in experimental.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> py3versions: no X-Python3-Version in control file, using supported versions
> mkdir -p buildtmp
> [ -e pandas/__version.py ] || \
> echo -e "version = '1.3.5'\nshort_version = '1.3.5'" > pandas/__version.py
> dh_auto_build
> I: pybuild base:239: /usr/bin/python3.9 setup.py build 
> running build
> running build_py
> running egg_info
> writing pandas.egg-info/PKG-INFO
> writing dependency_links to pandas.egg-info/dependency_links.txt
> writing entry points to pandas.egg-info/entry_points.txt
> writing requirements to pandas.egg-info/requires.txt
> writing top-level names to pandas.egg-info/top_level.txt
> reading manifest file 'pandas.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> no previously-included directories found matching 'doc/build'
> warning: no previously-included files matching '*~' found anywhere in 
> distribution
> warning: no previously-included files matching '.DS_Store' found anywhere in 
> distribution
> warning: no previously-included files matching '#*' found anywhere in 
> distribution
> warning: no previously-included files matching '*.py[ocd]' found anywhere in 
> distribution
> adding license file 'LICENSE'
> writing manifest file 'pandas.egg-info/SOURCES.txt'
> UPDATING /<>/.pybuild/cpython3_3.9/build/pandas/_version.py
> set /<>/.pybuild/cpython3_3.9/build/pandas/_version.py to '1.3.5'
> running build_ext
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/algos.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/arrays.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/groupby.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/hashing.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/hashtable.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/index.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/indexing.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/internals.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/interval.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/join.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/lib.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/missing.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/parsers.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/reduction.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/ops.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/ops_dispatch.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/properties.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/reshape.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/sparse.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslib.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/base.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/ccalendar.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/dtypes.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/conversion.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/fields.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/nattype.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/np_datetime.cpython-39-x86_64-linux-gnu.so
>  -> pandas/_libs/tslibs
> copying 
> /<>/.pybuild/cpython3_3.9/build/pandas/_libs/tslibs/offsets.cpython-39-x86_64-linux-g

Bug#1011343: WISHLIST: Offical ALL-IN-ONE images?

2022-06-22 Thread Zhang Boyang


Hi

On 2022/6/21 04:17, Thomas Schmitt wrote:

Hi,



Thanks for the detailed explanation! I think we can ignore minor 
differences, since creating a bit-for-bit reproducible image seems too 
hard for us.



md5sum.txt


Ouch. My script sorts the merged lines by the MD5 fields rather than by
the file paths.
Further this sorting is subject to locale settings, which is hardly
desirable, if the sequence of lines has a meaning at all.


I think maybe we should just create the md5sum from scratch? (or we can 
just reuse those md5sum of .deb only) Because some file definitely 
changed (like READMEs or files under /dists/...). A bad md5sum.txt will 
cause cdrom-checker in d-i to fail. (Fortunately it's not a standard 
step, but user can invoke it under `Advance options - Expert install')


Link: 
https://salsa.debian.org/installer-team/cdrom-checker/-/blob/master/main.c



Thank you again :)

Best Regards,
Zhang Boyang

Bug#1013374: O: emscripten -- LLVM-to-JavaScript Compiler

Package: wnpp
Severity: normal
X-Debbugs-Cc: Debian Javascript Maintainers 
, LLVM Packaging Team 
, Matrix Packaging Team 

Control: affects -1 src:emscripten

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I intend to orphan the emscripten package.

The package description is:
 Emscripten is an LLVM to JavaScript compiler. It takes LLVM bitcode, also
 called LLVM IR (which can be generated from C/C++ using Clang, or any other
 language that can be converted into LLVM bitcode) and compiles that into
 JavaScript, which can be run on the web (or anywhere else JavaScript can run).
 .
 Using Emscripten, you can
   * Compile C and C++ code into JavaScript and run that on the web
   * Run code in languages like Python as well, by compiling CPython from C
 to JavaScript and interpreting code in that on the web
 .
 Some uses of emscripten require additional packages:
  * setting WASM2C requires wabt (at least release 1.0.24-2).
  * emcmake requires cmake.
  * emconfigure may require automake.
  * emmake requires make.
  * emrun option --android requires adb.
  * emscons requires scons.
  * WebIDL Binder requires python3-ply.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK0B54ACgkQLHwxRsGg
ASHi2xAAkgaYJmycJ1DaTLmEPVivxjO13BH34EtAIOjZ2BKy2LLtns92AfYD/qXu
h/lQvETlEUsXH9kptV10kNLgKqGsZKUFJU06M1dzmpk7N6ez5pdEAWilsGJ3Bo0/
vkjn3L9EROQSn5YwViXe1AaaBh3afx4naeLfDiYAtBMgoMxFiOjLt+iyQ2ptj0El
+DaCV78cprqUuyJhEnbSJYlvRCBSrbRVp3OInV3lAt6wrtyNZGgYPUm91Z+Xtzl1
57X8Zj+vnsceox6Fs0BBYfzLJhlj0CRNQHmNkj2WoM0dJsVMIHVFFIKrpuIj6mko
1lg3r1mg0IWKDkJL5oEuOhdJDliTWpjsBfEy++RT8hLh+Bkjzww+5tj0fOqCPSJb
0XRrkHZ3C2i4fGUoP7zeR2lmnVQDVLZk+fG4Io47SSPro5fUlhQ20wXjlLXzVBHu
dKPKDWNBJ55+CTuzG8p11G/FTN0jigofxWSIYhvvyIoaATJHSol33Wg/RSlR0hEZ
rnkIvDLQDrgOeyxNFxSzMUchfaG3vCrn88N8p5FN6ee8XWicweaJPYTSgQssXX7n
2kzbz4CHuzCikAxShDRjdlU4BNhOf/atBbLhvHtIX05zwvxL+D9dv27kSKlmnrTg
Tb6KNuEjIqiexJcIHw7NcWWw0wStMEUt31lfP/ZJUge/n17Eaps=
=3ikY
-END PGP SIGNATURE-

Bug#991460: fix still not applied?

2022-06-22 Thread cacatoes


are you offering to do play-tests or can you also help compiling vcmi?


Mostly play-testing ;) I'm not into software dev, but I'm okay with some 
basic debug.


I packaged the current state of vcmi git and it fails to compile with 
these

errors:

https://salsa.debian.org/games-team/vcmi/-/jobs/2908349


I'm not familiar at all with CI, the error produced is not very 
explicit, it seems vcmiclient was built, but the Makefile fails and I'm 
not familiar enough to know how to dig that.


Thanks for your quick answer!

Bug#1013373: O: python-matrix-nio -- python no-IO library for the matrix chat protocol - Python3 library

Package: wnpp
Severity: normal
X-Debbugs-Cc: Matrix Packaging Team 
, Debian Python Team 

Control: affects -1 src:python-matrix-nio

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I intend to orphan the python-matrix-nio package.

The package description is:
 Nio is a multilayered Matrix client library.
 The underlying base layer doesn't do any IO on its own.
 On top of the base layer,
 a no-IO HTTP client implementation exists,
 as well as a full fledged batteries included asyncio layer
 using aiohttp.
 .
 Matrix is an open standard and lightweight protocol
 for real-time communication.
 .
 This package provides matrix-nio module
 for Python 3.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmK0Bw4ACgkQLHwxRsGg
ASERSA//axcpvh5HTvNDP0GIT7B7bFd53lsKb5Dx0tOFK7NeSgA+t6TmJJ0/wO+w
fCQ7VH5F6FJ7q0YWRXlGamFIdWVQrXYYzdgVWkuGHHQWSw96NV13tG6293CPJz/j
pPGxWRP06X6chvlZnc+X/7Z2kCSi8Vb2BXjUe/tYOuasYlHextyyWXzh2O+yYzoC
ZhCtyt0FPr27SI7KlcbqHb8AP2XU4tzWYWx6gAul7Zrpdqxgte8sR5pndljolcIU
eFB6jo9jBwjmQXSaGiMDTWRI/t2XobsKue6cLZ0F6cHu2K8skR8U+NcgFyGD1PbR
hMVpu2xWQiXtnFc0KkjogtQvgBvIHBWcY64QhWdsBkGaP3SqDGpUkWpgPDEW4vCW
R+FyLrUOJsoQVoS3ZoiwcdgOg6MjVa3uQzQsE+C4AVKCFWyPsoM+dmBe1n6mMvcw
Fi9L+6wMWy6hezr+u9/VvVKqSZCyyeX6/D/QohNWi+ar3KxvOkfvMy+m7Q5kPTTO
UKVLwlOFf3M6vykkeD/o/H2/AevgiUkXs8aXCA5o8pOL8iYejW9HzD0zK0E8n8iC
Xone/M+1trIjWW+1vP6seHz0VXPeV5BdIGmRX0hwnyBBO9Bk47Yy8h2DmvOSlbFQ
m8SOiqGghme7YKVWwohB+DlPhZNqZD2Ccon/C2k2x00WjSmTBHw=
=u/Zn
-END PGP SIGNATURE-

Bug#1013372: ITP: coq-dpdgraph -- Coq plugin to extract dependencies between Coq objects

2022-06-22 Thread Julien Puydt

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-dpdgraph
  Version : 1.0+8.15
  Upstream Author : A.Pacalet, Y.Bertot, O.Pons
* URL : https://github.com/coq-community/coq-dpdgraph
* License : LGPL-2.1
  Programming Lang: OCaml
  Description : Coq plugin to extract dependencies between Coq objects
 This package provides a plugin for Coq to extract dependencies
 between Coq objects and produce files with dependency information.
 .
 Coq is a proof assistant for higher-order logic.

I plan to maintain it within the Debian OCaml Maintainers team along with the
rest of the Coq-related packages.

Cheers,

J.Puydt

Bug#1013371: osmnx: online autopkgtest should be marked as flaky

2022-06-22 Thread Bas Couwenberg

Source: osmnx
Version: 1.2.0+ds-1
Severity: important
Tags: patch

Dear Maintainer,

The online autopkgtest tends to fail intermittently. The tests needed to be 
retried after the recent update of python-geopandas for example [0][1].

The attached patch adds the appropriate restrictions:

 * needs-internet
   The test needs unrestricted internet access, e.g. to download test data 
that's not shipped as a package, or to test a protocol implementation against a 
test server. Please also see the note about Network access later in this 
document.

 * flaky
   The test is expected to fail intermittently, and is not suitable for gating 
continuous integration. This indicates a bug in either the package under test, 
a dependency or the test itself, but such bugs can be difficult to fix, and it 
is often difficult to know when the bug has been fixed without running the test 
for a while. If a flaky test succeeds, it will be treated like any other 
successful test, but if it fails it will be treated as though it had been 
skipped.

[0] https://ci.debian.net/data/autopkgtest/testing/amd64/o/osmnx/22938879/log.gz
[1] https://ci.debian.net/data/autopkgtest/testing/i386/o/osmnx/22939502/log.gz

Kind Regards,

Bas
>From 1f92752ed5d1d722a08aaf2c27bf1b354a85ef15 Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Thu, 23 Jun 2022 07:23:29 +0200
Subject: Mark online autopkgtest as needs-internet and flaky.

The online test tends to fail intermitently.
---
 debian/tests/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/control b/debian/tests/control
index 91fe3f2..0d7d8c1 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -5,7 +5,7 @@ Depends:
  python3-folium, python3-scipy, python3-sklearn
 
 Test-Command: debian/tests/check online
-##Restrictions: needs-internet
+Restrictions: needs-internet, flaky
 Depends:
  python3-osmnx, python-osmnx-doc,
  python3-coverage, python3-pytest,
-- 
2.30.2

Bug#1013343: dbus-broker: CVE-2022-31212

2022-06-22 Thread Salvatore Bonaccorso

Hi Luca,

On Wed, Jun 22, 2022 at 08:06:14PM +0100, Luca Boccassi wrote:
> Control: found -1 26-1
> 
> On Wed, 22 Jun 2022 20:53:50 +0200 Salvatore Bonaccorso
>  wrote:
> > Hi,
> > 
> > On Wed, Jun 22, 2022 at 07:26:57PM +0100, Luca Boccassi wrote:
> > > Control: fixed -1 31-1
> > > 
> > > On Wed, 22 Jun 2022 11:36:32 +0200 =?UTF-
> 8?Q?Moritz_M=C3=BChlenhoff?=
> > >  wrote:
> > > > Source: dbus-broker
> > > > X-Debbugs-CC: t...@security.debian.org
> > > > Severity: important
> > > > Tags: security
> > > > 
> > > > Hi,
> > > > 
> > > > The following vulnerability was published for dbus-broker.
> > > > 
> > > > This was assigned CVE-2022-31212:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=2094718
> > > > 
> > > > 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-2022-31212
> > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31212
> > > > 
> > > > Please adjust the affected versions in the BTS as needed.
> > > 
> > > This appears to be already fixed in unstable and testing, at least
> > > according to this message on bugzilla that says v31 includes the
> fix:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2094720#c2
> > > 
> > > Although it is unclear precisely which commit/patch fixed it?
> > 
> > From https://bugzilla.suse.com/show_bug.cgi?id=1200332#c1??I would say
> > this is the following change:
> > 
> >
> https://github.com/c-util/c-shquote/commit/7fd15f8e272136955f7ffc37df29fbca9ddceca1
> > 
> > and so it should be fixed since dbus-broker/30-1 uploaded to
> unstable.
> 
> Got it - but the vulnerable code is then also present in v26, which is
> in Bullseye. Do we need a DSA? Otherwise I can just do a proposed-
> updates upload? Or should we ignore it altogether?
> 
> c_shquote_strnspn() is used by various functions in the submodule,
> which eventually chain to c_shquote_parse_argv(), which is used by
> src/launcher/launcher.c to parse the command line arguments on
> invocation.
> 
> Given the command line arguments are fixed in the unit files, it seems
> to me it requires elevated privileges to exploit, so severity seems
> minor at worst to me.

Gut feeling, to me this looks something which can be fixed in the
upcoming point release but would not need a DSA. Will leave the final
decision on it though to Moritz.

Salvatore

Bug#991460: fix still not applied?

2022-06-22 Thread Johannes Schauer Marin Rodrigues

Hi,

Quoting cacat...@tuxfamily.org (2022-06-22 19:07:56)
> Is there any chance to see this fix applied anytime soon? (this bug 
> prevents from playing a big part of the game).
> Upstream also has fixes for various (but less critical) things according 
> to commit logs.
> I'll try to be around for doing tests if a new package comes.

are you offering to do play-tests or can you also help compiling vcmi?

I packaged the current state of vcmi git and it fails to compile with these
errors:

https://salsa.debian.org/games-team/vcmi/-/jobs/2908349

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1002237: Any chance of re-introduction?

2022-06-22 Thread Bernhard

Dear maintainer

Is there a chance of re-introduction in bullseye?

The package "package-update-indicator" recommends "gnome-packagekit".
For this, i created the bug #1010802:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010802

Best regards and thank you
Bernhard

Bug#804638: same erre here

2022-06-22 Thread Ragnarok


i have same error on debian 11

Bug#934072: OpenRD images are gone

2022-06-22 Thread Martin Michlmayr

* Rick Thomas  [2022-06-22 20:05]:
> Great!  Thanks!  Now for testing: what exactly should I do with this
> tar-ball? I've been relying on Martin's instruction page at
> https://www.cyrius.com/debian/kirkwood/openrd/install/ which only
> mentions downloading two files (uImage and uInitrd) and putting them
> on a fat or ext2 USB-stick or MMC-card.

As far as I can tell, the build process appends the DTB to the kernel,
so just loading uImage and uInitrd (as per instructions) should work.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#934072: OpenRD images are gone

2022-06-22 Thread Rick Thomas

On Wed, Jun 22, 2022, at 7:27 AM, Cyril Brulebois wrote:
>> (If it builds, can you upload the images somewhere so Rick can test
>> them?)
>
> Sure, that was the plan all along.
>
> https://people.debian.org/~kibi/openrd4bullseye/ has the tarball after a
> full debian-installer build (it'll stay there until it's superseded by
> another attempt if required, or until that ends up being published in a
> point release).

Great!  Thanks!  Now for testing: what exactly should I do with this tar-ball? 
I've been relying on Martin's instruction page at 
https://www.cyrius.com/debian/kirkwood/openrd/install/ which only mentions 
downloading two files (uImage and uInitrd) and putting them on a fat or ext2 
USB-stick or MMC-card.

Downloading the tar-ball and un-tar-ing it I see there's a uImage and uInitrd 
file for ultimate, but there's also a .dtb file?  Should I include it on the 
USB-stick as well?  Is there anything else in the tar-ball I should be paying 
attention to?

I'm hoping to do preliminary testing tonight.  If I don't hear back before then 
(about midnight Pacific Daylight time) I'll go ahead and put all three files on 
a USB-stick and see what happens...

Enjoy!
Rick

Bug#925473: Accepted tomcat9 9.0.64-2 (source) into unstable

2022-06-22 Thread Emmanuel Bourg


Le 2022-06-22 19:14, Thorsten Glaser a écrit :

With these changes I think it's now possible to detach the sysvinit 
script

into an independent package (tomcat9-sysvinit?) enhancing tomcat9.


*WHY*?

The remaining changes do not change the way it is run under systemd
AT ALL.


Because separate packages means separate responsibilities. I'd like not
to maintain again sysvinit scripts in any Java package, we don't have
the time for this (we barely keep up with the Java and toolchain 
upgrades).


That said, I'm fine with applying some reasonable changes that ease the
use of sysvinit (like the logger change and the switch to the standalone
systemd-sysusers).



Having an extra binary package just for a handfull of scripts is
absolute overkill and ftpmasters from upon that, too.


If the number of packages matters, I've removed several unused 
lib*-java-doc
packages recently, so one more package for the Tomcat init script isn't 
really

an issue, the net change for the Java packages is negative.

To avoid the proliferation of sysvinit script packages the best approach
would be to group the scripts into a common package (maybe using a 
trigger
to install the script when a supported daemon is installed on the 
system).

This would lift the burden of maintaining these scripts off most DDs and
delegate the work to a small set of dedicated maintainers, properly
optimizing and harmonizing these scripts.

Emmanuel Bourg

Bug#1013260: coreutils: /bin/chown very slow in conjunction with storebackup

2022-06-22 Thread Adrian Kieß

Dear Michael,

yes I can reproduce this bug outside of storebackup, with the following
command — which storebackup uses:

# chown -h 0:0 /tmp/test

Sincerely, 

Adrian Kiess

On Tue, 21 Jun 2022 09:45:06 -0400
Michael Stone  wrote:

> On Mon, Jun 20, 2022 at 11:08:55AM +0200, Adrian Immanuel Kiess wrote:
> >in the current Debian/testing, storebackup fails to make a new backup, 
> >because
> >storebackup stalls during the backup process. From what I can see though ps
> >axuwww, storebackup stalls by calling /bin/chown, where every chown process
> >call takes seconds to minutes to complete.
> 
> Can you duplicate this outside of storebackup?

Bug#1011263: teem | d/rules: set DEB_CFLAGS_MAINT_APPEND = -ffp-contract=off in riscv64(Closes: #1011263) (!1)

2022-06-22 Thread 肖盛文


Control: tags -1 + pending


Thanks Boyuan Yang


在 2022/6/23 09:00, Boyuan Yang (@byang) 写道:

GitLab

Merge request !1 
 was 
merged


Project:Branches: atzlinux-guest/teem:fix-riscv64-test to 
science-team/teem:master


Author: xiao sheng wen(肖盛文)

—
Reply to this email directly or view it on GitLab 
.
You're receiving this email because of your account on 
salsa.debian.org. If you'd like to receive fewer emails, you can 
unsubscribe 
 
from this thread or adjust your notification settings.



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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#855145: [pkg-go] Bug#855145: prometheus: Console templates don't work out of the box

2022-06-22 Thread Rob Leslie

Attached is at least one patch needed to make the sample consoles usable.

-- 
Rob Leslie
r...@mars.org




prometheus.console_libraries.patch
Description: Binary data

Bug#1013370: libemf: Consider building on riscv64?

2022-06-22 Thread Boyuan Yang

Source: libemf
Version: 1.0.13-3
Severity: normal
Tags: sid  bookworm
X-Debbugs-CC: b...@debian.org

Dear Debian libemf package maintainer,

I noticed that the package libemf you maintain in Debian did not allow
building on riscv64 architecture. I am wondering whether there is any
specific reason for it. If not, can we try to enable package building on
riscv64 given the ongoing RISC-V development?

Thanks,
Boyuan Yang


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

Bug#992360: #992360 xfce4-notes-plugin in sid/bullseye

2022-06-22 Thread Andres Salomon

On 6/22/22 19:11, Andres Salomon wrote:

On Mon, 23 Aug 2021 15:50:31 +0200 Adam Borowski wrote:
[...]
>
> Thus: XFCE guys, please upload to unstable and bullseye-backports!
> Thanks for your good work so far.

>

Can we please get an upload of xfce4-notes-plugin 1.9.0 to unstable? 
I'm happy to do a backport to bullseye once it migrates to bookworm.

BTW, it's probably safe to remove the versioning in the build-deps 
(other than debhelper-compat, obviously) for this package. Bullseye 
released with libxfce*/libxfconf/xfce4-dev-tools 4.16, which is equal to 
or higher than all the build-deps.

Bug#992360: #992360 xfce4-notes-plugin in sid/bullseye

2022-06-22 Thread Andres Salomon

On Mon, 23 Aug 2021 15:50:31 +0200 Adam Borowski wrote:
[...]
>
> Thus: XFCE guys, please upload to unstable and bullseye-backports!
> Thanks for your good work so far.

>

Can we please get an upload of xfce4-notes-plugin 1.9.0 to unstable? I'm 
happy to do a backport to bullseye once it migrates to bookworm.

I realize that 1.9 is a development release, but

a) having something that's a little buggy is better than having nothing,

b) if it's done relatively soon, we can shake out any potential RC bugs 
well in advance of the upcoming bookworm freeze (rather than having 2 
debian releases in a row missing this package), and

c) despite being released back in Jan 2021, the only fix to git since 
then was for a text color change*. There's also a ton of translation 
update commits, which tells me that upstream is still doing at least 
some work on it. If it were a buggy unusable mess, there would probably 
be more fixes by now.

I've built it for myself and am currently running it on bullseye, and so 
far it's working fine. Please consider uploading it to sid.

Thanks,

Andres

 * 
https://gitlab.xfce.org/panel-plugins/xfce4-notes-plugin/-/commit/d545774d9a0eb078edced191823405f0d630549b

Bug#1000250: Dependency on patatt

2022-06-22 Thread Hector Oron

Hello,

On Sat, 20 Nov 2021 at 07:33, Anuradha Weeraman  wrote:
> Patatt (https://git.kernel.org/pub/scm/utils/patatt/patatt.git) is now
> in Debian unstable and patch attestation functionality has been moved
> to it, so requesting that a dependency be included in b4 for patatt.

This is now done, however, the recommended patatt version is patatt>=0.5,<2.0.
I'll update the package to versioned dependency once this is updated
in unstable.

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#764785: schroot: setup script to copy apt archives from host to chroot

2022-06-22 Thread Christoph Biedl

Control: tags 764785 pending

Felipe Sateler wrote...

> For systems without an apt proxy the local apt cache can be very useful
> to avoid downloading stuff multiple times. Thus I created a small
> script (attached) to copy the local apt cache contents into the chroot,
> and then copy them back to the host on stop. pbuilder does this as well.

This was included in the sources of schroot 1.6.10-13 but not in the
Debian package. Now in the list for the next upload.

Christoph


signature.asc
Description: PGP signature

Bug#1013364: dicomnifti: autopkgtest failure: number of repetitions is less than two

2022-06-22 Thread Valerio Luccio


Puzzling, this package has not changed since November 2017.

Not sure what I'm supposed to do next.

Thanks,

On 6/22/22 4:15 PM, Paul Gevers wrote:


Source: dicomnifti
Version: 2.33.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package dicomnifti, great. 
However, it fails on i386 and s390x. Currently this failure is 
blocking the migration to testing [1]. Can you please investigate the 
situation and fix it?


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

More information about this bug and the reason for filing it can be 
found on

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

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

https://ci.debian.net/data/autopkgtest/testing/i386/d/dicomnifti/22218046/log.gz 




 CreateNIfTIHeader: WARNING: number of repetitions is less 
than two

 time between volumes is set to zero
output.nii: FAILED
md5sum: WARNING: 1 computed checksum did NOT match
autopkgtest [15:10:43]: test run-unit-test



--
Valerio Luccio  
High Performance Computing  10 Astor Place, Room 416D
New York University New York, NY 10003

   "In an open world, who needs windows or gates ?"

Bug#989720: No need for a fix

2022-06-22 Thread Thomas Goirand


On 6/22/22 18:19, Antoine Beaupré wrote:

It's against debian/yoga, but I don't actually know what I mean or which
branch I'm supposed to be using there.


That's the latest OpenStack stable release. You don't need to know that, 
the only thing you need to know in the OpenStack team, is that you 
should send the merge request against whatever is the current default 
branch.



The patch is:

https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/10.patch


Thanks a lot, merged!


I also filed a MR against the release notes to try to get the word out
there (as we can't really update the NEWS file anymore):

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/133


Great.


I guess we can close this ticket when both are merged?


Yeah. FYI, I'm about to release 2.17.x in Debian. I'll make sure it 
closes this bug.


Cheers,

Thomas Goirand (zigo)

Bug#1013343: dbus-broker: CVE-2022-31212

2022-06-22 Thread Luca Boccassi

On Wed, 22 Jun 2022 20:06:14 +0100 Luca Boccassi 
wrote:
> Control: found -1 26-1
> 
> On Wed, 22 Jun 2022 20:53:50 +0200 Salvatore Bonaccorso
>  wrote:
> > Hi,
> > 
> > On Wed, Jun 22, 2022 at 07:26:57PM +0100, Luca Boccassi wrote:
> > > Control: fixed -1 31-1
> > > 
> > > On Wed, 22 Jun 2022 11:36:32 +0200 =?UTF-
> 8?Q?Moritz_M=C3=BChlenhoff?=
> > >  wrote:
> > > > Source: dbus-broker
> > > > X-Debbugs-CC: t...@security.debian.org
> > > > Severity: important
> > > > Tags: security
> > > > 
> > > > Hi,
> > > > 
> > > > The following vulnerability was published for dbus-broker.
> > > > 
> > > > This was assigned CVE-2022-31212:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=2094718
> > > > 
> > > > 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-2022-31212
> > > >
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31212
> > > > 
> > > > Please adjust the affected versions in the BTS as needed.
> > > 
> > > This appears to be already fixed in unstable and testing, at
least
> > > according to this message on bugzilla that says v31 includes the
> fix:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2094720#c2
> > > 
> > > Although it is unclear precisely which commit/patch fixed it?
> > 
> > From https://bugzilla.suse.com/show_bug.cgi?id=1200332#c1 I would
say
> > this is the following change:
> > 
> >
>
https://github.com/c-util/c-shquote/commit/7fd15f8e272136955f7ffc37df29fbca9ddceca1
> > 
> > and so it should be fixed since dbus-broker/30-1 uploaded to
> unstable.
> 
> Got it - but the vulnerable code is then also present in v26, which
is
> in Bullseye. Do we need a DSA? Otherwise I can just do a proposed-
> updates upload? Or should we ignore it altogether?
> 
> c_shquote_strnspn() is used by various functions in the submodule,
> which eventually chain to c_shquote_parse_argv(), which is used by
> src/launcher/launcher.c to parse the command line arguments on
> invocation.

The backport is trivial, shall I do an upload to bullseye-security?

-- 
Kind regards,
Luca Boccassi


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

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

2022-06-22 Thread Diederik de Haas

On Wednesday, 22 June 2022 23:15:46 CEST Diederik de Haas wrote:
> Via sources.list.erb I found that "<%= node['debian_release'] %>-backports"
> gets enabled, which I assume results in Stable-backports.
> It appears that various tools get installed (but I don't see qemu mentioned
> (explicitly)), but I do see 'virt-what' and the package description seems to
> indicate it may be useful to figure out detail of the VM.

Forgot to add: Backports seems available but it needs to be explicitly 
specified to install packages from it, which _I_ didn't see, but I'm not 
familiar with your (build) systems.
I don't know if it's an option, but stable-bpo has 1:7.0+dfsg-2~bpo11+2

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

Bug#1013367: [600]

2022-06-22 Thread Abdeu Tahar

Package: 600
Version: SoapFault - faultcode: 'SOAP-ENV:Server' faultstring: 'Processing
Failure' faultactor: 'null' detail: org.kxml2.kdom.Node@81e5592
Severity: 
Tags: 
X-Debbugs-CC: 
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

* What led up to the situation?
* What exactly did you do (or not do) that was effective (orineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?

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

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

2022-06-22 Thread Diederik de Haas

Hi Paul,

On Wednesday, 22 June 2022 21:57:06 CEST Paul Gevers wrote:
> On 21-06-2022 23:19, Diederik de Haas wrote:
> 
> > I think that the install logs aren't that important (anymore) as the
> > issue/symptoms appear to be the same:
> > - some swap action resulting in some failure
> > - CPU gets stuck
> > - watchdog triggers a reboot
> 
> If the reboot would actually happen/finish, I wouldn't have problems of 
> the hanging host. The issues I spotted required a manual reboot (and 
> that's why I spotted them).

Hmm ...interesting. AFAIK that is a watchdog's task.
And I was certain I saw sth about it as I've seen (a yet to be reported) an 
issue related to watchdog myself, hence why I remembered it.

On Saturday, 4 December 2021 22:44:38 CEST Paul Gevers wrote:
> I noticed in the logs that *after* the reported kernel bug but before
> the actual hang, I see multiple instances of:
> watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [apt-get:2204621]
> and
> watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kcompactd0:40]
> on ci-worker-arm64-07.

And here is where I saw it. (My watchdog issue doesn't cause a hang btw)

> > How is swap configured on these devices?
> 
> https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/ba
> sics/default.rb#L3 until line 11

Not familiar with Ruby, but IIUC a swap file get created half the size of RAM.
I _think_ the swapon command isn't technically needed as it will be done on 
bootup through fstab, but shouldn't hurt either. Seems fine :)

> > I *assumed* it was running on arm64 (native) hardware and was about to
> > ask specifics about it and then I noticed this:
> > Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge [1b36:0008]
> > 
> > Qemu. Quite likely unrelated, but a while back I had an issue with qemu
> > in building arm64 images: https://bugs.debian.org/988174
> 
> hmm, OK, right (I forgot that I knew this).
> 
> > I think it would be useful to know which qemu version(s) were used.
> 
> Is there any way to know from inside the VM?

If you have access to the host, APT should be able to tell you.

Via sources.list.erb I found that "<%= node['debian_release'] %>-backports" 
gets enabled, which I assume results in Stable-backports.
It appears that various tools get installed (but I don't see qemu mentioned 
(explicitly), but I do see 'virt-what' and the package description seems to 
indicate it may be useful to figure out detail of the VM.

@mjt, I have two questions for you:
1) do you know if/how the qemu version can be queried from within the VM?
2) Are you aware of potential issues wrt hangs in arm64 VM created with Qemu?
Or IOW, could you take a look at this bug and can you give tips which could 
help in tracking down the cause and subsequently the solution?

TIA,
  Diederik

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

Bug#1013186: python3-geopandas: geopandas is missing PROJ data directory

2022-06-22 Thread Akkana Peck

You're right. I tried it in a totally clean environment with no
virtualenvs and I don't get the warning. I must have something
in my regular venv that's interfering.

Sorry for the bogus bug report!

Bug#1013366: RM: tboot [i386] -- ROM; outdated i386 binaries

2022-06-22 Thread Timo Lindfors


Package: ftp.debian.org
Severity: normal

Can you please remove tboot 1.10.5-1 i386 binaries so that 1.10.5-3 can 
migrate to testing? Version 1.10.5-3 includes binary packages only for 
amd64.


-Timo

Bug#1012369: dt-schema: Please update to the latest version

2022-06-22 Thread Bastian Germann


It is now possible to publish the latest version in experimental because the 
needed jsonschema is available there.

Bug#1013365: python-aiortc: autopkgtest regression on armhf: [Errno 542398533] Generic error in an external library


Source: python-aiortc
Version: 1.3.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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


   passfail
python-aiortc  from testing1.3.2-1
all others from testingfrom testing

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

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


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/armhf/p/python-aiortc/22926423/log.gz

=== FAILURES 
===
_ MediaRecorderTest.test_video_mp4_uhd 
_


self = testMethod=test_video_mp4_uhd>


@asynctest
async def test_video_mp4_uhd(self):
path = self.temporary_path("test.mp4")
recorder = MediaRecorder(path)
recorder.addTrack(VideoStreamTrackUhd())
await recorder.start()
await asyncio.sleep(2)

  await recorder.stop()


tests/test_contrib_media.py:651: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/aiortc/contrib/media.py:383: in stop

for packet in context.stream.encode(None):
av/stream.pyx:164: in av.stream.Stream.encode
???
av/codec/context.pyx:492: in av.codec.context.CodecContext.encode
???
av/codec/context.pyx:411: in 
av.codec.context.CodecContext._send_frame_and_recv

???
av/codec/context.pyx:469: in av.codec.context.CodecContext._recv_packet
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _

  ???
E   av.error.ExternalError: [Errno 542398533] Generic error in an 
external library


av/error.pyx:336: ExternalError
- Captured stderr call 
-

[libx264 @ 0x1425410] using cpu capabilities: ARMv6 NEON
[libx264 @ 0x1425410] profile High, level 5.1, 4:2:0, 8-bit
[libx264 @ 0x1425410] 264 - core 164 r3095 baee400 - H.264/MPEG-4 AVC 
codec - Copyleft 2003-2022 - http://www.videolan.org/x264.html - 
options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 
psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 
8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 
threads=33 lookahead_threads=16 sliced_threads=1 slices=33 nr=0 
decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 
b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 
keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 
rc=abr mbtree=1 bitrate=1024 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 
qpstep=4 ip_ratio=1.40 aq=1:1.00

x264 [error]: malloc of size 26198688 failed
x264 [error]: malloc of size 43687792 failed
 H264Test.test_encoder 
_


self = 
frame = 
force_keyframe = False

def _encode_frame(
self, frame: av.VideoFrame, force_keyframe: bool
) -> Iterator[bytes]:
if self.codec and (
frame.width != self.codec.width
or frame.height != self.codec.height
# we only adjust bitrate if it changes by over 10%
or abs(self.target_bitrate - self.codec.bit_rate) / 
self.codec.bit_rate

> 0.1
):
self.buffer_data = b""
self.buffer_pts = None
self.codec = None
# reset the picture type, otherwise no B-frames are produced
frame.pict_type = av.video.frame.PictureType.NONE
if self.codec is None:
try:

  self.codec, self.codec_buffering = create_encoder_context(
"h264_omx", frame.width, frame.height, 
bitrate=self.target_bitrate

)

/usr/lib/python3/dist-packages/aiortc/codecs/h264.py:285: _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

codec_name = 'h264_omx', width = 640, height = 480, bitrate = 100

def create_encoder_context(
codec_name: str, width: int, height: int, bitrate: int
) -> Tuple[av.CodecContext, bool]:
codec = av.CodecContext.create(codec_name, "w")
codec.width = width
codec.height = height
codec.bit_rate = bitrate
codec.pix_fmt = "yuv420p"
codec.framerate = fractions.Fraction(MAX_FRAME_RATE, 1)
codec.time_base = fractions.Fraction(1, MAX_FRAME_RATE)
codec.options = {
"profile": "baseline",
"level": "31",

Bug#1013364: dicomnifti: autopkgtest failure: number of repetitions is less than two


Source: dicomnifti
Version: 2.33.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package dicomnifti, great. 
However, it fails on i386 and s390x. Currently this failure is blocking 
the migration to testing [1]. Can you please investigate the situation 
and fix it?


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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/i386/d/dicomnifti/22218046/log.gz


 CreateNIfTIHeader: WARNING: number of repetitions is less than two
 time between volumes is set to zero
output.nii: FAILED
md5sum: WARNING: 1 computed checksum did NOT match
autopkgtest [15:10:43]: test run-unit-test



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004831: transition: ffmpeg

2022-06-22 Thread Sebastian Ramacher

Control: tags -1 confirmed

On 2022-02-01 23:51:57 +0100, Sebastian Ramacher wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Tags: moreinfo
> X-Debbugs-Cc: sramac...@debian.org, debian-multime...@lists.debian.org
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-ffmpeg.html
> Control: block -1 by 1004570
> Control: block -1 by 1004573
> Control: block -1 by 1004574
> Control: block -1 by 1004578
> Control: block -1 by 1004579
> Control: block -1 by 1004581
> Control: block -1 by 1004584
> Control: block -1 by 1004585
> Control: block -1 by 1004587
> Control: block -1 by 1004594
> Control: block -1 by 1004595
> Control: block -1 by 1004596
> Control: block -1 by 1004597
> Control: block -1 by 1004598
> Control: block -1 by 1004600
> Control: block -1 by 1004610
> Control: block -1 by 1004612
> Control: block -1 by 1004613
> Control: block -1 by 1004616
> Control: block -1 by 1004620
> Control: block -1 by 1004622
> Control: block -1 by 1004623
> Control: block -1 by 1004624
> Control: block -1 by 1004625
> Control: block -1 by 1004626
> Control: block -1 by 1004627
> Control: block -1 by 1004628
> Control: block -1 by 1004629
> Control: block -1 by 1004630
> Control: block -1 by 1004631
> Control: block -1 by 1004632
> Control: block -1 by 1004633
> Control: block -1 by 1004634
> Control: block -1 by 1004636
> Control: block -1 by 1004637
> Control: block -1 by 1004638
> Control: block -1 by 1004639
> Control: block -1 by 1004640
> Control: block -1 by 1004641
> Control: block -1 by 1004642
> Control: block -1 by 1004718
> Control: block -1 by 1004719
> Control: block -1 by 1004720
> Control: block -1 by 1004721
> Control: block -1 by 1004722
> Control: block -1 by 1004760
> Control: block -1 by 1004762
> Control: block -1 by 1004763
> Control: block -1 by 1004764
> Control: block -1 by 1004766
> Control: block -1 by 1004767
> Control: block -1 by 1004768
> Control: block -1 by 1004769
> Control: block -1 by 1004770
> Control: block -1 by 1004771
> Control: block -1 by 1004772
> Control: block -1 by 1004774
> Control: block -1 by 1004776
> Control: block -1 by 1004777
> Control: block -1 by 1004778
> Control: block -1 by 1004779
> Control: block -1 by 1004782
> Control: block -1 by 1004783
> Control: block -1 by 1004784
> Control: block -1 by 1004785
> Control: block -1 by 1004787
> Control: block -1 by 1004788
> Control: block -1 by 1004789
> Control: block -1 by 1004791
> Control: block -1 by 1004792
> Control: block -1 by 1004793
> Control: block -1 by 1004794
> Control: block -1 by 1004795
> Control: block -1 by 1004796
> Control: block -1 by 1004797
> Control: block -1 by 1004799
> Control: block -1 by 1004800
> Control: block -1 by 1004801
> Control: block -1 by 1004802
> Control: block -1 by 1004803
> Control: block -1 by 1004804
> Control: block -1 by 1004805
> Control: block -1 by 1004806
> Control: block -1 by 1004807
> Control: block -1 by 1004808
> Control: block -1 by 1004809
> Control: block -1 by 1004810
> Control: block -1 by 1004811
> Control: block -1 by 1004812
> Control: block -1 by 1004813
> Control: block -1 by 1004814
> Control: block -1 by 1004816
> Control: block -1 by 1004817
> Control: block -1 by 1004819
> Control: block -1 by 1004820
> Control: block -1 by 1004821
> Control: block -1 by 1004822
> Control: block -1 by 1004823
> Control: block -1 by 1004825
> Control: block -1 by 1004826
> Control: block -1 by 1004828
> 
> ffmpeg got a new major release including API and ABI breakage. Hence, it
> needs a transition. The reverse dependencies are not yet ready, so this
> bug is just a heads up and should help to track progress. Due to
> ffmpeg's security record, we should complete this transition for
> bookworm.

Reverse dependencies had 4 months to fix their bugs, so I'm going ahead
with this one.

Cheers

> 
> Bugs for the reverse dependencies have been filed and they are available
> at
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=sramacher%40debian.org&tag=ffmpeg5.0
> 
> Cheers
> -- 
> Sebastian Ramacher



-- 
Sebastian Ramacher

Bug#1013363: fonttools breaks glyphslib autopkgtest: AssertionError: *.designspace file is different from expected


Source: fonttools, glyphslib
Control: found -1 fonttools/4.33.3-1
Control: found -1 glyphslib/5.3.2+ds1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
fonttools  from testing4.33.3-1
glyphslib  from testing5.3.2+ds1-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of fonttools to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/g/glyphslib/22951714/log.gz

=== FAILURES 
===
_ test_designspace_generation_regular_same_family_name[defcon] 
_


tmpdir = 
local('/tmp/pytest-of-debci/pytest-0/test_designspace_generation_re0')
ufo_module = '/usr/lib/python3/dist-packages/defcon/__init__.py'>


def test_designspace_generation_regular_same_family_name(tmpdir, 
ufo_module):

ufo_Lt = ufo_module.Font()
ufo_Lt.info.familyName = "CoolFoundry Examplary Serif"
ufo_Lt.info.styleName = "Light"
ufo_Lt.info.openTypeOS2WeightClass = 300
ufo_Rg = ufo_module.Font()
ufo_Rg.info.familyName = "CoolFoundry Examplary Serif"
ufo_Rg.info.styleName = "Regular"
ufo_Rg.info.openTypeOS2WeightClass = 400
ufo_Md = ufo_module.Font()
ufo_Md.info.familyName = "CoolFoundry Examplary Serif"
ufo_Md.info.styleName = "Medium"
ufo_Md.info.openTypeOS2WeightClass = 500
ufo_Bd = ufo_module.Font()
ufo_Bd.info.familyName = "CoolFoundry Examplary Serif"
ufo_Bd.info.styleName = "Bold"
ufo_Bd.info.openTypeOS2WeightClass = 700
ufo_ExBd = ufo_module.Font()
ufo_ExBd.info.familyName = "CoolFoundry Examplary Serif"
ufo_ExBd.info.styleName = "XBold"
ufo_ExBd.info.openTypeOS2WeightClass = 800
font = to_glyphs([ufo_Lt, ufo_Rg, ufo_Md, ufo_Bd, ufo_ExBd])
designspace = to_designspace(font, ufo_module=ufo_module)
path = os.path.join(str(tmpdir), "actual.designspace")
designspace.write(path)
expected_path = os.path.join(
os.path.dirname(__file__), "..", "data", 
"DesignspaceGenTestRegular.designspace"

)
>   assert (
len(main.diff_files(path, expected_path, 
formatter=formatting.DiffFormatter()))

== 0
)
E   assert 50 == 0
E+  where 50 = len('[update-attribute, /designspace[1], format, 
"4.1"]')
E+where '[update-attribute, /designspace[1], format, "4.1"]' 
= 0x7f6942f867a0>('/tmp/pytest-of-debci/pytest-0/test_designspace_generation_re0/actual.designspace', 
'/tmp/autopkgtest-lxc.p3l2ko5z/downtmp/build.Bjv/src/tests/builder/../data/DesignspaceGenTestRegular.designspace', 
formatter=)
E+  where  = 
main.diff_files
E+  and   0x7f69422765f0> = ()
E+where  = 
formatting.DiffFormatter


tests/builder/designspace_gen_test.py:69: AssertionError
_ test_designspace_generation_italic_same_family_name[defcon] 
__


tmpdir = 
local('/tmp/pytest-of-debci/pytest-0/test_designspace_generation_it0')
ufo_module = '/usr/lib/python3/dist-packages/defcon/__init__.py'>


def test_designspace_generation_italic_same_family_name(tmpdir, 
ufo_module):

ufo_Lt = ufo_module.Font()
ufo_Lt.info.familyName = "CoolFoundry Examplary Serif"
ufo_Lt.info.styleName = "Light Italic"
ufo_Lt.info.openTypeOS2WeightClass = 300
ufo_Lt.info.italicAngle = -11
ufo_Rg = ufo_module.Font()
ufo_Rg.info.familyName = "CoolFoundry Examplary Serif"
ufo_Rg.info.styleName = "Regular Italic"
ufo_Rg.info.openTypeOS2WeightClass = 400
ufo_Rg.info.italicAngle = -11
ufo_Md = ufo_module.Font()
ufo_Md.info.familyName = "CoolFoundry Examplary Serif"
ufo_Md.info.styleName = "Medium Italic"
ufo_Md.info.openTypeOS2WeightClass = 500
ufo_Md.info.italicAngle = -11
ufo_Bd = ufo_module.Font()
ufo_Bd.info.familyName = "CoolFoundry Examplary Serif"
ufo_Bd.info.styleName = "Bold Italic"
ufo_Bd.info.openTypeOS2WeightClass = 700
ufo_Bd.info

Bug#1013362: src:alt-ergo: fails to migrate to testing for too long: FTBFS on armel, mips64el and mipsel


Source: alt-ergo
Version: 2.0.0-8
Severity: serious
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:alt-ergo has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. The latest uploads of your 
package failed to build on armel, mips64el and mipsel [3].


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=alt-ergo
[3] https://buildd.debian.org/status/package.php?p=alt-ergo


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013361: ITP: ruptime -- poor man's ruptime

2022-06-22 Thread Gürkan Myczko


Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ruptime
  Version : 1.0
  Upstream Authors: 2022 Alex Myczko
  URL : https://github.com/alexmyczko/ruptime
* License : “Commons Clause” License Condition v1.0
  Description : poor man's ruptime
 Re-implementation of the old r-software from 1982. Its main
advantage over original ruptime is encrypted traffic and
multinetwork ruptime.

* the package is intended to non-free due to licensing
* it'll provide ruptime and ruptimed binary packages (where ruptimed 
source was not released yet)

Bug#1013360: src:ruby3.0: fails to migrate to testing for too long: causes autopkgtest failure on ppc64el


Source: ruby3.0
Version: 3.0.3-1
Severity: serious
Control: close -1 3.0.4-7
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

I know you know, but to track it, I'm still filing this bug.

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ruby3.0 has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. 3.0.4 triggers two autopkgtest 
regressions: "Compaction isn't available on this platform".


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!

Hi Diederik,

On 21-06-2022 23:19, Diederik de Haas wrote:

I think that the install logs aren't that important (anymore) as the issue/
symptoms appear to be the same:
- some swap action resulting in some failure
- CPU gets stuck
- watchdog triggers a reboot

If the reboot would actually happen/finish, I wouldn't have problems of
the hanging host. The issues I spotted required a manual reboot (and
that's why I spotted them).

How is swap configured on these devices?

https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/basics/default.rb#L3
until line 11

Yeah, I _assumed_ as such, but assumptions can be dangerous ;-)

Total ACK.

Normally I scroll (hard) by the hardware listings as that rarely says anything
to me. And I did that before too, but just now I made an important discovery.

I *assumed* it was running on arm64 (native) hardware and was about to ask
specifics about it and then I noticed this:
Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge [1b36:0008]

Qemu. Quite likely unrelated, but a while back I had an issue with qemu in
building arm64 images: https://bugs.debian.org/988174

hmm, OK, right (I forgot that I knew this).

I think it would be useful to know which qemu version(s) were used.

Is there any way to know from inside the VM?

If the issue does occur again, I think it would be useful to bring 'upstream'
into the conversation. They likely can bring much more useful input into this
then (f.e.) I could. Also, if upstream is made aware there is an issue (even
infrequent), then they can make the most informed choice what to do with it.

Ack.

Paul

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.


Hi,

On 22-06-2022 20:04, Moritz Mühlenhoff wrote:

Or if the goal is rather to experiment and expose BabaSSL to the many archs
we have in Debian, then keep it in unstable only by filing a bug to block
it from testing.


Or better: experimental, to avoid packages starting to (build-)depend on it.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012761: ITP: shtab -- generator for shell tab completion files for python projects

2022-06-22 Thread Stephan Lachnit

Hi Felix,

I will take a look at the package sometime next week. I'm currently packing
my stuff to move to Geneva, so I don't really have that much time right
now. Feel free to ping though in case I forget :)

Cheers,
Stephan

On Tue, Jun 21, 2022 at 4:30 PM Moessbauer, Felix <
felix.moessba...@siemens.com> wrote:

> Dear maintainers,
>
> the initial packaging of shtab is implemented in [1] and should be ready
> for a review.
>
> @stephan It would be great if you could sponsor this package.
> We talked about that at Debian Reunion Hamburg.
>
> [1] https://salsa.debian.org/python-team/packages/shtab
>
> Best regards,
> Felix Moessbauer
> Siemens AG
>

Bug#1013343: dbus-broker: CVE-2022-31212

2022-06-22 Thread Luca Boccassi

Control: found -1 26-1

On Wed, 22 Jun 2022 20:53:50 +0200 Salvatore Bonaccorso
 wrote:
> Hi,
> 
> On Wed, Jun 22, 2022 at 07:26:57PM +0100, Luca Boccassi wrote:
> > Control: fixed -1 31-1
> > 
> > On Wed, 22 Jun 2022 11:36:32 +0200 =?UTF-
8?Q?Moritz_M=C3=BChlenhoff?=
> >  wrote:
> > > Source: dbus-broker
> > > X-Debbugs-CC: t...@security.debian.org
> > > Severity: important
> > > Tags: security
> > > 
> > > Hi,
> > > 
> > > The following vulnerability was published for dbus-broker.
> > > 
> > > This was assigned CVE-2022-31212:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2094718
> > > 
> > > 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-2022-31212
> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31212
> > > 
> > > Please adjust the affected versions in the BTS as needed.
> > 
> > This appears to be already fixed in unstable and testing, at least
> > according to this message on bugzilla that says v31 includes the
fix:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2094720#c2
> > 
> > Although it is unclear precisely which commit/patch fixed it?
> 
> From https://bugzilla.suse.com/show_bug.cgi?id=1200332#c1 I would say
> this is the following change:
> 
>
https://github.com/c-util/c-shquote/commit/7fd15f8e272136955f7ffc37df29fbca9ddceca1
> 
> and so it should be fixed since dbus-broker/30-1 uploaded to
unstable.

Got it - but the vulnerable code is then also present in v26, which is
in Bullseye. Do we need a DSA? Otherwise I can just do a proposed-
updates upload? Or should we ignore it altogether?

c_shquote_strnspn() is used by various functions in the submodule,
which eventually chain to c_shquote_parse_argv(), which is used by
src/launcher/launcher.c to parse the command line arguments on
invocation.

Given the command line arguments are fixed in the unit files, it seems
to me it requires elevated privileges to exploit, so severity seems
minor at worst to me.

-- 
Kind regards,
Luca Boccassi


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

Bug#1013343: dbus-broker: CVE-2022-31212

2022-06-22 Thread Salvatore Bonaccorso

Hi,

On Wed, Jun 22, 2022 at 07:26:57PM +0100, Luca Boccassi wrote:
> Control: fixed -1 31-1
> 
> On Wed, 22 Jun 2022 11:36:32 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?=
>  wrote:
> > Source: dbus-broker
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for dbus-broker.
> > 
> > This was assigned CVE-2022-31212:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2094718
> > 
> > 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-2022-31212
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31212
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> This appears to be already fixed in unstable and testing, at least
> according to this message on bugzilla that says v31 includes the fix:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2094720#c2
> 
> Although it is unclear precisely which commit/patch fixed it?

>From https://bugzilla.suse.com/show_bug.cgi?id=1200332#c1 I would say
this is the following change:

https://github.com/c-util/c-shquote/commit/7fd15f8e272136955f7ffc37df29fbca9ddceca1

and so it should be fixed since dbus-broker/30-1 uploaded to unstable.

Regards,
Salvatore

Bug#1007717: Ballot and call for votes

2022-06-22 Thread Simon McVittie

On Mon, 20 Jun 2022 at 17:31:16 -0700, Sean Whitton wrote:
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.

I vote C > A > X > N.

smcv


signature.asc
Description: PGP signature

Bug#1013343: dbus-broker: CVE-2022-31212

2022-06-22 Thread Luca Boccassi

Control: fixed -1 31-1

On Wed, 22 Jun 2022 11:36:32 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?=
 wrote:
> Source: dbus-broker
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for dbus-broker.
> 
> This was assigned CVE-2022-31212:
> https://bugzilla.redhat.com/show_bug.cgi?id=2094718
> 
> 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-2022-31212
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31212
> 
> Please adjust the affected versions in the BTS as needed.

This appears to be already fixed in unstable and testing, at least
according to this message on bugzilla that says v31 includes the fix:

https://bugzilla.redhat.com/show_bug.cgi?id=2094720#c2

Although it is unclear precisely which commit/patch fixed it?

-- 
Kind regards,
Luca Boccassi


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

Bug#1013358: chktex: FTBFS when TERM is not set

2022-06-22 Thread Graham Inggs

Source: chktex
Version: 1.7.6-5
Tags: ftbfs patch

Hi Maintainer

The latest upload of chktex FTBFS when TERM is not set, e.g. on
reproducible builds [1], where it built previously.  I've copied what
I hope is the relevant part of the log below.

The following patch works for me:

--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,9 @@
 # Ensure texlive respects SOURCE_DATE_EPOCH
 export FORCE_SOURCE_DATE=1

+# Prevent FTBFS when TERM is not set
+export TERM=linux
+
 %:
  dh $@

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/chktex.html


   dh_auto_test
make -j15 test "TESTSUITEFLAGS=-j15 --verbose" VERBOSE=1
make[1]: Entering directory '/build/1st/chktex-1.7.6'
./chktex -mall ./Test.tex
./chktex: WARNING -- Could not find global resource file.
ChkTeX v1.7.6 - Copyright 1995-96 Jens T. Berger Thielemann.
Compiled with PCRE regex support.
./chktex: ERROR -- Terminal type `(null)' is not defined.
make[1]: *** [Makefile:186: test] Error 1
make[1]: Leaving directory '/build/1st/chktex-1.7.6'
dh_auto_test: error: make -j15 test "TESTSUITEFLAGS=-j15 --verbose"
VERBOSE=1 returned exit code 2
make: *** [debian/rules:10: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Bug#1013132: ITP: BabaSSL -- BabaSSL is a base library for modern cryptography and communication security protocols.

2022-06-22 Thread Moritz Mühlenhoff

Am Wed, Jun 22, 2022 at 02:28:36PM + schrieb Lance Lin:
> Hello Marco,
> 
> > What is the plan? Are there any current or new packages which will
> > depend on it?
> 
> Yes, from my understanding it is a "drop in" replacement for OpenSSL. One of 
> my packages (Workflow) uses it but can also use OpenSSL. 

Then make it use OpenSSL. If there's anything exciting in BabaSSL, they
should submit it for inclusion in OpenSSL. We should aim for fewer
crypto libraries in our stable releases, not more.

Or if the goal is rather to experiment and expose BabaSSL to the many archs
we have in Debian, then keep it in unstable only by filing a bug to block
it from testing.

Cheers,
Moritz

Bug#1013357: ITP: rust-nom-bibtex -- BibTeX parser using nom

Quoting Nilesh Patra (2022-06-22 19:21:15)
> On 6/22/22 10:40 PM, Jonas Smedegaard wrote:
> > This package is needed by zola (bug#976052).
> > It will be maintained in the Debian section of Salsa, here:
> > .
> 
> 
> Thanks for your work, Jonas. I was just curious to know if there is a reason
> that you are not maintaining it in the rust-team itself (given that there is 
> a team)?
> BTW, I am not (actively) a part of the team, myself - I might package 
> $something rust in near future and
> hence the question.

The Rust team require all their packages be maintained in one giant git.
I disagree with that approach and am far more comfortable with
maintaining packages as one git per upstream project - as I do with the
other 500+ packages I maintain (which includes packages I maintain in
the Haskell team which has a similar approach but only by default: They
are open to some packages being maintained differently).

They also don't use Debbugs - but hopefully that's a thing of the past:
Recently at least one team member actively responds to bugs I file (but
there are still RC bugs hanging for *years* with zero response from the
team).

Oh, and their odd packaging style also means you may upset them if you
do a source-full NMU, seemingly because they need the source tarball to
fit exactly their custom setup (i.e. *not* a Github release but what is
distributed at crates.io).

If you decide to maintain Rust packages outside of the Rust team as
well, then I would be happy to form another team if that might be
interesting.  Otherwise you might want to consider reusing my fork of
dh-cargo which I adapted to behave more like general debhelper snippets,
less hardcoding of how the Rust team does packaging.

...Or if my whining here didn't scare you, then join the Rust team! :-)

Thanks for asking,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64

2022-06-22 Thread Computer Enthusiastic

Hello,

I've been successfully used an experimental "work in progress" patch
with the kernel version 5.10.113 since last 25 may (see
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/issues/547#note_1438950)
.

I suspended and hibernated the system (Debian GNU/Linux 11.3 with the
aforementioned patch) many times without any issue :
# journalctl -S 2022-05-25 --no-pager | grep -e "PM: suspend
entry\|hibernation: hibernation entry"
May 25 08:39:48 debian kernel: PM: hibernation: hibernation entry
May 26 08:05:44 debian kernel: PM: hibernation: hibernation entry
May 28 12:28:50 debian kernel: PM: suspend entry (deep)
May 28 12:39:52 debian kernel: PM: suspend entry (deep)
May 28 13:34:55 debian kernel: PM: hibernation: hibernation entry
May 28 18:17:35 debian kernel: PM: hibernation: hibernation entry
May 30 08:56:31 debian kernel: PM: hibernation: hibernation entry
Jun 01 22:54:45 debian kernel: PM: hibernation: hibernation entry
Jun 02 17:44:35 debian kernel: PM: suspend entry (deep)
Jun 02 23:49:38 debian kernel: PM: hibernation: hibernation entry
Jun 04 10:54:04 debian kernel: PM: hibernation: hibernation entry
Jun 05 17:34:17 debian kernel: PM: hibernation: hibernation entry
Jun 06 08:18:21 debian kernel: PM: hibernation: hibernation entry
Jun 06 18:11:40 debian kernel: PM: suspend entry (deep)
Jun 06 19:27:39 debian kernel: PM: suspend entry (deep)
Jun 06 23:02:24 debian kernel: PM: hibernation: hibernation entry
Jun 08 08:53:02 debian kernel: PM: hibernation: hibernation entry
Jun 08 08:58:41 debian kernel: PM: suspend entry (deep)
Jun 08 08:59:32 debian kernel: PM: hibernation: hibernation entry
Jun 09 01:11:56 debian kernel: PM: hibernation: hibernation entry
Jun 09 21:08:22 debian kernel: PM: hibernation: hibernation entry
Jun 11 09:00:25 debian kernel: PM: hibernation: hibernation entry
Jun 21 23:35:30 debian kernel: PM: hibernation: hibernation entry

I've successful tested the patch at least one time with upstream
kernels version 5.10.117, 5.16.14 and 5.17.9, too.

Using this patch, the workaround cited in previous messages is not
required anymore with my hardware.
$ inxi -G
Graphics:  Device-1: NVIDIA G96CM [GeForce 9600M GT] driver: nouveau v: kernel
  Display: x11 server: X.Org 1.20.11 driver: loaded:
modesetting unloaded: fbdev,vesa resolution: 1280x800~60Hz
  OpenGL: renderer: NV96 v: 3.3 Mesa 20.3.5
The root cause of the issue is probably the cause, at least another,
of other different issue (see
https://gitlab.freedesktop.org/drm/nouveau/-/issues/156#note_1383820 )

It probably be useful to test the patch with different affected nvidia
graphic cards.

Hope that helps.
From 70271cb0aa30e4523d39c3942e84b16fe18338f5 Mon Sep 17 00:00:00 2001
From: Karol Herbst 
Date: Mon, 16 May 2022 17:40:20 +0200
Subject: [PATCH] nouveau WIP

---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 05076e530e7d..b6343741eda6 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -820,6 +820,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int evict,
 		if (ret == 0) {
 			ret = nouveau_fence_new(chan, false, &fence);
 			if (ret == 0) {
+nouveau_fence_wait(fence, false, false);
 ret = ttm_bo_move_accel_cleanup(bo,
 &fence->base,
 evict, false,
-- 
2.35.3

Bug#991460: fix still not applied?

2022-06-22 Thread cacatoes


Hello!
Is there any chance to see this fix applied anytime soon? (this bug 
prevents from playing a big part of the game).
Upstream also has fixes for various (but less critical) things according 
to commit logs.

I'll try to be around for doing tests if a new package comes.
Have a good day, and thanks!

Bug#1013357: ITP: rust-nom-bibtex -- BibTeX parser using nom

2022-06-22 Thread Nilesh Patra


On 6/22/22 10:40 PM, Jonas Smedegaard wrote:

* Package name: rust-nom-bibtex
   Version : 0.3.0
   Upstream Author : Charles Vandevoorde 
* URL : https://github.com/charlesvdv/nom-bibtex
* License : Expat
   Programming Lang: Rust
   Description : BibTeX parser using nom

  nom-bibtex is a feature complete *BibTeX* parser using nom.
  It can parse the four differents types of entries
  listed in the BibTeX format description:
   * Preambles which allows to call *LaTeX* command inside your *BibTeX*.
   * Strings which defines abbreviations in a key-value format.
   * Comments.
   * Bibliography entries.

This package is needed by zola (bug#976052).
It will be maintained in the Debian section of Salsa, here:
.



Thanks for your work, Jonas. I was just curious to know if there is a reason
that you are not maintaining it in the rust-team itself (given that there is a 
team)?
BTW, I am not (actively) a part of the team, myself - I might package 
$something rust in near future and
hence the question.

--
Best,
Nilesh
 






OpenPGP_signature
Description: OpenPGP digital signature

Bug#925473: Accepted tomcat9 9.0.64-2 (source) into unstable

2022-06-22 Thread Thorsten Glaser

Hi Emmanuel,

> With these changes I think it's now possible to detach the sysvinit script
> into an independent package (tomcat9-sysvinit?) enhancing tomcat9.

*WHY*?

The remaining changes do not change the way it is run under systemd
AT ALL.

Having an extra binary package just for a handfull of scripts is
absolute overkill and ftpmasters from upon that, too.

*gasp*,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#1013357: ITP: rust-nom-bibtex -- BibTeX parser using nom

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-nom-bibtex
  Version : 0.3.0
  Upstream Author : Charles Vandevoorde 
* URL : https://github.com/charlesvdv/nom-bibtex
* License : Expat
  Programming Lang: Rust
  Description : BibTeX parser using nom

 nom-bibtex is a feature complete *BibTeX* parser using nom.
 It can parse the four differents types of entries
 listed in the BibTeX format description:
  * Preambles which allows to call *LaTeX* command inside your *BibTeX*.
  * Strings which defines abbreviations in a key-value format.
  * Comments.
  * Bibliography entries.

This package is needed by zola (bug#976052).
It will be maintained in the Debian section of Salsa, here:
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmKzTRYACgkQLHwxRsGg
ASFS3g/+NPoL99pdIz1lkldvL+/s/EUl1CG4DJxjqnIw9aIITVAhG5bIauZg2VO3
PS9q5LBi5oKbBK4SZRFT3O64J88ftO3sX+4uSrzlgleAb3sF+WXjAmtlsQtuHEGH
wlpTkM+TEhs8qgtchh4LgsbJjgdzJUB+fYFmxRG8yAp2BC1fNA26kLXgkketDt1n
dau5KQ5sjIYoGgewnF4ZbcX3Bphum9wLDNEmf1/jkiwAM9qHtq0jBWwPnckMoLdB
5LtW9WugH6K6+FZR995QuZmRmJ7uiF3YMP9M2GRGzJuVI8HqAECDFvwLZGTkk/Fa
1DthGSCt92LZhiZRo+0u1t4OBf0+fniO8ZARbB2Tyz5p8Y8LoM76c8r9cM1L+716
1lPrL+kbDz3AzlE1AXpuJUaa61d0agziFwmky5D9+YRh1S4n27YbnRJ32XWkNA4m
wxrUu3g1FzRKyVmo606TYYOnEIl8IiMouibD4XEarLXumGShP+mzGpruxIDfuNYt
gRCx+w+SJf5WUXEClp/PEs55qq6faFnJrE/ViL/TXH7XadCuzJ2HGmMKlGbnm1Eg
lCfYHNJlwxK9PAnFYT414bTrnq+FXzIi47IH2Wniuo/2XIp7ctzhZ5BSV2e0C53+
acos8wVT+xhGXcM90WlEwYaBXRgwBLG7qfv1eyOIr4iEHEhYIko=
=842g
-END PGP SIGNATURE-

Bug#1013340: systemd: unclear (but probably very important) NEWS message

2022-06-22 Thread Julian Gilbey

On Wed, Jun 22, 2022 at 01:10:00PM +0200, Michael Biebl wrote:
> > > Thanks Michael!
> > > 
> > > https://salsa.debian.org/jdg/systemd/-/merge_requests/1
> > 
> > Thanks! Can you submit this MR against the correct repository?
> > Atm it's only available in your private copy/fork.
> 
> We use gbp dch to generate debian/changelog. So a MR should preferrably have
> no modifications to debian/changelog but the git commit message should be
> what ends up in the changelog.
> 
> Please also use the
> 
> Closes: #1013340
> 
> annotation.
> 
> See man gbp dch

Oh, sorry I messed up.  Do you like the suggested patch, though?  If
so, could you not just copy the two line message directly into the
main systemd repository?  It's much less work all round.

Best wishes,

   Julian

Bug#1013355: groovy: FTBFS with jansi 2.4.0-1

2022-06-22 Thread Markus Koschany

Forgot to CC the bug report

Am Mittwoch, dem 22.06.2022 um 18:14 +0200 schrieb Emmanuel Bourg:
> Le 2022-06-22 17:54, Markus Koschany a écrit :
> 
> > groovy FTBFS with jansi 2.4.0. I intend to either prepare a patch or
> > upgrade to a newer upstream release in the future.
> 
> Please hold the upload, this is going to blow up Maven and Gradle. I've 
> introduced
> jansi1 to try to work around the issue but I haven't completed the 
> transition yet.

Could you share your plans with jansi1 and why we just can't upgrade to a newer
version of it? I am still working on a major gradle upgrade in the background
and I hope we don't need the current version any longer. jansi 2.4.0 was also
required to upgrade maven-shared-utils. Besides from gradle and groovy no other
r-dep failed to build from source, at least that was the outcome of a ratt
rebuild.






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

Bug#1013355: groovy: FTBFS with jansi 2.4.0-1

2022-06-22 Thread Emmanuel Bourg


Le 2022-06-22 17:54, Markus Koschany a écrit :


groovy FTBFS with jansi 2.4.0. I intend to either prepare a patch or
upgrade to a newer upstream release in the future.


Please hold the upload, this is going to blow up Maven and Gradle. I've 
introduced
jansi1 to try to work around the issue but I haven't completed the 
transition yet.


Emmanuel Bourg

Bug#989720: No need for a fix

2022-06-22 Thread Antoine Beaupré

I filed two merge requests to try to address those issues. First, to
tweak the README files here:

https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/10

It's against debian/yoga, but I don't actually know what I mean or which
branch I'm supposed to be using there.

The patch is:

https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/10.patch

I also filed a MR against the release notes to try to get the word out
there (as we can't really update the NEWS file anymore):

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/133

I guess we can close this ticket when both are merged?

A.

-- 
Power is always dangerous.
Power attracts the worst and corrupts the best.
- Edward Abbey

Bug#1007717: Ballot and call for votes

2022-06-22 Thread Gunnar Wolf

Hello,

Sean Whitton dijo [Mon, Jun 20, 2022 at 05:31:16PM -0700]:
> Hello,
> 
> I hereby call for votes on the following resolution:
> 
> BEGIN BALLOT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4a. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
> 
>   This is because there is currently no other source format which is
>   such that avoid both (i) uploading the whole source, including
>   upstream, for every upload; and (ii) having to maintain
>   debian/patches/ inside the package tree.
> 
>   4c. We believe that there are indeed circumstances in which
>   1.0-with-diff is the best choice for a particular source package,
>   including, but not limited to, git-first packaging workflows.
>   However, we recommend discontinuing use of 1.0-with-diff in other
>   circumstances, to simplify the contents of the archive.
> 
>   This is because ... [second paragraph as in 4a].
> 
>   5. We decline to comment on the recent source package format MBF.
> 
> Option A -- issue items 1-3, 4a and 5
> 
> Option C -- issue items 1-3, 4c and 5
> 
> Option X -- issue only items 1, 2, 3 and 5
> 
> Option N -- none of the above.
> 
> END BALLOT

My vote is:

A > C > X > N

Thanks!


signature.asc
Description: PGP signature

Bug#1010064: salsa: please push the pristine-tar branch

2022-06-22 Thread Hector Oron

Hello Dmitry,

On Sat, 23 Apr 2022 at 15:57, Dmitry Baryshkov  wrote:
>
> Source: device-tree-compiler
> Version: 1.6.1-1
> Severity: normal
>
> Recent push to dtc sources to the repo at salsa includes the
> debian/gbp.conf file. This file contains the "pristine-tar = True"
> config option, however the repo does not contain the pristine-tar
> branch. Thus rebuilding the package from the repo without passing
> additional options to gbp is impossible.
>
> Please push the prisine-tar branch to the salsa repo.

I do not have a pristine-tar branch on my system, but you can grab the
upstream tarball from the Debian mirror. I'll drop pristine-tar from
gbp.conf to allow gbp to create a tarball from the upstream tag.

I hope that works for you.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#1013356: fzf: Bash completions not active by default

2022-06-22 Thread Matthijs Kooijman

Package: fzf
Version: 0.30.0-1+b1
Severity: normal

Hi,

README.Debian says:

  Note, since fzf 0.29.0-1, the bash completion is installed for bash by
  default. Feel free to ignore the following instruction for fzf >=
  0.29.0-1.

It seems this means that the completion is installed as
/usr/share/bash-completion/completions/fzf

However, completions from that directory are not loaded by default, but
are loaded dynamically when the user tries to complete arguments to
their command.

See e.g.:

https://salsa.debian.org/debian/bash-completion/-/blob/master/bash_completion#L2175

In practice, this means that in a new shell, doing "cd **" does not
offer completion. If I then do "fzf ", the completion is loaded,
and after that "cd **" *does* offer fzf completion.

This was tested on Ubuntu 22.04, but with the sid version of fzf
(0.30.0-1+b1) and bash-completion (2:2.11-6), so I'm assuming the same
behavior happens on Debian.


I'm not sure if there is a way for the package to bypass this dynamic
loading and have a snippet be loaded automatically (other than putting
a file in `/etc/bash_completion.d`, but that seems to be for
compatibility only).

What does seem to work is to load it explicitly in `~/.bashrc`:

  source /usr/share/bash-completion/completions/fzf

So maybe that chould be documented?

Gr.

Matthijs

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports'), (50, 'unstable-debug'), (50, 'testing-debug'), (50, 
'stable-security'), (50, 'stable-debug'), (50, 'unstable'), (50, 'testing'), 
(50, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-25-generic (SMP w/8 CPU threads)
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

-- no debconf information

Bug#1013355: groovy: FTBFS with jansi 2.4.0-1

2022-06-22 Thread Markus Koschany

Package: groovy
Version: 2.4.21-1
Severity: serious
X-Debbugs-Cc: a...@debian.org

groovy FTBFS with jansi 2.4.0. I intend to either prepare a patch or
upgrade to a newer upstream release in the future.

Markus

Bug#1013354: ITP: rust-oxilangtag -- language tag normalization and validation

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-oxilangtag
  Version : 0.1.3
  Upstream Author : Pyfisch Tpt 
* URL : https://github.com/oxigraph/oxilangtag
* License : Expat
  Programming Lang: Rust
  Description : language tag normalization and validation

 OxiLangTag is a Rust library
 allowing to validate and normalize language tags
 following RFC 5646 (BCP 47).
 .
 It is a fork of "language-tags" focusing on RDF use cases.
 You might find the "language-tags" crate more convenient.
 .
 Resource Description Framework (RDF)
 is a standard model for data interchange on the Web.

This package is needed by oxigraph (Bug#996504) and atomic-data-rust
(Bug#996464).

It will be maintained in the collaborative Debian section at Salsa:
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmKzOIAACgkQLHwxRsGg
ASEt1g/+OLpKT68AZoQiua4qCfqI/6a7EgU4ma7+riS0KhY9/QhHSw3o6wFAZif/
SiJpgQvZB6sgl01Q3AHyzurxflXT9606OfYPIpuVPncDzwln2gcZVBy2HPya+nGy
3/Q1QcjHJ8ezTRb2YwEVmAov8RgCHoWDhurW0LybqRpWS1oqBghb7tcCxN2jUqem
d9Sgg0lR4V6XWZ0h/7o7c+cHLKqfs73kZYuPNVr1DVLnPnJZkyNfgW3dKXQ7yqx9
ygs5lgm3hHJOS8D8LExYhUkjQfFqfXkOPghpe8vzCuF/efgdbn0aV2yQ89lz6SEw
3HqWtriW8Bi7qjzb0gVC/mTj+LhCpHrSX3P8/ExT8LYn51DqrFTc97FC2aDqAwgX
ITcFNNI6R7RAOMw/3bgA9hoSaRkhLzn3sGZiLdmeKJjRsOFxkYPrQ1NE1PVPaxgs
t6tOBcqBBkWZRNDSWPqb20VRprFpD0NZZNGhIKB2li6SlcYnZxl0NjGILhsYVnDL
JiE0xTyXGOHMBPzpAm8Rcr3whJF6WJhXfU1XXeKlZftimbOCuFo0kj9ir6FzLXMj
Gv8yaerVYtI2v8xTRT1hxKOPJIGwNi6wHYE2nK6BrdSv1NHLQ+Nx+Z+dwN9za6xt
/Eqg4RG2eKHRVWviPFeREMYKJ1EPrDmOWUyeiyMGOQWkjWMjdpU=
=0KhR
-END PGP SIGNATURE-

Bug#1013286: closed by Debian FTP Masters (reply to Simon Josefsson ) (Bug#1013286: fixed in pmccabe 2.8-3)

2022-06-22 Thread Mattia Rizzolo

On Mon, Jun 20, 2022 at 10:09:06PM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Simon Josefsson ).
...
> Maintainer: Paul Bame 
> Changed-By: Simon Josefsson 
> Closes: 1013286
> Changes:
>  pmccabe (2.8-3) unstable; urgency=medium
>  .
>* Update Paul's new email.  Closes: #1013286.

Did you check this with Paul?

From our private (albeit very short) interaction, I had the feeling that
he doesn't plan on taking care of this package moving forward, so I
expected you to take over completely, not just swap the address.

Also where is that @riseup.net coming from?  The emails I had from him
were coming from another domain.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

signature.asc
Description: PGP signature

Bug#1013353: linux-image-5.10.0-15-amd64: virtualbox vm suddenly stops

2022-06-22 Thread IMOTO Takashi

Package: src:linux
Version: 5.10.120-1
Severity: normal
X-Debbugs-Cc: imoto.taka...@gmail.com

Dear Maintainer,


   * What led up to the situation?
After upgrade the kernel from 5.10.0-14 to 5.10.0-15
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Install Oracle Virtual box from Debian fasttrack (6.1.32-dfsg-1~ftoll+2),
activate virtual machine running Windows 10, the virtual machine runs several
minutes, but it suddenly stops, and virtualbox said "A critical error has
occurred".
Reboot the system with version 5.10.0-14 kernel, virtual box runs without any
error.   Reboot the system again with version 5.10.0-15 kernel, virtual box
stops again.


-- Package-specific info:
** Version:
Linux version 5.10.0-15-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.120-1 (2022-06-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-15-amd64 
root=UUID=2fd2ca2e-fa07-4cf1-90eb-e4d7cca176db ro quiet

** Tainted: PO (4097)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded

** Kernel log:
[6.503980] Disabling lock debugging due to kernel taint
[6.515176] kvm: Nested Virtualization enabled
[6.515187] SVM: kvm: Nested Paging enabled
[6.515188] SVM: Virtual VMLOAD VMSAVE supported
[6.515188] SVM: Virtual GIF supported
[6.528059] MCE: In-kernel MCE decoding enabled.
[6.529656] EDAC amd64: F19h_M20h detected (node 0).
[6.529699] EDAC amd64: Node 0: DRAM ECC disabled.
[6.535145] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 243

[6.535445] nvidia :07:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=none
[6.564330] EXT4-fs (nvme0n1p7): mounted filesystem with ordered data mode. 
Opts: user_xattr
[6.579511] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  460.91.03  Fri 
Jul  2 06:04:10 UTC 2021
[6.863059] EDAC amd64: F19h_M20h detected (node 0).
[6.863102] EDAC amd64: Node 0: DRAM ECC disabled.
[6.863562] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  460.91.03  Fri Jul  2 05:43:38 UTC 2021
[7.143131] EDAC amd64: F19h_M20h detected (node 0).
[7.143178] EDAC amd64: Node 0: DRAM ECC disabled.
[7.144865] [drm] [nvidia-drm] [GPU ID 0x0700] Loading driver
[7.144867] [drm] Initialized nvidia-drm 0.0.0 20160202 for :07:00.0 on 
minor 0
[7.219025] EDAC amd64: F19h_M20h detected (node 0).
[7.219079] EDAC amd64: Node 0: DRAM ECC disabled.
[7.310751] EDAC amd64: F19h_M20h detected (node 0).
[7.310794] EDAC amd64: Node 0: DRAM ECC disabled.
[7.346444] loop: module loaded
[7.390997] EDAC amd64: F19h_M20h detected (node 0).
[7.391040] EDAC amd64: Node 0: DRAM ECC disabled.
[7.391438] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[7.462738] EDAC amd64: F19h_M20h detected (node 0).
[7.462778] EDAC amd64: Node 0: DRAM ECC disabled.
[7.535050] EDAC amd64: F19h_M20h detected (node 0).
[7.535094] EDAC amd64: Node 0: DRAM ECC disabled.
[7.602804] EDAC amd64: F19h_M20h detected (node 0).
[7.602853] EDAC amd64: Node 0: DRAM ECC disabled.
[7.698819] EDAC amd64: F19h_M20h detected (node 0).
[7.698855] EDAC amd64: Node 0: DRAM ECC disabled.
[7.774937] EDAC amd64: F19h_M20h detected (node 0).
[7.774978] EDAC amd64: Node 0: DRAM ECC disabled.
[7.834901] EDAC amd64: F19h_M20h detected (node 0).
[7.834940] EDAC amd64: Node 0: DRAM ECC disabled.
[9.739849] audit: type=1400 audit(1655910269.096:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=1319 comm="apparmor_parser"
[9.740087] audit: type=1400 audit(1655910269.096:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=1318 comm="apparmor_parser"
[9.740229] audit: type=1400 audit(1655910269.096:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=1307 
comm="apparmor_parser"
[9.740232] audit: type=1400 audit(1655910269.096:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=1307 comm="apparmor_parser"
[9.740499] audit: type=1400 audit(1655910269.096:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=1311 
comm="apparmor_parser"
[9.740501] audit: type=1400 audit(1655910269.096:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=1311 
comm="apparmor_parser"
[9.740503] audit: type=1400 audit(1655910269.096:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=1311 
comm="apparmor_parser"
[9.740559] audit: type=1400 audit(1655910269.096:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=1313 
comm="apparmor_parser"
[

Bug#968641: marked as pending in jack-audio-connection-kit

2022-06-22 Thread Vagrant Cascadian

Control: found 968641 1:0.126.0-1

On 2022-05-31, Dennis Braun wrote:
> Bug #968641 in jack-audio-connection-kit reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
> https://salsa.debian.org/multimedia-team/jack-audio-connection-kit/-/commit/b77b2f4bdb7ef7569dfa5628e49170b7a4295b6e
>
> 
> Example files are removed with this release (Closes: #968641)
> 

The example files are still shipped in the package as of the 1:0.126.0-1
version:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/jack-audio-connection-kit.html

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1013352: ITP: rust-oxhttp -- very simple implementation of HTTP 1.1