Bug#1069756: marked as pending in readability
Control: tag -1 pending Hello, Bug #1069756 in readability 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/python-team/packages/readability/-/commit/8c36e8dac6b5aa7b09c55840971a988b36f6f77c Add (build-)dependency on python3-lxml-html-clean Closes: #1069756 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069756
Bug#1069756: readability: build time test error: lxml.html.clean module is now a separate project lxml_html_clean
On Wed, Apr 24, 2024 at 11:16:17AM +0200, Étienne Mollier wrote: > As far as I could witness, replacing the python3-lxml build > dependency by python3-lxml-html-clean resolved the issue at > least for the bulid time test. The package is subject to > autodep8 python3 test, which raises that the binary package will > also need it dependencies adjusted; this suggests the setup.py > would probably need patching so this is addressed appropriately > at a larger scale than Debian's. Based on https://github.com/buriy/python-readability/issues/179, it looks as though upstream intends to switch to bleach; I think we can just patch setup.py in Debian in the meantime though. I'll do that. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069608: marked as pending in topplot
Control: tag -1 pending Hello, Bug #1069608 in topplot 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/python-team/packages/topplot/-/commit/3b37e8bd6872c31e18cac5f8fd54039ca9919942 Add python3-all to autopkgtest Depends Closes: #1069608 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069608
Bug#1069360: marked as pending in python-cytoolz
Control: tag -1 pending Hello, Bug #1069360 in python-cytoolz 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/python-team/packages/python-cytoolz/-/commit/3f462fede0bcd4468c9dd27b6b9f23c033fb611b Fix test failure on Python 3.11.9/3.12.3/main Closes: #1069360 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069360
Bug#1069818: marked as pending in toolz
Control: tag -1 pending Hello, Bug #1069818 in toolz 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/python-team/packages/toolz/-/commit/59155505e05c393226e55cad4e0e5de690df3d07 Fix test failure on Python 3.11.9/3.12.3/main Closes: #1069818 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069818
Bug#1066788: gyoto: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 check-lorene returned exit code 2
Control: tag -1 patch On Wed, Mar 13, 2024 at 03:56:54PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[3]: Entering directory '/<>/yorick' > > Makefile:136: warning: overriding recipe for target 'check-dll' > > ../yorick/Makepkg:158: warning: ignoring old recipe for target 'check-dll' > > make[3]: 'check-lorene' is up to date. > > make[3]: Leaving directory '/<>/yorick' > > make[2]: Leaving directory '/<>' > > dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" > > VERBOSE=1 check-lorene returned exit code 2 A more relevant part was: ImportError: /<>/python/gyoto/_std.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE I sent a patch for this upstream as https://github.com/gyoto/Gyoto/pull/17. Here's a patch to fix the Debian package in the meantime. -- Colin Watson (he/him) [cjwat...@debian.org] >From 19e6f4bcdc33cbd7995027bf56ec3b5a7125ea5f Mon Sep 17 00:00:00 2001 From: Colin Watson Date: Wed, 24 Apr 2024 15:25:19 +0100 Subject: [PATCH] Remove undefined operator<< declaration for PolishDoughnut Closes: #1066788 --- debian/changelog | 7 ++ .../patches/remove-polish-doughnut-operator | 25 +++ debian/patches/series | 1 + 3 files changed, 33 insertions(+) create mode 100644 debian/patches/remove-polish-doughnut-operator diff --git a/debian/changelog b/debian/changelog index 8f74908..0188483 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +gyoto (2.0.2-1.2) UNRELEASED; urgency=medium + + * Remove undefined operator<< declaration for PolishDoughnut (closes: +#1066788). + + -- Colin Watson Wed, 24 Apr 2024 14:32:29 +0100 + gyoto (2.0.2-1.1) unstable; urgency=medium * Non-maintainer upload. diff --git a/debian/patches/remove-polish-doughnut-operator b/debian/patches/remove-polish-doughnut-operator new file mode 100644 index 000..ead15f5 --- /dev/null +++ b/debian/patches/remove-polish-doughnut-operator @@ -0,0 +1,25 @@ +Description: Remove undefined operator<< declaration for PolishDoughnut + On current Debian systems this resulted in `undefined symbol: + _ZN5Gyoto7AstrobjlsERSoRKNS0_14PolishDoughnutE` while running tests. +Bug-Debian: https://bugs.debian.org/1066788 +Forwarded: https://github.com/gyoto/Gyoto/pull/17 +Last-Update: 2024-04-24 + +Index: b/include/GyotoPolishDoughnut.h +=== +--- a/include/GyotoPolishDoughnut.h b/include/GyotoPolishDoughnut.h +@@ -262,13 +262,6 @@ + // Outputs + // --- + public: +- +- /// Display +- friend std::ostream& operator<<(std::ostream& , const PolishDoughnut& ) ; +- +- public: +- +- + }; + + #endif diff --git a/debian/patches/series b/debian/patches/series index b9e8f3b..b8e9081 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,3 +1,4 @@ interpreter-path +remove-polish-doughnut-operator # This patch is conditionally applied by debian/rules: # no-fp-ilogb0 -- 2.43.0
Bug#1058888: pyferret FTBSF on several architectures: dh_install: error: missing files, aborting
Control: retitle -1 pyferret FTBFS on several architectures: dh_install: error: missing files, aborting Control: tag -1 patch On Sun, Dec 17, 2023 at 08:24:07PM +0200, Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=pyferret=7.6.5-5 > > ... >dh_install -a > dh_install: warning: Cannot find (any matches for) > "debian/tmp/ext_func/pylibs" (tried in ., debian/tmp) > > dh_install: warning: python3-ferret missing files: debian/tmp/ext_func/pylibs > install -m0755 -d debian/python3-ferret//usr/bin > cp --reflink=auto -a ./debian/pyferret3 debian/python3-ferret//usr/bin/ > install -m0755 -d debian/python3-ferret//usr/lib/python3/dist-packages > cp --reflink=auto -a > ./debian/tmp/lib/python3.11/libpyferret.cpython-311-powerpc64le-linux-gnu.so > ./debian/tmp/lib/python3.12/libpyferret.cpython-312-powerpc64le-linux-gnu.so > ./install/local/lib/python3.11/dist-packages/__pycache__ > ./install/local/lib/python3.11/dist-packages/gcircle-7.65-py3.11.egg-info > ./install/local/lib/python3.11/dist-packages/gcircle.py > ./install/local/lib/python3.11/dist-packages/pipedviewer > ./install/local/lib/python3.11/dist-packages/pipedviewer-7.65-py3.11.egg-info > ./install/local/lib/python3.11/dist-packages/pyferret > ./install/local/lib/python3.11/dist-packages/pyferret-7.65-py3.11.egg-info > debian/python3-ferret//usr/lib/python3/dist-packages/ > install -m0755 -d > debian/python3-ferret//usr/share/bash-completion/completions/ > cp --reflink=auto -a ./debian/bash_completion.d/pyferret3 > debian/python3-ferret//usr/share/bash-completion/completions// > dh_install: error: missing files, aborting > make: *** [debian/rules:8: binary-arch] Error 25 I've proposed https://salsa.debian.org/science-team/pyferret/-/merge_requests/3 to fix this. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1068349: marked as pending in nbconvert
Control: tag -1 pending Hello, Bug #1068349 in nbconvert 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/python-team/packages/nbconvert/-/commit/7131b104d389851c2a15996362f2088319ca46ff (Build-)depend on python3-lxml-html-clean Closes: #1068349 (this message was generated automatically) -- Greetings https://bugs.debian.org/1068349
Bug#1042699: marked as pending in nbconvert
Control: tag -1 pending Hello, Bug #1042699 in nbconvert 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/python-team/packages/nbconvert/-/commit/882b71c61264df472c3d58101532ecec51e9ec68 Updates for sphinx 5.0 support Closes: #1042699 (this message was generated automatically) -- Greetings https://bugs.debian.org/1042699
Bug#1064761: marked as pending in libsdl-perl
Control: tag -1 pending Hello, Bug #1064761 in libsdl-perl 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/perl-team/modules/packages/libsdl-perl/-/commit/d04367a8b11f83b5aead5fadcf2cff4a200dc714 Fix reference-counting in set_event_filter Closes: #1064761 (this message was generated automatically) -- Greetings https://bugs.debian.org/1064761
Bug#1067013: marked as pending in trn4
Control: tag -1 pending Hello, Bug #1067013 in trn4 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/debian/trn4/-/commit/b62b2875b57f3cd7977c498cfd480bf0ec87554f Add many missing #includes and prototypes Closes: #1067013 (this message was generated automatically) -- Greetings https://bugs.debian.org/1067013
Bug#1066692: marked as pending in knews
Control: tag -1 pending Hello, Bug #1066692 in knews 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/debian/knews/-/commit/b76b51bc2091260c801ffc439d40cdf4658d0cfa Add missing #includes Closes: #1066692 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066692
Bug#1066562: marked as pending in kali
Control: tag -1 pending Hello, Bug #1066562 in kali 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/debian/kali/-/commit/21a65c26f243e32011d38ed27f54ba0b9c10a157 Add many missing prototypes and #includes Closes: #1066562 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066562
Bug#1066389: marked as pending in db1-compat
Control: tag -1 pending Hello, Bug #1066389 in db1-compat 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/debian/db1-compat/-/commit/0cd10b5405832373e42bdd95106aa92592e53075 Add missing #include to db_dump185 Closes: #1066389 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066389
Bug#1066078: marked as pending in vigor
Control: tag -1 pending Hello, Bug #1066078 in vigor 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/debian/vigor/-/commit/9d0673487379c41c7b99d50d3e105aa01b9ac33e Add many missing #includes Closes: #1066078 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066078
Bug#1065757: marked as pending in openssh-ssh1
Control: tag -1 pending Hello, Bug #1065757 in openssh-ssh1 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/ssh-team/openssh-ssh1/-/commit/7f75517641e502fdf0afd90bc548b84ffee2dfd8 configure.ac: add missing includes Closes: #1065757 (this message was generated automatically) -- Greetings https://bugs.debian.org/1065757
Bug#1064697: flask-babelex: FTBFS: ImportError: cannot import name '_request_ctx_stack' from 'flask' (/usr/lib/python3/dist-packages/flask/__init__.py)
On Sun, Feb 25, 2024 at 08:37:09PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > == > > ERROR: flask_babelex (unittest.loader._FailedTest.flask_babelex) > > -- > > ImportError: Failed to import test module: flask_babelex > > Traceback (most recent call last): > > File "/usr/lib/python3.12/unittest/loader.py", line 427, in > > _find_test_path > > package = self._get_module_from_name(name) > > > > File "/usr/lib/python3.12/unittest/loader.py", line 337, in > > _get_module_from_name > > __import__(name) > > File > > "/<>/.pybuild/cpython3_3.12_flask-babelex/build/flask_babelex/__init__.py", > > line 20, in > > from flask import _request_ctx_stack > > ImportError: cannot import name '_request_ctx_stack' from 'flask' > > (/usr/lib/python3/dist-packages/flask/__init__.py) https://github.com/mrjoes/flask-babelex is archived and shows a deprecation warning: "All Flask-BabelEx features were merged into Flask-Babel and Flask-BabelEx package should no longer be used in your projects. Please migrate." Apparently this was originally packaged as a dependency of pgadmin4, but pgadmin4 no longer uses it: https://github.com/pgadmin-org/pgadmin4/commit/d644b4f94ec71af78a46434121bce0fcd626a2dc Should we just remove this package from Debian? I'm CCing everyone who's uploaded it in the past just in case, but I suspect this is an easy decision. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1042679: quark-sphinx-theme: FTBFS with Sphinx 7.1, docutils 0.20: AssertionError: no elements
etUpClass
run_sphinx(cls.source_dir, cls.build_dir, cls.builder, cls.config,
File
"/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/util.py",
line 65, in run_sphinx
raise Exception('%s returned non-zero exit status %s\n'
Exception: ['-b', 'qthelp', '-N',
'/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/testdoc-html_rewrite',
'/tmp/tmp-sphinx-build-test-g9rskfhy'] returned non-zero exit status 2
--- Output:
Running Sphinx v7.2.6
Configuration error:
HTML 4 is no longer supported by Sphinx. ("html4_writer=True" detected in
configuration options)
==
ERROR: setUpClass (test.test_theme.TestThemeEntrypoint)
--
Traceback (most recent call last):
File
"/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/util.py",
line 84, in setUpClass
run_sphinx(cls.source_dir, cls.build_dir, cls.builder, cls.config,
File
"/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/util.py",
line 65, in run_sphinx
raise Exception('%s returned non-zero exit status %s\n'
Exception: ['-b', 'html', '-N',
'/<>/.pybuild/cpython3_3.11_quark-sphinx-theme/build/test/testdoc-theme-entrypoint',
'/tmp/tmp-sphinx-build-test-huhej5mg'] returned non-zero exit status 2
--- Output:
Running Sphinx v7.2.6
Theme error:
no theme named 'quark' found (missing theme.conf?)
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1061754: python-json-log-formatter ftbfs with Python 3.12 as default
On Tue, Mar 05, 2024 at 06:15:32PM +, Colin Watson wrote: > While it looks like this was fixed upstream in > https://github.com/marselester/json-log-formatter/commit/74f04ee4f6aa8e461fcb2d688459888b7279fc73 > and I guess we could cherry-pick that, I also can't reproduce this > failure in current unstable with Python 3.12. Can you still reproduce > this? I guess it doesn't hurt to apply this anyway, so I'm just going ahead. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1008502: vdirsyncer: Unknown error occured: unmatched ')'
Control: tag -1 unreproducible On Mon, Mar 28, 2022 at 01:44:58AM +0200, Christof Schulze wrote: > Running vdirsyncer sync causes the above error message about unmatched > ')'. This renders 0.4.4 - the version in stable - unusable. The root cause is > that > python-click-threading 0.4.4, which vdirsyncer is depending on, > introduced an incompatibility with python-click. > More info on the problem can be found in [2] and [3]. > > The version in testing (0.18.0-6) is working fine as it depends on a > python-click-version that does not have the problem. So installing the > version from testing including its dependencies works. > > Would you please upgrade vdirsyncer in stable to the current version in > testing to make the program work again for everyone on stable? I know this was a long time ago, but I've been going through some Python team bugs to see if I can do anything with them, and came across this; it interested me because I've been using vdirsyncer since 2017, and that definitely involved a period when I was using it on bullseye and I don't think I ever ran across this bug. I just tried setting up a clean bullseye container, installing vdirsyncer, copying over my configuration, and running "vdirsyncer discover contacts && vdirsyncer sync". Everything worked perfectly. > [1] https://github.com/pimutils/vdirsyncer/pull/891 > [2] https://github.com/click-contrib/click-threading/pull/5 > [3] https://github.com/pimutils/vdirsyncer/issues/887 If we were to update anything here in bullseye, it would make more sense to just cherry-pick the fix to click-threading; the only thing a new vdirsyncer would add would be a tighter dependency on click-threading, but for Debian stable release purposes we might as well just issue the click-threading update and have people upgrade to it. However, [2] and [3] both make it clear that the problem with the combination of click and click-threading was introduced in click 8.0.0 and does not exist with click 7.1.2. bullseye has click 7.1.2, and indeed the package versions in your bug show that as well: > Versions of packages vdirsyncer depends on: > ii init-system-helpers1.60 > ii python33.9.2-3 > ii python3-atomicwrites 1.4.0-2 > ii python3-click 7.1.2-1 > ii python3-click-log 0.2.1-2 > ii python3-click-threading0.4.4-2 > ii python3-requests 2.25.1+dfsg-2 > ii python3-requests-toolbelt 0.9.1-1 ... so I am quite suspicious that there may be some relevant information that's not in the bug report. You didn't include a traceback, which might have made it clearer; but is it possible that you have a locally installed version of click >= 8.0.0 from PyPI, perhaps due to running "pip install" outside a virtual environment? That would explain this happening to you. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1042241: marked as pending in wcwidth
Control: tag -1 pending Hello, Bug #1042241 in wcwidth 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/python-team/packages/wcwidth/-/commit/224ad07e9c5a6068957c5588e4fa1677fafb5b36 Update upstream source from tag 'upstream/0.2.13+dfsg1' Update to upstream version '0.2.13+dfsg1' with Debian dir 7763002028eb5176ac6dd29c7886dd3af7766443 Closes: #1042241 (this message was generated automatically) -- Greetings https://bugs.debian.org/1042241
Bug#1061754: python-json-log-formatter ftbfs with Python 3.12 as default
Control: tag -1 moreinfo
On Mon, Jan 29, 2024 at 01:10:20PM +0100, Matthias Klose wrote:
> With python3-defaults from experimental, the package fails to build:
>
> [...]
> = test session starts
> ==
> platform linux -- Python 3.12.1, pytest-7.4.4, pluggy-1.4.0
> cachedir: .tox/py312/.pytest_cache
> rootdir: /<>
> collected 29 items
>
> tests.py ...FF
>
> === FAILURES
> ===
> _
> JSONFormatterTest.test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided
> _
>
> self = testMethod=test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided>
>
> def
> test_message_and_time_and_extra_are_in_json_record_when_extra_is_provided(self):
> logger.info('Sign up', extra={'fizz': 'bazz'})
> json_record = json.loads(log_buffer.getvalue())
> expected_fields = set([
> 'message',
> 'time',
> 'fizz',
> ])
> > self.assertEqual(set(json_record), expected_fields)
> E AssertionError: Items in the first set but not the second:
> E 'taskName'
While it looks like this was fixed upstream in
https://github.com/marselester/json-log-formatter/commit/74f04ee4f6aa8e461fcb2d688459888b7279fc73
and I guess we could cherry-pick that, I also can't reproduce this
failure in current unstable with Python 3.12. Can you still reproduce
this?
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#999908: marked as pending in celery-haystack-ng
Control: tag -1 pending Hello, Bug #08 in celery-haystack-ng 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/python-team/packages/celery-haystack-ng/-/commit/5b561e1cbe481c67b3241e19898a528d34a236b6 Breaks/Replaces: python3-django-celery-haystack Closes: #08 (this message was generated automatically) -- Greetings https://bugs.debian.org/08
Bug#1064852: incus: missing depends on iproute2
On Tue, Feb 27, 2024 at 01:33:08AM +, Mathias Gibbens wrote: > iproute2 is Priority: important, which according to Policy §2.5 means > that it is generally expected to be present on a Debian system. Do you > have a specific use case where for some reason you don't have iproute2 > installed? Would you mind reassessing your view in light of Policy 3.5 (https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies)? I think it's quite straightforward and unambiguous. Section 2.5 has traditionally not been what controls decisions about when dependencies ought to be specified, and this particular case is one that I'm surprised to find being controversial. The fine distinction between "Priority: required" and "Essential: yes" has sometimes confused people in the past and has needed some discussion, but it's always been my experience that if one package needs another "Priority: important" package for proper functioning then it's been quite uncontroversial that the first package must declare a dependency. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063345: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#1063345: fixed in python3.12 3.12.2-2)
Control: reopen 1063345 > python3.12 (3.12.2-2) unstable; urgency=medium > . > [ Colin Watson ] >* Don't rely on module state in teedataobject_clear (from Brandt Bucher in > https://github.com/python/cpython/issues/115874). Closes: #1063345. Unfortunately this commit just added my changelog entry but not the actual patch, and so the bug is still present: https://salsa.debian.org/cpython-team/python3/-/commit/c2e29e5e5d9daf98d28a682349341408ac3fadca -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1058317: Bug#1063345: python3.12: Segmentation fault in get_module_state_by_cls at ../Modules/itertoolsmodule.c
Control: unmerge 1058317 1063345 Control: reassign 1063345 python3.12 Control: affects 1063345 celery Control: forwarded 1063345 https://github.com/python/cpython/issues/115874 Control: block 1058317 by 1063345 Control: tag 1063345 patch On Tue, Feb 06, 2024 at 02:26:55PM +0100, Jérémy Lal wrote: > python3-celery test suite crashes with python 3.12 during gc before exit (see > attached stack trace). > > It can be reproduced quickly with > > apt build-dep celery > dget -xu https://deb.debian.org/debian/pool/main/c/celery/celery_5.3.4-2.dsc > cd celery-5.3.4 > python3.12 -m pytest -v > t/unit/tasks/test_canvas.py::test_group::test_apply_contains_chords_containing_empty_chain > t/unit/tasks/test_canvas.py::test_group::test_apply > > > Results (0.56s): >1 passed >1 xfailed > Erreur de segmentation (core dumped) There are two separate issues in the current celery FTBFS, so I'm unmerging these two bugs again because they ought to be tracked separately - and it turns out that this one really is a bug in Python 3.12. I happened to notice that something very similar to #1063345 had recently been reported to Python upstream as https://github.com/python/cpython/issues/115874, with a much more manageably-sized reproducer, and there's a patch for it in https://github.com/python/cpython/issues/115874#issuecomment-1965775536. I've built the Debian python3.12 package with this patch, and I've confirmed that Celery 5.3.6 passes its tests with this patch when it previously failed. Celery is unlucky to run into this, but it doesn't seem to be anything particularly intrinsic to Celery - it's an artifact of the particular set of pytest plugins it happens to use, which manage to tickle this particular bug. I think it would be worth applying this patch to Debian's python3.12 package, as it could easily bite in other places and this was a real time-sink for me before I managed to find the upstream bug that somebody else had fortunately filed. (It would also be nice to get Celery back into Debian testing and Ubuntu noble if at all possible, the latter of which has a fairly close deadline.) Separately, #1058317 still has the test failure in test_AsyncResult.test_del. That was fixed in Celery 5.3.5, and 5.3.6 is currently on salsa, but there's only limited point in uploading it until the Python bug is fixed. Suggested Python patch follows, though you might want to check whether it's progressed any further upstream in case there've been any additional tweaks: diff --git a/debian/changelog b/debian/changelog index 0e16636..b57f7dc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +python3.12 (3.12.2-1.1) UNRELEASED; urgency=medium + + * Don't rely on module state in teedataobject_clear (from Brandt Bucher in +https://github.com/python/cpython/issues/115874; closes: #1063345). + + -- Colin Watson Tue, 27 Feb 2024 10:15:37 + + python3.12 (3.12.2-1) unstable; urgency=medium * Python 3.12.2 release. diff --git a/debian/patches/itertools-clear-crash.diff b/debian/patches/itertools-clear-crash.diff new file mode 100644 index 000..cdaeebb --- /dev/null +++ b/debian/patches/itertools-clear-crash.diff @@ -0,0 +1,19 @@ +Description: Don't rely on module state in teedataobject_clear +Origin: other, https://github.com/python/cpython/issues/115874#issuecomment-1965775536 +Bug: https://github.com/python/cpython/issues/115874 +Bug-Debian: https://bugs.debian.org/1063345 + +Index: b/Modules/itertoolsmodule.c +=== +--- a/Modules/itertoolsmodule.c b/Modules/itertoolsmodule.c +@@ -832,8 +832,7 @@ + Py_CLEAR(tdo->values[i]); + tmp = tdo->nextlink; + tdo->nextlink = NULL; +-itertools_state *state = get_module_state_by_cls(Py_TYPE(tdo)); +-teedataobject_safe_decref(tmp, state->teedataobject_type); ++teedataobject_safe_decref(tmp, Py_TYPE(tdo)); + return 0; + } + diff --git a/debian/patches/series b/debian/patches/series index 63c72c2..0a85028 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -31,3 +31,4 @@ fix-py_compile.diff ntpath-import.diff python3.12-updates.diff issue108447.diff +itertools-clear-crash.diff Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1064699: marked as pending in storm
Control: tag -1 pending Hello, Bug #1064699 in storm 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/python-team/packages/storm/-/commit/dd61f733d074d13a267f6a0176e5ce9f54c3c202 Build-depend on python3-six Closes: #1064699 (this message was generated automatically) -- Greetings https://bugs.debian.org/1064699
Bug#1056232: celery's autopkg tests fail with Python 3.12
Control: reassign -1 python3-kombu Control: forwarded -1 https://github.com/celery/kombu/issues/1804 Control: affects -1 src:celery Control: fixed -1 kombu/5.3.4-1 Control: close -1 On Sun, Nov 19, 2023 at 12:08:09PM +0100, Matthias Klose wrote: > celery's autopkg tests fail with Python 3.12. All failing like: [...] > 544s self = > 544s instance = > 544s value = 0x73c86780> > 544s > 544s def __set__(self, instance, value): > 544s if instance is None: > 544s return self > 544s > 544s > with self.lock: > 544s E AttributeError: 'cached_property' object has no attribute > 'lock' > 544s > 544s /usr/lib/python3/dist-packages/kombu/utils/objects.py:37: > AttributeError This was https://github.com/celery/kombu/issues/1804, fixed in kombu 5.3.3, which has been in Debian for a few months now. (#1058317 is still a problem, but is a separate bug.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file
On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote: > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca : > > Dumping the encoded keymaps for pc105... > > WARNING: Can not find "caps_switch" in "group". > > WARNING: Can not find "caps_toggle" in "group". > > gzip -9n >/Keyboard/pc105.ekbd > > >/<>/Keyboard/pc105.ekbd.gz > > /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file > > make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2 > > make[1]: Leaving directory '/<>' > > make: *** [debian/rules:204: udeb-install] Error 2 > > > >Version 1.223 builds fine in unstable instead. Perhaps this is related > >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd? > > What makes you think, that this has happened? > > There is a merge request that includes the removal of said package, > but it has not yet been merged. It's not in git, but you appear to have built 1.224 from an unclean source tree that had that patch applied. My inclination is to upload 1.225 without that patch for now, as we need to rebuild for the new xkb-data to sort out uninstallability in unstable, and then get the kFreeBSD-removal patch sorted out after that. Objections? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1063216: parted: NMU diff for 64-bit time_t transition
On Mon, Feb 05, 2024 at 03:08:55PM -0300, Lucas Kanashiro wrote: > diff -Nru parted-3.6/debian/libparted-fs-resize0t64.maintscript > parted-3.6/debian/libparted-fs-resize0t64.maintscript > --- parted-3.6/debian/libparted-fs-resize0t64.maintscript 1969-12-31 > 21:00:00.0 -0300 > +++ parted-3.6/debian/libparted-fs-resize0t64.maintscript 2023-06-26 > 19:34:57.0 -0300 > @@ -0,0 +1 @@ > +dir_to_symlink /usr/share/doc/libparted-fs-resize0 libparted2 3.5-2~ Does this need to be /usr/share/doc/libparted-fs-resize0t64 instead? (Alternatively, maybe this .maintscript file can just be dropped, since the new directory name won't need to be switched to a symlink.) > diff -Nru parted-3.6/debian/rules parted-3.6/debian/rules > --- parted-3.6/debian/rules 2023-06-26 19:34:57.0 -0300 > +++ parted-3.6/debian/rules 2024-02-05 14:58:17.0 -0300 > @@ -69,18 +69,18 @@ > dh_install -pparted-udeb -plibparted2-udeb -plibparted-fs-resize0-udeb > --sourcedir=debian/tmp-udeb > > override_dh_installdocs-arch: > - dh_installdocs --link-doc=libparted2 > + dh_installdocs --link-doc=libparted2t64 > > override_dh_installdocs-indep: > - dh_installdocs -pparted-doc --doc-main-package=libparted2 > + dh_installdocs -pparted-doc --doc-main-package=libparted2t64 > dh_installdocs --remaining-packages > > override_dh_strip: > - dh_strip -plibparted2 --ddeb-migration='libparted2-dbg (<< 3.2-11~)' > - dh_strip -plibparted-fs-resize0 \ > + dh_strip -plibparted2t64 --ddeb-migration='libparted2-dbg (<< 3.2-11~)' > + dh_strip -plibparted-fs-resize0t64 \ > --ddeb-migration='libparted-fs-resize0-dbg (<< 3.2-11~)' Is the --ddeb-migration option here still needed? Presumably it won't have any common files with the old -dbg package any more (the file names in /usr/lib/debug/ change all the time, and the only other common file was /usr/share/doc/libparted-fs-resize0-dbgsym). In fact, since 3.2-11 was before oldoldstable, I'm just going to remove this override_dh_strip rule entirely, as it isn't needed any more: https://salsa.debian.org/parted-team/parted/-/commit/2ede9a43a0cb5e5abb52cd3c519769ad9d8d489d Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1062291: libfido2: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 12:26:58AM +, Steve Langasek wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > libfido2 as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). [...] > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. This one surprised me, because there doesn't seem to be anything about either times or offsets in libfido2's ABI as far as I can see. https://people.canonical.com/~vorlon/armhf-time_t/compat_reports/libfido2-dev/lfs_to_timet/compat_report.html reports 100% binary compatibility. The source compatibility tab there does indeed show a time_t change, but I didn't think that was cause for a SONAME change as long as it doesn't affect libfido2's own exported symbols - am I missing something here? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059802: troffcvt: Broken with groff 1.23.0: .de1 etc. unimplemented
Package: troffcvt Version: 1.04+repack1-1 Severity: grave Justification: renders package unusable groff 1.23.0 makes more use of the .de1 request (and probably others) than previous versions did. This causes troffcvt to be unable to even format its own documentation, with this error: /usr/share/groff/current/tmac/devtag.tmac (line 74): you cannot alias to non-existing name That's probably just the first error; some work is needed to get this rendering properly again. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-10-generic (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages troffcvt depends on: ii groff 1.23.0-3 ii libc6 2.37-13 ii perl 5.36.0-10 troffcvt recommends no packages. troffcvt suggests no packages. -- no debconf information -- Colin Watson [cjwat...@debian.org]
Bug#1058287: marked as pending in openssh-ssh1
Control: tag -1 pending Hello, Bug #1058287 in openssh-ssh1 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/ssh-team/openssh-ssh1/-/commit/392f90d23f762299e03ef3543aa23b404ab5576e Fix zlib version check for 1.3 and future versions Closes: #1058287 (this message was generated automatically) -- Greetings https://bugs.debian.org/1058287
Bug#1054938: marked as pending in python-tblib
Control: tag -1 pending Hello, Bug #1054938 in python-tblib 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/python-team/packages/python-tblib/-/commit/bd7dce68ae4614a8ca3bc55f2bd691785672ceaa Run tests with PYTHONNODEBUGRANGES=yes Closes: #1054938 (this message was generated automatically) -- Greetings https://bugs.debian.org/1054938
Bug#1041731: marked as pending in groff
Control: tag -1 pending Hello, Bug #1041731 in groff 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/debian/groff/-/commit/d5394c68d70e6c5199b01d2522e094c8fd52e64e Map -, ', and ` to \-, \[aq], and \[ga] again for UTF-8 manual pages Closes: #1041731 (this message was generated automatically) -- Greetings https://bugs.debian.org/1041731
Bug#1041731: Hyphens in man pages
My plan, as indicated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041731#62, had been to leave things much as they are for most of the period while trixie is in development, and then put the ".char - \-" etc. workarounds back in place for nroff output for trixie's release; this would have meant a higher chance of more manual page authoring tools being updated to handle the groff input language more strictly (although this isn't always easy, as Russ has indicated, since sometimes the input languages of those tools are less rich than groff). However, after wading through an enormous amount of inordinately verbose stuff in my inbox about this, I'm afraid I've now lost patience with the whole thing and am definitely not willing to put up with it for another year or more, so I'm putting the workaround back in place now. Sorry to anyone who will end up dissatisfied by non-terminal printed output as a result. https://salsa.debian.org/debian/groff/-/commit/d5394c68d7 It is still true that being strict about the use of the "\-", "\[aq]", "\[ga]", "\[ha]", and "\[ti]" escape sequences (as opposed to "-", "'", "`", "^", and "~" respectively) will produce better printed output. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1
On Mon, Aug 07, 2023 at 04:45:30PM +0200, Thomas Goirand wrote:
> Ok, so if there's only 5 patches, not 6, then I should be able to manage
> (even though it's not the best convenient way). Thanks for your patches.
I think I possibly understand what you meant now. Is this more
convenient?
--
Colin Watson (he/him) [cjwat...@debian.org]
>From 45a2a2245f6c73dc6898f63c8d30ffd138920066 Mon Sep 17 00:00:00 2001
From: Colin Watson
Date: Fri, 4 Aug 2023 18:22:31 +0100
Subject: [PATCH v2 0/5] docs: Fix manpage-check warnings with groff 1.23.0
https://bugs.debian.org/1042358 reported a manpage-check failure with
groff 1.23.0 in Debian testing/unstable. Fixing the immediate mistake
here exposed a few other issues in how the tables in ovs-fields(7) are
rendered.
Colin Watson (5):
docs: Wrap more table entries in text blocks
docs: Shorten overly-wide table heading
docs: Tweak width of name column in field property tables
docs: Fix rendering of VLAN Comparison Chart
docs: Run tbl preprocessor in manpage-check rule
Makefile.am | 2 +-
build-aux/extract-ofp-fields | 20 ++--
lib/meta-flow.xml| 25 +
3 files changed, 28 insertions(+), 19 deletions(-)
--
2.39.2
>From 97fb673b2b09747beabe8625ac86dbfc5aa0c023 Mon Sep 17 00:00:00 2001
From: Colin Watson
Date: Fri, 4 Aug 2023 11:19:06 +0100
Subject: [PATCH v2 1/5] docs: Wrap more table entries in text blocks
This fixes a number of "table wider than line length minus indentation"
warnings from tbl. The table cells are too narrow for centered text to
look good, so left-align the contents of the text blocks.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index efec59c25..2f566d2b9 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -189,12 +189,14 @@ def field_to_xml(field_node, f, body, summary):
ovs_version = [int(x) for x in ovs_version_s.split(".")]
if min_ovs_version is None or ovs_version < min_ovs_version:
min_ovs_version = ovs_version
-summary += ["\\fB%s\\fR" % f["name"]]
+summary += ["T{\n.ad l\n\\fB%s\\fR" % f["name"]]
if f["extra_name"]:
summary += [" aka \\fB%s\\fR" % f["extra_name"]]
-summary += [";%d" % f["n_bytes"]]
+summary += ["\nT}"]
+summary += [";T{\n.ad l\n%d" % f["n_bytes"]]
if f["n_bits"] != 8 * f["n_bytes"]:
summary += [" (low %d bits)" % f["n_bits"]]
+summary += ["\nT}"]
summary += [";%s;" % {"MFM_NONE": "no", "MFM_FULLY": "yes"}[f["mask"]]]
summary += ["%s;" % {True: "yes", False: "no"}[f["writable"]]]
summary += ["%s;" % f["prereqs"]]
@@ -203,7 +205,7 @@ def field_to_xml(field_node, f, body, summary):
support += ["OF %s+" % VERSION_REVERSE[min_of_version]]
if min_ovs_version is not None:
support += ["OVS %s+" % ".".join([str(x) for x in min_ovs_version])]
-summary += " and ".join(support)
+summary += ["T{\n.ad l\n", " and ".join(support), "\nT}"]
summary += ["\n"]
# Full description.
@@ -230,8 +232,10 @@ l lx.
body += ["Width:;"]
if f["n_bits"] != 8 * f["n_bytes"]:
body += [
+"T{\n",
"%d bits (only the least-significant %d bits "
-"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"])
+"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"]),
+"\nT}",
]
elif f["n_bits"] <= 128:
body += ["%d bits" % f["n_bits"]]
--
2.39.2
>From 36207097b0c3de75d562b93e666c54f954da763c Mon Sep 17 00:00:00 2001
From: Colin Watson
Date: Fri, 4 Aug 2023 18:01:55 +0100
Subject: [PATCH v2 2/5] docs: Shorten overly-wide table heading
Using "NXM/OXM Support" makes these tables a little too wide to fit well
when rendered in 80 columns, causing warnings from groff. There's
already some abbreviation going on here (e.g. "RW?"), so "NXM/OXM?"
seems acceptable.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-aux/extract-ofp-fiel
Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1
On Mon, Aug 07, 2023 at 10:54:52AM +0200, Thomas Goirand wrote: > I very much appreciate that you've sent patches for this bug, thanks for > this. However, it is difficult to apply your patches because they are sent > inline, and therefore hard to save on disk. Also, I would have done the work > by hand to avoid annoying you, but your "Message part 2" doesn't contain > the patch at all, only a diffstat. > > Could you send me the 6 patches as separate files, so I could more easily > add them to debian/patches? Or at least send the first patch that's > completely missing... I don't mind sending you patches in a different format if it's helpful, but I'm confused; I _did_ send them as separate files, MIME-encapsulated. How else would I have sent them as separate files? The "PATCH v2 0/5" message is a cover letter for the patch set. It's not supposed to contain a patch itself. Cheers, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1
On Fri, Aug 04, 2023 at 12:54:31PM +0100, Colin Watson wrote:
> On Wed, Jul 26, 2023 at 10:21:34PM +0200, Lucas Nussbaum wrote:
> > > an.tmac:lib/ovs-fields.7:762: warning: tbl preprocessor failed, or it or
> > > soelim was not run; table(s) likely not rendered (TE macro called with TW
> > > register undefined)
>
> I've sent a patch set for this upstream. It's currently waiting for
> mailing list moderation, but I've attached the messages here.
Frode Nordahl pointed out that this patch set introduces warnings with
earlier versions of groff. Here's an updated version that doesn't.
--
Colin Watson (he/him) [cjwat...@ubuntu.com]
--- Begin Message ---
https://bugs.debian.org/1042358 reported a manpage-check failure with
groff 1.23.0 in Debian testing/unstable. Fixing the immediate mistake
here exposed a few other issues in how the tables in ovs-fields(7) are
rendered.
Colin Watson (5):
docs: Wrap more table entries in text blocks
docs: Shorten overly-wide table heading
docs: Tweak width of name column in field property tables
docs: Fix rendering of VLAN Comparison Chart
docs: Run tbl preprocessor in manpage-check rule
Makefile.am | 2 +-
build-aux/extract-ofp-fields | 20 ++--
lib/meta-flow.xml| 25 +
3 files changed, 28 insertions(+), 19 deletions(-)
--
2.39.2
--- End Message ---
--- Begin Message ---
This fixes a number of "table wider than line length minus indentation"
warnings from tbl. The table cells are too narrow for centered text to
look good, so left-align the contents of the text blocks.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index efec59c25..2f566d2b9 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -189,12 +189,14 @@ def field_to_xml(field_node, f, body, summary):
ovs_version = [int(x) for x in ovs_version_s.split(".")]
if min_ovs_version is None or ovs_version < min_ovs_version:
min_ovs_version = ovs_version
-summary += ["\\fB%s\\fR" % f["name"]]
+summary += ["T{\n.ad l\n\\fB%s\\fR" % f["name"]]
if f["extra_name"]:
summary += [" aka \\fB%s\\fR" % f["extra_name"]]
-summary += [";%d" % f["n_bytes"]]
+summary += ["\nT}"]
+summary += [";T{\n.ad l\n%d" % f["n_bytes"]]
if f["n_bits"] != 8 * f["n_bytes"]:
summary += [" (low %d bits)" % f["n_bits"]]
+summary += ["\nT}"]
summary += [";%s;" % {"MFM_NONE": "no", "MFM_FULLY": "yes"}[f["mask"]]]
summary += ["%s;" % {True: "yes", False: "no"}[f["writable"]]]
summary += ["%s;" % f["prereqs"]]
@@ -203,7 +205,7 @@ def field_to_xml(field_node, f, body, summary):
support += ["OF %s+" % VERSION_REVERSE[min_of_version]]
if min_ovs_version is not None:
support += ["OVS %s+" % ".".join([str(x) for x in min_ovs_version])]
-summary += " and ".join(support)
+summary += ["T{\n.ad l\n", " and ".join(support), "\nT}"]
summary += ["\n"]
# Full description.
@@ -230,8 +232,10 @@ l lx.
body += ["Width:;"]
if f["n_bits"] != 8 * f["n_bytes"]:
body += [
+"T{\n",
"%d bits (only the least-significant %d bits "
-"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"])
+"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"]),
+"\nT}",
]
elif f["n_bits"] <= 128:
body += ["%d bits" % f["n_bits"]]
--
2.39.2
--- End Message ---
--- Begin Message ---
Using "NXM/OXM Support" makes these tables a little too wide to fit well
when rendered in 80 columns, causing warnings from groff. There's
already some abbreviation going on here (e.g. "RW?"), so "NXM/OXM?"
seems acceptable.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index 2f566d2b9..808c6527d 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -323,7 +323,7 @@ def gr
Bug#1042358: openvswitch: FTBFS: make[3]: *** [Makefile:6743: manpage-check] Error 1
Control: tag -1 patch
On Wed, Jul 26, 2023 at 10:21:34PM +0200, Lucas Nussbaum wrote:
> > an.tmac:lib/ovs-fields.7:762: warning: tbl preprocessor failed, or it or
> > soelim was not run; table(s) likely not rendered (TE macro called with TW
> > register undefined)
I've sent a patch set for this upstream. It's currently waiting for
mailing list moderation, but I've attached the messages here.
--
Colin Watson (he/him) [cjwat...@debian.org]
--- Begin Message ---
https://bugs.debian.org/1042358 reported a manpage-check failure with
groff 1.23.0 in Debian testing/unstable. Fixing the immediate mistake
here exposed a few other issues in how the tables in ovs-fields(7) are
rendered.
Colin Watson (3):
docs: Wrap more table entries in text blocks
docs: Fix rendering of VLAN Comparison Chart
docs: Run tbl preprocessor in manpage-check rule
Makefile.am | 2 +-
build-aux/extract-ofp-fields | 14 +-
lib/meta-flow.xml| 25 +
3 files changed, 23 insertions(+), 18 deletions(-)
--
2.40.1
--- End Message ---
--- Begin Message ---
This fixes a number of "table wider than line length minus indentation"
warnings from tbl.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
build-aux/extract-ofp-fields | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index efec59c25..7b5863829 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -189,12 +189,14 @@ def field_to_xml(field_node, f, body, summary):
ovs_version = [int(x) for x in ovs_version_s.split(".")]
if min_ovs_version is None or ovs_version < min_ovs_version:
min_ovs_version = ovs_version
-summary += ["\\fB%s\\fR" % f["name"]]
+summary += ["T{\n\\fB%s\\fR" % f["name"]]
if f["extra_name"]:
summary += [" aka \\fB%s\\fR" % f["extra_name"]]
-summary += [";%d" % f["n_bytes"]]
+summary += ["\nT}"]
+summary += [";T{\n%d" % f["n_bytes"]]
if f["n_bits"] != 8 * f["n_bytes"]:
summary += [" (low %d bits)" % f["n_bits"]]
+summary += ["\nT}"]
summary += [";%s;" % {"MFM_NONE": "no", "MFM_FULLY": "yes"}[f["mask"]]]
summary += ["%s;" % {True: "yes", False: "no"}[f["writable"]]]
summary += ["%s;" % f["prereqs"]]
@@ -203,7 +205,7 @@ def field_to_xml(field_node, f, body, summary):
support += ["OF %s+" % VERSION_REVERSE[min_of_version]]
if min_ovs_version is not None:
support += ["OVS %s+" % ".".join([str(x) for x in min_ovs_version])]
-summary += " and ".join(support)
+summary += ["T{\n", " and ".join(support), "\nT}"]
summary += ["\n"]
# Full description.
@@ -230,8 +232,10 @@ l lx.
body += ["Width:;"]
if f["n_bits"] != 8 * f["n_bytes"]:
body += [
+"T{\n",
"%d bits (only the least-significant %d bits "
-"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"])
+"may be nonzero)" % (f["n_bytes"] * 8, f["n_bits"]),
+"\nT}",
]
elif f["n_bits"] <= 128:
body += ["%d bits" % f["n_bits"]]
@@ -319,7 +323,7 @@ def group_xml_to_nroff(group_node, fields):
".TS\n",
"tab(;);\n",
"l l l l l l l.\n",
-"Name;Bytes;Mask;RW?;Prereqs;NXM/OXM Support\n",
+"Name;Bytes;Mask;RW?;Prereqs;T{\nNXM/OXM Support\nT}\n",
"\_;\_;\_;\_;\_;\_\n",
]
content += summary
--
2.40.1
--- End Message ---
--- Begin Message ---
tbl defaults to expecting table entries to be separated by tab
characters. However, commit 5a0e4aec1af5cf7741c490bce704577e51e536b9
converted these to spaces and inadvertently broke the rendering. Use
semicolons as separators instead; these are less prone to being broken
by tree-wide changes, and match the style used by
build-aux/extract-ofp-fields.
Reported-by: Lucas Nussbaum
Reported-at: https://bugs.debian.org/1042358
Signed-off-by: Colin Watson
---
lib/meta-flow.xml | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/lib/meta-flow.xml b/lib/meta-flow.xml
index bdd12f6a7..0ac182be1 100644
--- a/lib/meta-flow.xml
+++ b/lib/meta-flow.xml
@@ -3517,23 +3517,24 @@ actio
Bug#1040438: libmail-dkim-perl: missing dependency on libgetopt-long-descriptive-perl
Package: libmail-dkim-perl Version: 1.20230212-1 Severity: serious Justification: Policy 3.5 $ dkimproxy-verify Can't locate Getopt/Long/Descriptive.pm in @INC (you may need to install the Getopt::Long::Descriptive module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/bin/dkimproxy-verify line 13. BEGIN failed--compilation aborted at /usr/bin/dkimproxy-verify line 13. Installing libgetopt-long-descriptive-perl fixes it, but this should clearly be in Depends. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmail-dkim-perl depends on: ii libcrypt-openssl-rsa-perl 0.33-3+b1 ii liberror-perl 0.17029-2 ii libmail-authenticationresults-perl 2.20230112-1 ii libmailtools-perl 2.21-2 ii libnet-dns-perl 1.36-1 ii perl [libdigest-sha-perl] 5.36.0-7 libmail-dkim-perl recommends no packages. libmail-dkim-perl suggests no packages. -- no debconf information Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1033422: base-passwd: missing Build-Depends docbook
Control: severity -1 normal On Fri, Mar 24, 2023 at 07:30:26PM +, henrynmail-deb...@yahoo.com wrote: > Package: base-passwd > Version: 3.6.1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > Usertags: rebootstrap > > Dear Maintainer, > > build in a minimal build environmet fails for docbook2html. > > # apt remove docbook && apt autoremove > # apt build-dep base-passwd > ... some dependency installed ... > # dpkg-buildpackage -j1 -B "-Pnocheck noinsttest noudeb" -uc -us It builds fine for me in sbuild with an unstable chroot, which definitely doesn't have docbook installed; and similarly, when I follow your reproduction recipe in a clean chroot, it still builds fine. In fact, your build environment isn't minimal. Here's the true reproduction recipe: apt install docbook-xml apt build-dep base-passwd dpkg-buildpackage [etc.] base-passwd Build-Depends: docbook-utils Depends: docbook-dsssl Depends: docbook (>= 3.1) | docbook-xml. This means that having docbook-xml already installed causes apt not to install docbook. The RC policy (https://release.debian.org/testing/rc_policy.txt) is that packages must autobuild, and autobuilders don't randomly have non-build-essential packages such as docbook-xml installed, so this is not release-critical. It seems reasonable to add an explicit Build-Depends to fix it, but I don't think I need to trouble the release team requesting a freeze exception to get it into bookworm; it can wait until the next release. In the meantime, I recommend that you make your minimal build environment truly minimal - it shouldn't have non-build-essential packages installed. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1027751: need to properly depend on python3-exceptiongroup
On Tue, Jan 03, 2023 at 12:53:47AM +0530, Nilesh Patra wrote: > While building pairtools version 1.0.2-1 I noticed this error. I have > temporarliy added > a build depend on exceptiongroup in the said package to work around the issue. I ran into the same thing in python-ws4py, and am applying the same workaround there. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1025924: python-rx: Fails to build with Python 3.11 (AttributeError: module 'asyncio' has no attribute 'coroutine')
hreadExceptionWarning(msg)) .pybuild/cpython3_3.11_rx/build/tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_action_cancel_same_loop /usr/lib/python3/dist-packages/_pytest/threadexception.py:73: PytestUnhandledThreadExceptionWarning: Exception in thread Thread-116 (thread_target) Traceback (most recent call last): File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner self.run() File "/usr/lib/python3.11/threading.py", line 975, in run self._target(*self._args, **self._kwargs) File "/<>/.pybuild/cpython3_3.11_rx/build/tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py", line 127, in thread_target @asyncio.coroutine ^ AttributeError: module 'asyncio' has no attribute 'coroutine' warnings.warn(pytest.PytestUnhandledThreadExceptionWarning(msg)) .pybuild/cpython3_3.11_rx/build/tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_action_cancel_same_thread /usr/lib/python3/dist-packages/_pytest/threadexception.py:73: PytestUnhandledThreadExceptionWarning: Exception in thread Thread-117 (thread_target) Traceback (most recent call last): File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner self.run() File "/usr/lib/python3.11/threading.py", line 975, in run self._target(*self._args, **self._kwargs) File "/<>/.pybuild/cpython3_3.11_rx/build/tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py", line 127, in thread_target @asyncio.coroutine ^ AttributeError: module 'asyncio' has no attribute 'coroutine' warnings.warn(pytest.PytestUnhandledThreadExceptionWarning(msg)) .pybuild/cpython3_3.11_rx/build/tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_now_units /usr/lib/python3.11/unittest/case.py:678: DeprecationWarning: It is deprecated to return a value that is not None from a test case (>) return self.run(*args, **kwds) -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html === short test summary info FAILED tests/test_observable/test_fromfuture.py::TestFromFuture::test_future_cancel FAILED tests/test_observable/test_fromfuture.py::TestFromFuture::test_future_dispose FAILED tests/test_observable/test_fromfuture.py::TestFromFuture::test_future_failure FAILED tests/test_observable/test_fromfuture.py::TestFromFuture::test_future_success FAILED tests/test_observable/test_start.py::TestStart::test_start_async - Att... FAILED tests/test_observable/test_start.py::TestStart::test_start_async_error FAILED tests/test_scheduler/test_eventloop/test_asyncioscheduler.py::TestAsyncIOScheduler::test_asyncio_schedule_action FAILED tests/test_scheduler/test_eventloop/test_asyncioscheduler.py::TestAsyncIOScheduler::test_asyncio_schedule_action_cancel FAILED tests/test_scheduler/test_eventloop/test_asyncioscheduler.py::TestAsyncIOScheduler::test_asyncio_schedule_action_due FAILED tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_action FAILED tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_action_cancel FAILED tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_action_cancel_same_loop FAILED tests/test_scheduler/test_eventloop/test_asynciothreadsafescheduler.py::TestAsyncIOThreadSafeScheduler::test_asyncio_threadsafe_schedule_action_due === 13 failed, 1309 passed, 10 skipped, 9 warnings in 20.51s === E: pybuild pybuild:386: test: plugin distutils failed with: exit code=1: cd /<>/.pybuild/cpython3_3.11_rx/build; python3.11 -m pytest tests This looks like https://github.com/ReactiveX/RxPY/issues/588, but it also seems that we're several upstream versions behind. Would packaging 4.0.4 be in order? If this is too big a migration though (I see from https://github.com/ReactiveX/RxPY/blob/master/docs/migration.rst that it doesn't look entirely trivial), at least cherry-picking that fix for now would probably be a good idea. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1021403: [parted] /usr/sbin/parted: invalid token: swap
Control: severity -1 normal Control: fixed -1 3.5-1 On Fri, Oct 07, 2022 at 05:29:14PM +0200, Jean-Marc LACROIX wrote: > Severity: critical "makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package" A difficulty with using the CLI, or even a missing feature in the CLI, doesn't fall into any of these categories. > According documentation available in man it seems possible to create one > partition of type "swap" by using "set" option on command line. > > After many tests done with Linux "parted" command and Ansible module > "parted", it seems that it is not possible to set one logical partition as a > swap partition with the flag option available into parted tool. > > My disk uses for test has following partitions... > > ansible@thinkpad-410:~$ sudo fdisk -l /dev/sda > Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs > Modèle de disque : HGST HTS721010A9 > Unités : secteur de 1 × 512 = 512 octets > Taille de secteur (logique / physique) : 512 octets / 4096 octets > taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets > Type d'étiquette de disque : dos > Identifiant de disque : 0x483880d2 > > Périphérique AmorçageDébutFin Secteurs Taille Id Type > /dev/sda1*2048 48828415 48826368 23,3G 83 Linux > /dev/sda2 48830462 1953523711 1904693250 908,2G 5 Étendue > /dev/sda5 48830464 68360191 19529728 9,3G 8e LVM Linux > /dev/sda6 68362240 703610871998848 976M 82 partition > d'échange Linux / Solaris This says that it's already a swap partition, so I'm not sure why you need to set it as one. Can you explain further? (On an MBR partition table like this, all that setting the "swap" flag does is set the partition type to 0x82.) > /dev/sda7 70363136 742666233903488 1,9G 8e LVM Linux > /dev/sda8 74268672 279068671 20480 97,7G 8e LVM Linux > > and when i try to set one partition with swap, then ... > > ansible@thinkpad-410:~$ sudo /usr/sbin/parted -s -m -a optimal /dev/sda -- > unit KiB set 6 swap on > /usr/sbin/parted: invalid token: swap > > I have also tried, but without success... > > ansible@thinkpad-410:~$ sudo /usr/sbin/parted -s -m -a optimal /dev/sda -- > unit KiB set 6 swap on set 6 lvm off > /usr/sbin/parted: invalid token: swap This was fixed in parted 3.4.64. From the NEWS file: Add use of the swap partition flag to msdos disk labeled disks. But since it's already of the correct type, maybe you can just skip that bit on older versions of parted? (Or, if your automation is building the entire system from scratch, then another option might be to use GPT instead of MBR.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1021123: libgdbm-compat-dev: missing dependency on libgdbm-dev
Package: libgdbm-compat-dev Version: 1.23-2 Severity: serious Justification: Policy 3.5 The header files in libgdbm-compat-dev (dbm.h, gdbm-ndbm.h, and ndbm.h) all have "#include ". libgdbm-compat-dev therefore needs to depend on libgdbm-dev so that this #include can be resolved. (Noticed while improving man-db's upstream CI jobs.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#991936: openssh-server: seccomp filter defaults to SIGSYS, could break any libc or kernel upgrade
Control: severity -1 important Control: tag -1 upstream Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3478 On Fri, Aug 06, 2021 at 11:29:15AM +0200, Julian Andres Klode wrote: > seccomp filters are currently setup to kill the process > > #define SECCOMP_FILTER_FAIL SECCOMP_RET_KILL > > /* Default deny */ > BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL), > > this means every new libc or kernel release can cause openssh > to break, requiring breaks from them on openssh, which does not > scale, and is currently breaking SSH during upgrades. > > This also means openssh might fail to work inside containers > because the host kernel is newer. > > The default policy needs to be changed to return ENOSYS instead, > such that libc can fallback to other syscalls for its wrappers. > With the caveat that umask is a bit broken, if you don't want to > allow it, block it explicitly with RET_KILL: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1724098 > > This should be fixed for bullseye+1, and fixed in a point release > IMO, it might be a tad too late right now for the release itself. I agree this is at least a problem waiting to happen and a noticeable inconvenience for stable release maintenance, so I've (belatedly) forwarded it upstream with a suggested patch. The sandbox is security-critical enough that I don't want to patch fundamental things about its behaviour without upstream's consent, so we'll see what they make of my suggestion. I don't think this needs to be release-critical. It's a significant problem and I'd definitely like it to be fixed, but mostly this change would protect us against specific manifestations of syscall filtering problems that would be grave bugs, rather than being intrinsically RC. As such I'm downgrading it a step for now. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1000796: marked as pending in base-passwd
On Sun, Aug 14, 2022 at 11:27:47PM +0200, Paul Gevers wrote: > On Thu, 03 Mar 2022 00:42:14 +0000 Colin Watson wrote: > > Bug #1000796 in base-passwd 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/debian/base-passwd/-/commit/06ed6f49253ff244dc9cbcadc840fdf611f11462 > > Can we have this uploaded to unstable please? Pending RC bugs for 5 months > are a bit awkward. Uploaded now - sorry for the delay. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1016340: marked as pending in openssh
Control: tag -1 pending Hello, Bug #1016340 in openssh 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/ssh-team/openssh/-/commit/dd1e52af266a53671b162ddd95e4f6b01513e8e5 Work around apparent dh-exec regressions Closes: #1016340 (this message was generated automatically) -- Greetings https://bugs.debian.org/1016340
Bug#1016340: openssh: FTBFS: Failed to copy 'etc/ssh/sshd_config': No such file or directory at /usr/share/dh-exec/dh-exec-install-rename line 68, <> line 7.
dh-exec._KAY3sIj/usr/share/openssh/sshd_config") dh_missing: error: missing files, aborting While detecting missing files, dh_missing noted some files with a similar name to those that were missing. This error /might/ be resolved by replacing references to the missing files with the similarly named ones that dh_missing found - assuming the content is identical. As an example, you might want to replace: * debian/tmp/dh-exec._KAY3sIj/etc/ufw/applications.d/openssh-server with: * dh-exec.aqR1q_B1/etc/ufw/applications.d/openssh-server in a file in debian/ or as argument to one of the dh_* tools called from debian/rules. (Note it is possible the paths are not used verbatim but instead directories containing or globs matching them are used instead) Alternatively, add the missing file to debian/not-installed if it cannot and should not be used. The following debhelper tools have reported what they installed (with files per package) * dh_install: openssh-client (27), openssh-client-udeb (3), openssh-server (14), openssh-server-udeb (2), openssh-sftp-server (2), openssh-tests (10), ssh (0), ssh-askpass-gnome (2) * dh_installdocs: openssh-client (4), openssh-server (0), openssh-sftp-server (0), openssh-tests (0), ssh (0), ssh-askpass-gnome (0) * dh_installexamples: openssh-client (0), openssh-server (1), openssh-sftp-server (0), openssh-tests (0), ssh (0), ssh-askpass-gnome (1) * dh_installman: openssh-client (2), openssh-server (0), openssh-sftp-server (0), openssh-tests (0), ssh (0), ssh-askpass-gnome (1) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. All those debian/tmp/dh-exec.* temporary directories are confusing dh_missing, it seems. I'm not quite sure what's going on here since this used to work. What's the intended design for these temporary directories? Presumably they can't be cleaned up by dh-exec-install-rename itself because the files still need to be processed by dh_install proper. That leaves the dh_missing warning for etc/ssh/sshd_config. That is in fact installed - it's just that debian/.debhelper/generated/openssh-server/installed-by-dh_install lists it as ./debian/tmp/dh-exec._KAY3sIj/usr/share/openssh/sshd_config rather than as the original file name. What are we supposed to do here? This seems like it must be a bug somewhere between debhelper and dh-exec, but I'm not sure exactly where. For now I'm going to work around this in openssh as follows: diff --git a/debian/openssh-server.install b/debian/openssh-server.install index 99cfb8d6b..cf86dce41 100755 --- a/debian/openssh-server.install +++ b/debian/openssh-server.install @@ -7,7 +7,7 @@ usr/share/man/man5/moduli.5 usr/share/man/man5/sshd_config.5 usr/share/man/man8/sshd.8 -etc/ssh/sshd_config => usr/share/openssh/sshd_config +debian/tmp/etc/ssh/sshd_config => usr/share/openssh/sshd_config debian/openssh-server.ucf-md5sum => usr/share/openssh/sshd_config.md5sum debian/openssh-server.ufw.profile => etc/ufw/applications.d/openssh-server diff --git a/debian/rules b/debian/rules index d5a9ee23d..5a8795478 100755 --- a/debian/rules +++ b/debian/rules @@ -203,6 +203,10 @@ override_dh_runit: execute_after_dh_fixperms-arch: chmod u+s debian/openssh-client/usr/lib/openssh/ssh-keysign +# Work around debhelper/dh-exec bug #XXX. +override_dh_missing: + dh_missing --list-missing + # Tighten libssl dependencies to match the check in entropy.c. execute_after_dh_shlibdeps: debian/adjust-openssl-dependencies But this all seems quite weird. Do you have any clues as to any of this? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#983264: marked as pending in troffcvt
Control: tag -1 pending Hello, Bug #983264 in troffcvt 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/debian/troffcvt/-/commit/47ffafea1c1283c9022b80fbe3ddb8b97d368899 Fix compatibility with binutils 2.36 patches/WRPRC-2.11.diff: Change ar command to use cq instead of clq to fix compatibility with binutils 2.36. Closes: #983264 (this message was generated automatically) -- Greetings https://bugs.debian.org/983264
Bug#1010070: python3-fuse: several bindings broken on Python 3.10
Package: python3-fuse Version: 2:1.0.2-1+b1 Severity: grave Anything that uses the "write", "setxattr", or "ioctl" method is broken with Python 3.10 due to the change described at the top of https://docs.python.org/3/whatsnew/3.10.html#id2. Among other things, this breaks the binfmt-support test suite. https://github.com/libfuse/python-fuse/issues/41 already existed for this, and I've proposed https://github.com/libfuse/python-fuse/pull/43 which fixes binfmt-support's tests. An upload of that would be great so that my CI works again. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-23-generic (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages python3-fuse depends on: ii fuse3 [fuse] 3.10.5-1 ii libc6 2.33-7 ii libfuse2 2.9.9-5 ii python3 3.10.4-1 python3-fuse recommends no packages. python3-fuse suggests no packages. -- no debconf information Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#1000796: marked as pending in base-passwd
Control: tag -1 pending Hello, Bug #1000796 in base-passwd 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/debian/base-passwd/-/commit/06ed6f49253ff244dc9cbcadc840fdf611f11462 update-passwd.c: set walk to walk->next before removing update-passwd only removes once and exits even more than one items need to be removed. Root cause is walk is set to walk->next after remove_node(), in which the walk has been cleaned, so the while(walk) is terminated. Without the fix, the output of update-passwd $update-passwd --verbose Adding group "postgres" (120) Adding group "nova" (162) Adding group "barbican" (978) Adding group "keystone" (42424) Adding group "neutron" (164) Adding group "ceilometer" (166) Adding group "sysinv" (168) Adding group "snmpd" (169) Adding group "fm" (195) Adding group "libvirt" (991) Adding group "ironic" (1874) Adding group "www" (1877) Removing group "daemon" (1) Adding user "postgres" (120) Adding user "neutron" (164) Adding user "sysinv" (168) Adding user "snmpd" (169) Adding user "fm" (195) Adding user "barbican" (982) Adding user "ceilometer" (991) Adding user "keystone" (42424) Adding user "nova" (994) Adding user "ironic" (1874) Adding user "www" (1877) Removing user "daemon" (1) 25 changes have been made, rewriting files Writing passwd-file to /etc/passwd Writing shadow-file to /etc/shadow Writing group-file to /etc/group With the fix: $sudo update-passwd --verbose Adding group "postgres" (120) Adding group "nova" (162) Adding group "barbican" (978) Adding group "keystone" (42424) Adding group "neutron" (164) Adding group "ceilometer" (166) Adding group "sysinv" (168) Adding group "snmpd" (169) Adding group "fm" (195) Adding group "libvirt" (991) Adding group "ironic" (1874) Adding group "www" (1877) Removing group "daemon" (1) Removing group "bin" (2) Removing group "lp" (7) Removing group "man" (12) Removing group "audio" (29) Removing group "video" (44) Removing group "games" (60) Adding user "postgres" (120) Adding user "neutron" (164) Adding user "sysinv" (168) Adding user "snmpd" (169) Adding user "fm" (195) Adding user "barbican" (982) Adding user "ceilometer" (991) Adding user "keystone" (42424) Adding user "nova" (994) Adding user "ironic" (1874) Adding user "www" (1877) Removing user "daemon" (1) Removing user "bin" (2) Removing user "games" (5) Removing user "lp" (7) Removing user "mail" (8) 35 changes have been made, rewriting files Writing passwd-file to /etc/passwd Writing shadow-file to /etc/shadow Writing group-file to /etc/group Signed-off-by: Yue Tao Closes: #1000796 (this message was generated automatically) -- Greetings https://bugs.debian.org/1000796
Bug#1006445: openssh-server: Killed by seccomp after accepting connection (i386)
Control: forwarded -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3396 On Fri, Feb 25, 2022 at 03:50:05PM +, Colin Watson wrote: > On Fri, Feb 25, 2022 at 02:14:58PM +, Paul Brook wrote: > > The attached patch fixes this by adding ppoll_time64 the seccomp sanbox > > filters, > > which seems reasonable as ppoll is already allowed. > > Yeah, this looks reasonable to me too, though for tidiness I'd suggest > moving __NR_ppoll_time64 below __NR_ppoll to match the ordering of > __NR_pselect6 and __NR_pselect6_time64. > > Would you mind sending this upstream to https://bugzilla.mindrot.org/ ? > I can do it for you if you can't, but it's usually best to have fewer > people in the middle of the discussion. Looks like somebody else already filed this at https://bugzilla.mindrot.org/show_bug.cgi?id=3396 with a very similar patch, so no need to send it again. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1006445: marked as pending in openssh
Control: tag -1 pending Hello, Bug #1006445 in openssh 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/ssh-team/openssh/-/commit/62765c0d4297dae75c91aa1d3191df3e3a1b5893 Allow ppoll_time64 in seccomp filter Closes: #1006445 (this message was generated automatically) -- Greetings https://bugs.debian.org/1006445
Bug#1006463: openssh-client: Can't login on two i386 boxes anymore since the server-side has been upgraded to 8.9p1: "debug1: expecting SSH2_MSG_KEX_ECDH_REPLY"
Control: forcemerge -1 1006445 On Fri, Feb 25, 2022 at 09:38:31PM +0100, Axel Beckert wrote: > TL;DR: OpenSSH clients (at least 8.8 and 8.9) can't talk with OpenSSH > 8.9 servers in some cases (common property so far: if and only if it's > i386 on the server-side), but 8.9 clients can talk with 8.8 servers in > the same cases (i.e. i386 on the server-side) after downgrading the > server-side. i386 OpenSSH clients can't talk to i386 8.9 servers either. See #1006445. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1005550: marked as pending in password-store
Control: tag -1 pending Hello, Bug #1005550 in password-store 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/debian/password-store/-/commit/188c3d86aeef48ae7ac13f75e087c3904d10b4f0 Ensure compatibility with tree 2.0 Closes: #1005550 (this message was generated automatically) -- Greetings https://bugs.debian.org/1005550
Bug#1003008: marked as pending in grub
Control: tag -1 pending Hello, Bug #1003008 in grub 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/grub-team/grub-legacy/-/commit/0be04af37796a03f6091723199ed50c72b33d4d9 Make convert_to_ascii non-variadic GCC 11 seemed to miscompile this very dodgy by-hand imitation of va_arg otherwise. Closes: #1003008 (this message was generated automatically) -- Greetings https://bugs.debian.org/1003008
Bug#1002803: marked as pending in openssh
Control: tag -1 pending Hello, Bug #1002803 in openssh 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/ssh-team/openssh/-/commit/ae5af192dfe30307ba6568e248ecbda95551d797 Correcting typo in openssh-client.alternatives Closes: #1002803 Signed-off-by: Daniel Baumann (this message was generated automatically) -- Greetings https://bugs.debian.org/1002803
Bug#999238: xdelta: diff for NMU version 1.1.3-9.4
Control: tags 999238 patch pending
Hi LaMont,
I've prepared an NMU for xdelta (versioned as 1.1.3-9.4) and uploaded it
to DELAYED/5. Please feel free to tell me if I should delay it longer.
Regards,
--
Colin Watson [cjwat...@debian.org]
diff -u xdelta-1.1.3/debian/changelog xdelta-1.1.3/debian/changelog
--- xdelta-1.1.3/debian/changelog
+++ xdelta-1.1.3/debian/changelog
@@ -1,3 +1,10 @@
+xdelta (1.1.3-9.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/rules: Add build-arch and build-indep targets (closes: #999238).
+
+ -- Colin Watson Wed, 15 Dec 2021 12:15:05 +
+
xdelta (1.1.3-9.3) unstable; urgency=medium
* Non-maintainer upload.
diff -u xdelta-1.1.3/debian/rules xdelta-1.1.3/debian/rules
--- xdelta-1.1.3/debian/rules
+++ xdelta-1.1.3/debian/rules
@@ -24,13 +24,15 @@
CPPFLAGS=`glib-config --cflags` CFLAGS="${CFLAGS}" \
dh_auto_configure
-build: build-stamp
+build build-arch: build-stamp
build-stamp: config.status
dh_testdir
$(MAKE)
touch $@
+build-indep:
+
autofiles:
#libtoolize --automake --copy --force
#aclocal
@@ -57,12 +59,12 @@
dh_install --sourcedir=debian/tmp --list-missing
-binary-indep: build install
+binary-indep: build-indep
# There are no architecture-independent files to be uploaded
# generated by this package. If there were any they would be
# made here.
-binary-arch: build install
+binary-arch: build-arch install
dh_testdir -a
dh_testroot -a
dh_installchangelogs -a
@@ -81,4 +83,4 @@
dh_builddeb -a
binary: binary-indep binary-arch
-.PHONY: build clean binary-arch binary-indep binary install
+.PHONY: build-arch build-indep build clean binary-arch binary-indep binary install
Bug#1001057: grub2: hold 2.06 in unstable for now
Package: grub2 Version: 2.06-2 Severity: serious Justification: maintainer says so GRUB 2.06 is a pretty big change over 2.04. I'd like to hold this in unstable for a while longer to let things shake out before we allow it to move to testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#997100: marked as pending in grub2
Control: tag -1 pending Hello, Bug #997100 in grub2 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/grub-team/grub/-/commit/66db5e1fe0ddb2d9157e7b715ac69461cc711150 Note bug closure from previous tests/ahci cherry-pick Closes: #997100 (this message was generated automatically) -- Greetings https://bugs.debian.org/997100
Bug#997615: troffcvt: FTBFS: ar: libdeps specified more than once
Control: reassign -1 xutils-dev Control: affects -1 troffcvt Control: merge 994276 -1 On Sat, Oct 23, 2021 at 11:18:52PM +0200, Lucas Nussbaum wrote: > > ar clq libport.a ato.o dir.o fd.o lock.o mem.o > > ar: libdeps specified more than once > > make[3]: *** [Makefile:325: libport.a] Error 1 troffcvt uses imake, so this is #994276. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#997641: knews: FTBFS: ar: libdeps specified more than once
Control: reassign -1 xutils-dev Control: affects -1 knews Control: merge 994276 -1 On Sat, Oct 23, 2021 at 11:18:35PM +0200, Lucas Nussbaum wrote: > > ar clq libWidgets.a ArtText.o ArtTree.o CloseSh.o Dialogue.o FileSel.o > > Login.o Manager.o Menu.o MenuG.o MenuKnapp.o MenuShell.o > > Notice.o Knapp.o Message.o PullRight.o Sash.o Scrollable.o ScrBar.o > > ScrList.o SeparatorG.o Shadow.o StringG.o TextField.o Toggle.o > > ToggleG.o Util.o Layout.o laylex.o laygram.o > > ar: libdeps specified more than once > > make[3]: *** [Makefile:1057: libWidgets.a] Error 1 knews uses imake, so this is #994276. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#994382: marked as pending in storm
Control: tag -1 pending Hello, Bug #994382 in storm 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/python-team/packages/storm/-/commit/bdc07afaf763de0016f5dd820cfc0125c0daa4a9 Remove python3-storm-dbg The automatically-generated -dbgsym packages should be good enough now that Python has a common ABI for normal and debug extension builds. Closes: #994382 (this message was generated automatically) -- Greetings https://bugs.debian.org/994382
Bug#992915: marked as pending in grub
Control: tag -1 pending Hello, Bug #992915 in grub 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/grub-team/grub-legacy/-/commit/e08bd28a6af23870db9668bdd451b2107c1c543a Use mktemp rather than tempfile Closes: #992915 (this message was generated automatically) -- Greetings https://bugs.debian.org/992915
Bug#992093: marked as pending in cccc
Control: tag -1 pending Hello, Bug #992093 in 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/debian//-/commit/bebf6e1d4df5a7ae90b2c9134e36028cc44862ec Repack original source tarball without test/prn1[34].* These files contain code under non-free licences. Closes: #992093 (this message was generated automatically) -- Greetings https://bugs.debian.org/992093
Bug#801951: debian/copyright should mention BSD3 license, not PSF
Control: tag -1 pending On Fri, Jul 02, 2021 at 04:05:05PM +0200, Bastian Germann wrote: > On Fri, 16 Oct 2015 10:48:28 +0200 Stefano Zacchiroli wrote: > > debian/copyright currently refers to (various incarnations of...) the PSF > > license, whereas python-dateutil has been relicense under BSD3 a while ago. > > See http://sources.debian.net/src/python-dateutil/latest/LICENSE/ for > > reference. debian/copyright should be updated (and can be widely simplified > > / > > shortened) to refer to BSD3. > > Current versions (in buster and upcoming bullseye) are dual-licensed under > BSD3 and Apache 2. I am raising the severity because this is a long-standing > policy violation. Thanks for committing a fix for this to git. Do you need sponsorship help to upload this (if so, I'd be happy to do it), or is an upload already in progress? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#934713: os-prober: missing dependency on mount
On Mon, Jun 28, 2021 at 10:17:10PM +0900, Hideki Yamane wrote: > On Thu, 15 Aug 2019 16:49:46 +0200 Johannes Schauer wrote: > > I was not trying to justify or excuse the omission of the src:util-linux > > maintainers. I can only imagine that os-prober somehow slipped through the > > cracks when the src:util-linux maintainers filed bugs against all packages > > that > > need the mount utilities during the buster release cycle. > > > > I agree that the situation now is unfortunate but I only reported this > > problem > > once I stumbled across it. I was not involved in the decision two years ago. > > Anyway, here's a tiny MR > https://salsa.debian.org/installer-team/os-prober/-/merge_requests/9 > > > If it would be a wrong way to deal with this bug, then close above MR > and remove Tags: patch, please. If not - just merge it and push the package > :D This looks correct to me, thanks. Merged and uploaded. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#934713: marked as pending in os-prober
Control: tag -1 pending Hello, Bug #934713 in os-prober 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/installer-team/os-prober/-/commit/4ba8cc3630c068732369659b45a920af364bd006 Add mount dependency (Closes: #934713) > The mount package used to be Essential:yes. Since version 2.29.2-3 it is > not essential anymore and os-prober should depend on it. (this message was generated automatically) -- Greetings https://bugs.debian.org/934713
Bug#934713: marked as pending in os-prober
Control: tag -1 pending Hello, Bug #934713 in os-prober 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/installer-team/os-prober/-/commit/da1f2eba18bdae82c77123f63a17003de41c2d2d Merge branch 'master' into 'master' Add mount dependency (Closes: #934713) See merge request installer-team/os-prober!9 (this message was generated automatically) -- Greetings https://bugs.debian.org/934713
Bug#990017: [REGRESSION] Bullseye CD installer images fail to install GRUB on OpenPOWER machines
Control: tag -1 moreinfo On Thu, Jun 17, 2021 at 07:56:27PM -0500, Timothy Pearson wrote: > - Original Message - > > From: "Steve McIntyre" > > To: "Timothy Pearson" , > > 990...@bugs.debian.org > > Sent: Thursday, June 17, 2021 7:43:15 PM > > Subject: Re: Bug#990017: [REGRESSION] Bullseye CD installer images fail to > > install GRUB on OpenPOWER machines > > > Reassigning this to the correct package where it should get more > > attention... > > Thank you, much appreciated. > > > On Thu, Jun 17, 2021 at 04:20:47PM -0500, Timothy Pearson wrote: > >>Attempting to use the latest Bullseye RC2 CD installer on an OpenPOWER > >>machine > >>results in a fatal error during bootloader installation: > >> > >>Jun 17 21:14:45 grub-installer: info: Installing grub on '/dev/sda1' > >>Jun 17 21:14:45 grub-installer: info: grub-install does not support > >>--no-floppy > >>Jun 17 21:14:45 grub-installer: info: Running chroot /target grub-install > >>--force "/dev/sda1" > >>Jun 17 21:14:45 grub-installer: Installing for powerpc-ieee1275 platform. > >>Jun 17 21:14:57 grub-installer: grub-install: error: unknown filesystem. > >>Jun 17 21:14:57 grub-installer: error: Running 'grub-install --force > >>"/dev/sda1"' failed. > >> > >>The bootloader installs normally using the Buster CD installers on the same > >>hardware. > > > > Just a quick sanity check - how did you partition the disk? Does it > > have the normal boot partition etc. needed for OpenPOWER? I'll admit I > > don't know all the details here - I'm not a powerpc expert. > > All defaults. PReP partition was added automatically by the apparition, it > almost looks like Grub doesn't know what to do with it? > > Layout: > PReP: /dev/sda1 > System: /dev/sda2 > Swap: /dev/sda3 It's been quite a while since I dealt with this, but grub-install certainly shouldn't be looking for a filesystem on the PReP partition - indeed, the current code expects it to be empty. When the install fails, could you please run: chroot /target grub-install --debug --force /dev/sda1 >/var/log/grub-install.out 2>&1 ... and then extract the resulting /var/log/grub-install.out file (e.g. using the "Save debug logs" main menu entry)? If you're able to also run "grub-install --debug /dev/sda1" on a working buster system (assuming the PReP partition is on /dev/sda1 there too) and provide the full output for comparison purposes, that would be helpful as well. You may need to clear that partition first using dd, but if so grub-install should tell you the necessary command. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)
Control: tag -1 moreinfo
Sorry for our long delay in replying to this.
On Mon, Mar 08, 2021 at 02:20:08PM +1100, Anand Kumria wrote:
> grub went into grub rescue mode and displayed:
>
> error: symbol `grub_is_lockdown` not found
In general, this means that grub-install is not installing to the place
that your firmware is actually booting from, which causes the core image
(installed to a file under /boot/efi/ on UEFI systems) to be out of sync
with the modules (installed to a subdirectory of /boot/grub/). This is
much rarer on UEFI systems than on BIOS systems, but it's still possible
in some misconfigured cases.
Could you please attach the output of "sudo grub-install --debug", "sudo
efibootmgr -v", and "sudo find /boot/efi -ls"?
> Currently, I am booting using a rescue CD and then entering commands to
> manually start the laptop
What commands are you using?
> -- Package-specific info:
>
> *** BEGIN /proc/mounts
> /dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
> /dev/sda6 /home ext4 rw,relatime 0 0
> /dev/sda2 /boot/efi vfat
> rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> 0 0
> *** END /proc/mounts
[...]
> *** BEGIN /dev/disk/by-id
> total 0
> lrwxrwxrwx 1 root root 9 Mar 8 11:14 ata-MATSHITADVD-RAM_UJ8C2_WP18_009183
> -> ../../sr0
> lrwxrwxrwx 1 root root 9 Mar 8 11:14 ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY
> -> ../../sda
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part1 -> ../../sda1
> lrwxrwxrwx 1 root root 10 Mar 8 11:15
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part2 -> ../../sda2
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part3 -> ../../sda3
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part4 -> ../../sda4
> lrwxrwxrwx 1 root root 10 Mar 8 11:14
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part5 -> ../../sda5
> lrwxrwxrwx 1 root root 10 Mar 8 11:15
> ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY-part6 -> ../../sda6
> *** END /dev/disk/by-id
>
> *** BEGIN /dev/disk/by-uuid
> total 0
> lrwxrwxrwx 1 root root 10 Mar 8 11:14 141A3D7E1A3D5E44 -> ../../sda4
> lrwxrwxrwx 1 root root 9 Mar 8 11:15 2020-11-30-03-01-21-00 -> ../../sr0
> lrwxrwxrwx 1 root root 10 Mar 8 11:15 26cd5a33-dd28-4968-b2b4-2d134be2e444
> -> ../../sda6
> lrwxrwxrwx 1 root root 10 Mar 8 11:14 A65030AD50308659 -> ../../sda1
> lrwxrwxrwx 1 root root 10 Mar 8 11:15 DE31-8EDF -> ../../sda2
> lrwxrwxrwx 1 root root 10 Mar 8 11:14 a49dde0e-f2e4-4679-8c56-b9013d7b0fd2
> -> ../../sda5
> *** END /dev/disk/by-uuid
I notice that not all your partitions are mounted. What's on partitions
1, 3, and 4? ("sudo parted -s /dev/sda print" might help.)
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#945001: grub-efi-amd64: GRUB-EFI messes up boot variables
Control: tag -1 moreinfo Sorry for our long delay in replying to this. On Mon, Nov 18, 2019 at 10:16:43AM +0100, Heinrich Schuchardt wrote: > I have multiple disk with different operating systems each with its own > bootloader. > > Updating GRUB delete all existing UEFI variables BOOT and put in > some values that do not make any sense for my system. I had a lot of > trouble to get my system running again. If possible, the output of "sudo grub-install --debug" would be the most helpful thing you could provide here. I understand if that is difficult due to the work needed to get back to a working state afterwards, but it's really what we need to see. Could you also please provide a dump of /sys/firmware/efi/efivars/ (or at least all the Boot* entries there) as well the output of "sudo efibootmgr -v", ideally both before and after running grub-install? Even if you can't provide grub-install --debug output, a snapshot of this information may still be helpful. I notice that you say "BOOT", rather than "Boot" as I see on my system. Does this match how your variables are named? If this is a case-sensitivity issue, that could possibly be interesting. (However, I think such firmware would be non-compliant; the latest version of the UEFI spec that I have to hand specifies "Boot" and has no indication that it may be case-insensitive.) Even so, the only Boot entries that grub-install might intentionally delete are second and subsequent entries with the label "debian". Anything else is definitely unintentional and indicates something quite odd going on. > I do not expect GRUB to ever touch my UEFI variables without my explicit > consent. Please, provide a dialogue. I don't think this is an expectation we can fulfil given the stated purpose of the grub-efi-amd64 package, which is to be your system's active boot loader: it may have to edit the boot order to achieve that. You can remove grub-efi-amd64 and leave only grub-efi-amd64-bin if you want to deal with the step of installing GRUB manually. All the same, what you're seeing would certainly be a bug, just not one whose cause I can identify without more information. Adding a dialogue to work around such a bug is probably not the right answer. (Release team: the code likely to be responsible for this hasn't significantly changed since 2.02+dfsg1-14, which predates buster. Since I don't yet understand the bug I can't say for sure, but you might wish to draw the conclusion that this bug probably existed in buster as well and thus shouldn't block bullseye.) > Bug report 913916 seems to be related but I am not sure if it is > reporting the same issue. That was against 2.02~beta3-5+deb9u1, and I essentially rewrote grub-install's UEFI boot variable handling in 2.02+dfsg1-14. It could probably only be the same issue if it turns out to be a problem in the efivar userspace library or in the kernel (or I suppose perhaps in the firmware). Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#940911: marked as pending in grub2
Control: tag -1 pending Hello, Bug #940911 in grub2 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/grub-team/grub/-/commit/80ffd292d9cab51fd6f9adf60ae98f9cee840b7e tpm: Pass unknown error as non-fatal, but debug print the error we got Closes: #940911 LP: #1848892 (this message was generated automatically) -- Greetings https://bugs.debian.org/940911
Bug#989229: grub-install: warning: Cannot read EFI Boot* variables.
Control: reassign -1 linux Control: affects -1 grub2-common On Sat, May 29, 2021 at 12:00:17PM -0400, Joseph Maher wrote: > grub seems unhappy on my laptop (testing=bullseye, acer spin 1), currently > grub-install doesn't work, and so the various grub packages aren't > installable / upgradable > > Not sure what the severity should be, or which package I should file a bug > against, but I've appended some typical output below that may or may not be > useful: > > Yours > > Joseph > > > # grub-install --target=x86_64-efi > Installing for x86_64-efi platform. > grub-install: warning: Cannot read EFI Boot* variables. > grub-install: warning: efivarfs_get_variable: read failed: Interrupted system > call. > grub-install: warning: efi_get_variable: ops->get_variable failed: > Interrupted system call. > grub-install: error: failed to register the EFI boot entry: Interrupted > system call. > > > # grub-install --target=x86_64-efi --debug > > This output is very verbose, but I've left a copy here: > > https://www.maher.org.uk/~joseph/20210529-grub-install.log > > > > # efibootmgr Skipping unreadable variable "Boot": Interrupted system > call > Skipping unreadable variable "Boot0001": Interrupted system call > Skipping unreadable variable "Boot0002": Interrupted system call > Skipping unreadable variable "Boot0003": Interrupted system call > Skipping unreadable variable "Boot0005": Interrupted system call > Skipping unreadable variable "Boot0008": Interrupted system call > Skipping unreadable variable "Boot000B": Interrupted system call > Skipping unreadable variable "Boot000E": Interrupted system call > Skipping unreadable variable "Boot0011": Interrupted system call > Skipping unreadable variable "Boot0014": Interrupted system call > Skipping unreadable variable "Boot0017": Interrupted system call > Skipping unreadable variable "Boot2001": Interrupted system call > Skipping unreadable variable "Boot2002": Interrupted system call > Skipping unreadable variable "Boot2003": Interrupted system call > show_order(): Interrupted system call The fact that both grub-install and efibootmgr are getting EINTR here (albeit with different subsequent effects) suggests to me that the problem is at a lower level. This looks like it's probably a kernel bug, or maybe (though less likely IMO) a bug in the efivar userspace library. Reassigning to the kernel for now. I suspect "strace -f -s 1024 grub-install --target=x86_64-efi" and "strace -f -s 1024 efibootmgr" might be helpful, along with checking dmesg to see if the kernel is logging any errors there. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#990879: marked as pending in base-passwd
Control: tag -1 pending Hello, Bug #990879 in base-passwd 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/debian/base-passwd/-/commit/bf262828aae9a6ddbc6bcb539c88dd4550cb49c7 Skip irc home directory question in default setups update-passwd.c: Skip debconf question when changing irc's home directory from /var/run/ircd to /run/ircd, since these are equivalent. [cjwatson: fixed boolean logic] Closes: #990879 (this message was generated automatically) -- Greetings https://bugs.debian.org/990879
Bug#990879: base-passwd: asks high-priority question about irc user's home directory when upgrading from buster to bullseye
Package: base-passwd Version: 3.5.49 Severity: serious In response to https://bugs.debian.org/946884, I changed the irc user's home directory from /var/run/ircd to /run/ircd in base-passwd 3.5.48. However, I noticed in a recent test upgrade from buster to bullseye that this causes users with default configurations to be prompted to accept this change. This was not my intention when making this change: /var/run/ircd and /run/ircd are equivalent (base-files.postinst makes /var/run a symlink to /run) and so the prompt is simply noise that I expect to confuse some users. Some of this confusion is visible for Ubuntu users here: https://bugs.launchpad.net/ubuntu/+source/base-passwd/+bug/1916651 I think this is worth fixing before it causes problems for users doing stable upgrades. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#984520: 'error: symbol "grub_register_command_lockdown" not found' and then lightdm fails to start
On Thu, Jun 03, 2021 at 11:07:27AM +0200, Jesús Ángel wrote: > I am also facing this error every now and then. Sometimes GRUB doesn't > boot and keeps showing "error: symbol `grub_register_command_lockdown' > not found.". > On pressing any key, GRUB restarts and I get the same error again. If you're getting this non-deterministically, it suggests that you have multiple possible boot disks and either your firmware is picking one or the other inconsistently, or GRUB isn't properly configured to install to the right ones. You should run "dpkg-reconfigure grub-pc" and select all the disks that your firmware might boot from at the "GRUB install devices:" prompt. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#984520: 'error: symbol "grub_register_command_lockdown" not found' and then lightdm fails to start
On Thu, Mar 04, 2021 at 05:18:18PM +0100, Marco Kühnel wrote: > after the recent update to grub2/202+dfsg1-20+deb10u4, during boot the > mentioned error is thrown. After that, boot continues but lightdm cannot be > started anymore. > This only happens on my laptop containing two bootable hard disks. The > separate boot partitions share /boot/efi and from the second hard disk its > Ubuntu > installation still boots flawlessly. For the Debian installation, /boot and > /boot/efi are both on /dev/sda, but by default the laptop boots from /dev/sdb. What do you mean by "the laptop boots from /dev/sdb"? If your EFI System Partition is on /dev/sda1, then by definition that's where the boot loader lives, unless you're doing something else odd. Do you just mean that your root file system is on /dev/sdb? > Tried: grub-install /dev/sda In UEFI mode, grub-install ignores the device name you give it, and always installs to the EFI System Partition on /boot/efi. Could you please post the full output of "grub-install --debug"? -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target
Control: severity -1 important On Wed, Feb 17, 2021 at 09:36:15AM +0100, Thomas Goirand wrote: > Package: openssh-server > Version: 1:8.4p1-4 > Severity: grave No. It may yet need to be sorted out before release, but this is a rare situation and I'm not having it being release-critical right now, especially because it's not clear that it's openssh-server's problem. > On a Sid/Testing system, currently we have in /lib/systemd/system/ssh.service: > > After=network.target auditd.service > > While this isn't a problem in most installation, it didn't work under our > setup, > because we use "bgp-to-the-host" networking. In this setup, we need FRR (the > BGP routing daemon which is a fork of Quagga, if you didn't know) to provide > network connectivity to the server. Our configuration is something like this: > > # cat /etc/frr/frr.conf > [...] > ! > int lo > ip address 10.56.17.7/32 > ! > [...] > > This means that, until FRR is fully up and running, with the BGP session > established, the server IP (10.x.x.x/32 bound to the loopback interface) isn't > set yet on the server, and the ssh daemon cannot bind on the IP (as it's not > there yet). Are you using ListenAddress in sshd_config? Normally sshd doesn't require network interfaces to be online - it just binds to 0.0.0.0 or [::] and that's enough for it to be bound to interfaces as they come up. If lo has to be up for this to work (which is surprising to me, but maybe), then I think there's a decent argument for frr to be part of network.target on such systems. > Our fix was pretty simple: > > # cat /etc/systemd/system/ssh.service.d/override.conf > [Unit] > After=network-online.target auditd.service > > But IMO, this is very wrong to mandate doing this, and not having ssh > connectivity after a reboot, is kind of a grave problem. > > So, could you hard-wire this in the openssh-server package directly, so Debian > users can avoid such an override? Indeed After=network.target doesn't tell you > that network is ready. After=network-online.target does, and that's IMO what > the ssh daemon should be using. I don't agree that network-online.target is appropriate in general, from its documentation: network-online.target Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service. Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up[1] for more information. sshd does not in general require a configured network connection just to start up, and making it do so would be a pretty significant change to the unit dependency graph on most systems; it would make "is not [part of the boot process]" above typically untrue, for one thing. See also https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, which among other things (in general the tone of that page is that a well-written service should not use After=network-online.target) says: "If you write a server: listen on [::], [::1], 0.0.0.0 and 127.0.0.1 only. These pseudo-addresses are unconditionally available." That's what sshd does in its default configuration. If it doesn't work, the systemd documentation suggests that something else is not fulfilling its end of a contract somewhere. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Mon, Feb 15, 2021 at 11:31:45AM +0100, Andreas Henriksson wrote: > On Mon, Feb 15, 2021 at 09:41:30AM +0000, Colin Watson wrote: > > FWIW, I think your patch in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982705#25 is correct > > (even if I prefer to take a different approach as a workaround for the > > packaging) and could be forwarded upstream. Would you mind doing that? > > I normally prefer people to forward their own patches where possible so > > that there's no doubt about copyright/licensing intent or whatever. > > Agreed. The patch is fixing stuff in the non-portable version though > and I couldn't figure out how to contribute to that. The only > contribution info I could find lead to donating money to openbsd. IME: just send it as a bug on bugzilla.mindrot.org and they sort out which branch to apply it to. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982705: marked as pending in openssh
Control: tag -1 pending Hello, Bug #982705 in openssh 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/ssh-team/openssh/-/commit/d0cee71ebcde7400f7caa1fcbf0f997302d1528f Avoid using libmd's even if it's installed Closes: #982705 (this message was generated automatically) -- Greetings https://bugs.debian.org/982705
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Mon, Feb 15, 2021 at 01:52:59AM +0100, Andreas Henriksson wrote: > On Sun, Feb 14, 2021 at 01:05:11PM +0000, Colin Watson wrote: > > How about this approach instead? Given the choice between a > > packaging-only change and one that requires another patch against > > upstream, I have a slight preference for the packaging-only change as > > long as it's basically reasonable, which I think this is. It just > > overrides configure's automatic detection and tells it that sha2.h isn't > > available. Builds cleanly and doesn't seem to incur any new direct > > dependencies. > > Whatever works and feel free to choose the way you as maintainer > prefers as far as I'm concerned! :) Right, I'll go ahead and upload this. > FWIW I make similar choices myself, but my definition of preferred > solution is a bit more complicated. Nothing is ever as permanent > as something temporary. It's not uncommon to see a temporary > hack be forgotten about and then not be dropped when it's > no longer needed, just to come back later and bite you in the ass. > So while I agree with your rule in general, I go for patches when > there's a big chance that the patch will stop apply when upstream > fixes this. Then it's hard to miss that it should be dropped when > the package is updated the next time However there's no guarantee > that will happen with my patch, so it's really up to you to go > with your gut feeling. Yeah, I agree with your more nuanced version of this too. FWIW, I think your patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982705#25 is correct (even if I prefer to take a different approach as a workaround for the packaging) and could be forwarded upstream. Would you mind doing that? I normally prefer people to forward their own patches where possible so that there's no doubt about copyright/licensing intent or whatever. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#982705: openssh: FTBFS: sha2.h:57:16: error: redefinition of ‘struct _SHA2_CTX’
On Sun, Feb 14, 2021 at 12:49:29PM +0100, Andreas Henriksson wrote: > Attached is a possibly upstreamable patch that solves our problem > (but the base problem still exists in the code for anyone wishing to > build with openssl disabled). Thanks for digging into this. How about this approach instead? Given the choice between a packaging-only change and one that requires another patch against upstream, I have a slight preference for the packaging-only change as long as it's basically reasonable, which I think this is. It just overrides configure's automatic detection and tells it that sha2.h isn't available. Builds cleanly and doesn't seem to incur any new direct dependencies. diff --git a/debian/rules b/debian/rules index 73a53c309..44bac00f1 100755 --- a/debian/rules +++ b/debian/rules @@ -65,6 +65,10 @@ ifeq ($(DEB_HOST_ARCH_OS),hurd) confflags += --with-libs=-lcrypt endif +# Avoid using libmd even if it's installed; see +# https://bugs.debian.org/982705. +confflags += ac_cv_header_sha2_h=false + # Everything above here is common to the deb and udeb builds. confflags_udeb := $(confflags) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#966575: grub-pc: Bailing out if the boot device from the debconf database does not longer exist might produce a more complicated issue
On Thu, Feb 11, 2021 at 09:34:31PM +0100, Daniel Leidert wrote: > I recently stumbled into this issue myself. Reading your explanation was very > helpful. However the way you fixed it produces another issue as described > here: > > https://forum.openmediavault.org/index.php?thread/37903-grub-related-error-on-5-5-23-update/ > > The command suggested by the error message (dpkg-reconfigure) actually doesn't > work if grub-pc is not fully installed. Hm, it's true that's not entirely ideal, sorry. I think I'd probably meant to recommend an interactive run of "dpkg --configure grub-pc", but I'll need to think about how to present that best. Your reply on that thread seems slightly overkill - there should be no reason to drop to low priority, since the relevant questions are asked at critical. > I don't have a technical solution myself, but bailing out creates an > even worse situation here. For context: every single time the GRUB core <-> modules ABI has changed in the last ten years or so, we've had multiple critical bugs filed due to unbootable systems as a result of incorrect configuration causing the boot loader to be only half-upgraded. I entirely disagree that a failed upgrade, even on many systems, is a worse situation than that. > Maybe instead of bailing out print a warning instead? I simply don't think that enough people are going to see a warning in the middle of what's often thousands of lines of dpkg output to make any kind of difference. The postinst already only bails out if it can't prompt you interactively to fix the problem, and people are even less likely to notice warnings printed in the middle of a *noninteractive* upgrade. They'll just find out about it when they reboot and their system doesn't come up, which is worse. It's also worth noting that bailing out here has apparently prompted some bit of FAI config to be found and fixed, which has probably been the partial cause of quite a few of those bugs. The problem with this whole situation is that I've always known that a large part of the fix would have to be in installer-type code somewhere, but could never track down where the bugs were because they were on other people's systems and often years distant in time; that's been apparently intractable and very frustrating. Maybe it's just luck, but in those terms this has already been one of the most successful interventions I've found so far. > I was also thinking: If this cannot be handled in a technical way this should > definitely be mentioned in the release notes. I'm not opposed to some kind of mention in the release notes, I suppose, but it feels like more of a general operations manual sort of thing (for example, it might happen on the next upgrade after a subtly-botched disk swap), and I'm not sure where would be best. This isn't particularly specific to any one Debian release. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists
On Tue, Feb 09, 2021 at 12:56:27AM +0100, Ivo De Decker wrote: > I was wondering if there is a way to make it clear that the seccomp filter > has actually blocked something, perhaps by showing a warning. That would > make it easier to debug something like this in the future. Maybe that should > be a separate (wishlist) bug. It's worth a separate bug report, yes. When I initially added seccomp support to man-db, this would have been pretty hard, but I think the SCMP_FLTATR_CTL_LOG attribute that libseccomp supports nowadays would make it possible to at least have the kernel log something to dmesg, which is probably the best that can be done. (I haven't tested that as yet, though.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#969072: dahdi-tools FTBFS on armel/mipsel/hppa/powerpc: pre-grohtml: fatal error: cannot create temporary file: File exists
On Mon, Feb 08, 2021 at 07:17:57PM +0100, Ivo De Decker wrote: > On Sat, Nov 21, 2020 at 07:06:02PM +0200, Tzafrir Cohen wrote: > >On abel in a armel chroot the issue is reproduced by running: > > man -Thtml > >even on an empty man page. > > > >Right now you can try: > > > >$ schroot -r -c session:tzafrir-dahdi-tools -- man -Thtml ~tzafrir/test.8 > >>/dev/null > >pre-grohtml: fatal error: cannot create temporary file: File exists > >man: command exited with status 1: /usr/lib/man-db/zsoelim | > >/usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e > >UTF-8 | tbl | groff -mandoc -Thtml > > > >Not reproduced in a armhf chroot there or in a qemu armel chroot on my > >laptop. > > When running this with MAN_DISABLE_SECCOMP=1, the issue goes away, so it's > caused by the seccomp filter man is setting up when running groff. I guess > some system call must be (slightly) different on some of the architectures, > and it's not allowed by the filter. > > So it seems this is a bug in man-db. Ah yes, sorry for missing this. Running strace on abel, it looks like clock_gettime64 is the offending syscall, which means that https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7315a9475d8fa37af49e9e7ed11e1534f23ef70b should fix this; I've tested that on abel and it seems to do the job. The upstream changes since 2.9.3 are not otherwise especially intrusive (mostly new translations), so I think I'll deal with this by doing a new upstream release and packaging that. I'm working on that now. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 01:44:47PM +0100, Julian Andres Klode wrote: > On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > > The break hasn't been added randomly, but in response to upstream > > release notes and bug #965932. In short the openssh seccomp filters in > > buster are too narrow, and do not allow the new 64-bit syscalls needed > > for 64-bit time_t compatibility to be used. Would it help to get those seccomp filter fixes into buster, and then we could tell people that they have to upgrade to the latest point release first? Awkward but not unprecedented I think. > An alternative solution, for openssh-server would be to avoid using the > new syscalls for 64-bit time_t compatibility I assume (forcing it to > link with older symbol versions?), Changing openssh-server in bullseye can't possibly help here, because if you've upgraded openssh-server then that will include the updated seccomp filters anyway. Changing openssh-server in buster might help, but if so it would be much simpler to take the approach above (backporting the seccomp filter fixes) rather than doing symbol versioning hacks. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#971093: closed by Debian FTP Masters (reply to Jonas Meurer ) (Bug#971093: fixed in lazr.config 2.2.2-1)
On Mon, Jan 25, 2021 at 10:59:28PM +, Colin Watson wrote: > On Sat, Jan 02, 2021 at 12:24:05AM +, Debian Bug Tracking System wrote: > >* Disable test `test_not_stackable` which fails for python3.9 > > (Closes: #970148) > > Thanks for sorting out the immediate issue, but this should really have > been reported upstream for a proper fix. I've proposed a better fix > just now: > > > https://code.launchpad.net/~cjwatson/lazr.config/zope.interface-5.0.0/+merge/396876 Fixed upstream now in lazr.config 2.2.3, and I've uploaded 2.2.3-1 to Debian. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#971093: closed by Debian FTP Masters (reply to Jonas Meurer ) (Bug#971093: fixed in lazr.config 2.2.2-1)
On Sat, Jan 02, 2021 at 12:24:05AM +, Debian Bug Tracking System wrote: > Source: lazr.config > Source-Version: 2.2.2-1 > Done: Jonas Meurer [...] >[ Jonas Meurer ] >* New upstream release. (Closes: #971093) >* d/control: > - Add myself to Uploaders > - Remove Barry Warsaw from Uploaders > - Update standards version to 4.5.1, no changes needed. >* Disable test `test_not_stackable` which fails for python3.9 > (Closes: #970148) Thanks for sorting out the immediate issue, but this should really have been reported upstream for a proper fix. I've proposed a better fix just now: https://code.launchpad.net/~cjwatson/lazr.config/zope.interface-5.0.0/+merge/396876 -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#980367: grub-common: disregards settings in /etc/default/grub
On Mon, Jan 18, 2021 at 05:31:53PM +0900, Norbert Preining wrote: > I am not sure when it happened, but it seems that grub started to ignore > settings in /etc/default/grub, despite /etc/grub.d/README referring to > it, and pervious versions correctly used it. > > I have to add additional boot parameters which I add via > GRUB_CMDLINE_LINUX_DEFAULT="" > but those are not ending up anymore in /boot/grub/grub.cfg Nothing's changed in this area recently, so I'm going to need you to attach at least the following: * /etc/default/grub * the resulting /boot/grub/grub.cfg * any output from "sudo update-grub" -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#978515: marked as pending in grub2
Control: tag -1 pending Hello, Bug #978515 in grub2 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/grub-team/grub/-/commit/fdff3397ab772d328e179bc34900f045df84cc78 Build with GCC 10 Closes: #978515 (this message was generated automatically) -- Greetings https://bugs.debian.org/978515
Bug#973199: marked as pending in python-libnacl
Control: tag -1 pending Hello, Bug #973199 in python-libnacl 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/python-team/packages/python-libnacl/-/commit/fb39afbbd81293f5c3c4f015f38ed02d8272de5c Update upstream source from tag 'upstream/1.7.2' Update to upstream version '1.7.2' with Debian dir 46aef562b4952ca77b362110f015e807d8e81f7d Closes: #973199 (this message was generated automatically) -- Greetings https://bugs.debian.org/973199
Bug#973199: marked as pending in python-libnacl
Control: tag -1 pending Hello, Bug #973199 in python-libnacl 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/python-team/packages/python-libnacl/-/commit/4bb19237beb77790a56b46c7186c6980692a250c Update upstream source from tag 'upstream/1.7.2' Update to upstream version '1.7.2' with Debian dir 46aef562b4952ca77b362110f015e807d8e81f7d Closes: #973199 (this message was generated automatically) -- Greetings https://bugs.debian.org/973199
Bug#966575: marked as pending in grub2
Control: tag -1 pending Hello, Bug #966575 in grub2 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/grub-team/grub/-/commit/e6f75471fd2046dbebcd6fc02585bb3c567b6bdb Check whether target device exists before grub-install Explicitly check whether the target device exists before running grub-install, since grub-install copies modules to /boot/grub/ before installing the core image, and the new modules might be incompatible with the old core image. Closes: #966575 (this message was generated automatically) -- Greetings https://bugs.debian.org/966575
Bug#966575: How to fix LLVM/LUKS installs?
On Tue, Aug 11, 2020 at 12:51:17PM -0400, Todd Howe wrote: > I got around to fixing my desktop today. In addition to the instructions I > posted above and the procedure to mount system directories below, there was > only one necessary change: > > https://gist.github.com/samuelcolvin/43c5ed2807e7db004b1058d0c9bfb068 > > That guy suggested used grub-install /dev/sda instead of dpkg-reconfigure > grub-pc. If you do this, then it will work for now but you may still have a problem on later upgrades. You must do "dpkg-reconfigure grub-pc" at some point and instruct it to install to the right place, even if you didn't do it as part of the initial recovery process. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#966575: How to fix LLVM/LUKS installs?
On Tue, Aug 04, 2020 at 05:08:44PM -0400, Todd Howe wrote: > ls /media/root/$UUID > apt install grub > grub-install --root-directory=/media/root/$UUID /dev/sda I generally don't recommend this sort of approach. Instead, and simpler: for x in dev proc sys; do mount --rbind "/$x" "/media/root/$UUID/$x" done chroot "/media/root/$UUID/$x" dpkg-reconfigure grub-pc exit for x in dev proc sys; do umount -l "/media/root/$UUID/$x" done (Untested and there may be some minor roadblocks, but this is my usual approach; if you do this interactively then hopefully it'll be reasonably clear how to make whatever minor adjustments are needed. I think it's essentially just the bind-mounts that you were missing when you tried to chroot later on.) -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
On Sat, Aug 01, 2020 at 01:52:41PM +0100, Steve McIntyre wrote:
> * Do we need to scan? if grub is installed and doing an upgrade and
>there is only one disk of an appropriate type (BIOS with DOS, or
>UEFI with GPT), then always install there?
Possibly. I'd still be inclined to have a scan as a guard-rail in that
case, since we'd need to have the code anyway, and the point is to try
to discover the disk that the system booted from so by definition it
must have GRUB there if it's to be valid.
> * (Maybe) we could add an option for grub-pc to always grub-install
>to *all* the BIOS-visible disks? Yes, I know there's a potential
>for breakage there with multi-boot systems. Maybe only do this on
>systems where os-prober has not found anything but the Debian
>installation?
One concern I have is filtering out things like optical drives, which
are BIOS-visible but not sensible grub-install targets. I'm also
slightly reluctant to add more invocations of os-prober while it's as
slow as it can sometimes be. I do see the utility of this though.
> * If we do add the code to scan boot sectors, maybe check all the
>BIOS-visible disks and flag any that look like they have GRUB, but
>are not our version? (Not sure how feasible this is without
>digging!)
Unfortunately I believe this to be essentially infeasible. As an
illustration, this is the scan code which exists in the current postinst
to support migration from GRUB Legacy, and believe me I didn't resort to
this horror before trying to find more sensible alternatives:
# In order to determine whether we accidentally ran grub-install without
# upgrade-from-grub-legacy on versions older than 1.98+20100617-1, we need
# to be able to scan a disk to determine whether GRUB 2 was installed in its
# boot sector. This is specific to i386-pc (but that's the only platform
# where we need it).
scan_grub2()
{
if ! dd if="$1" bs=512 count=1 2>/dev/null | grep -aq GRUB; then
# No version of GRUB is installed.
return 1
fi
# The GRUB boot sector always starts with a JMP instruction.
initial_jmp="$(dd if="$1" bs=2 count=1 2>/dev/null | od -Ax -tx1 | \
head -n1 | cut -d' ' -f2,3)"
[ "$initial_jmp" ] || return 1
initial_jmp_opcode="${initial_jmp%% *}"
[ "$initial_jmp_opcode" = eb ] || return 1
initial_jmp_operand="${initial_jmp#* }"
case $initial_jmp_operand in
47|4b|4c|63)
# I believe this covers all versions of GRUB 2 up to the package
# version where we gained a more explicit mechanism. GRUB Legacy
# always had 48 here.
return 0
;;
esac
return 1
}
The actual package version does get embedded in the boot loader, but
only in the "normal" module, not anywhere that could be usefully
discovered by a scan. Otherwise the best we could do would basically be
a big list of signatures, which I'm not enthusiastic about.
> * For UEFI, I'd love to switch to using the monolithic GRUB image
>even for non-signed use. It makes a lot of the issues go away if
>~all the modules necessary for boot are always built-in.
I think I agree, though we should take that to a separate bug; I'd like
to keep this one for the BIOS situation.
> * Finally, we should also stop using debconf as a registry like we
>are. It's annoying the DSA folks (at least). By all means use
>debconf to help manage things, but we should be storing the lasting
>config in a config file that people can edit. We already store some
>of our stuff in /etc/default/grub, let's push more of our config
>there?
Agreed in general terms; this has been on my to-do list for a long time.
Of course we need to consider the migration path carefully. In terms of
specifics, I'm not sure I want to extend /etc/default/grub for this,
though; that has configuration file management issues, and generally I
don't really want to overload the upstream grub-mkconfig configuration
file with packaging-specific things for grub-install. I'd be inclined
to go for /etc/default/grub-pc instead, or maybe something under
/etc/grub/.
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#966575: grub-pc: error: symbol `grub_calloc' not found.
On Sat, Aug 01, 2020 at 01:32:33PM +0200, Miklos Quartus wrote: > I am reporting this bug here Please could you file this as a *new* bug report, *not* as a followup to #966575 which I would much rather keep for just the more common BIOS case? Ideally you would do this by typing "reportbug grub-efi-amd64" and following the prompts from there; this will automatically include some more information about your system that you haven't yet provided. If reportbug doesn't work for some reason, you can send email to sub...@bugs.debian.org with this paragraph at the top of your email: Package: grub-efi-amd64 Version: 2.02+dfsg1-20+deb10u2 ... and we can ask for more information from there. -- Colin Watson (he/him) [cjwat...@debian.org]
