Bug#1077765: marked as pending in openssh
Control: tag -1 pending Hello, Bug #1077765 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/b7f99430d6680677d4ae7ef30acc14ae7ff46dbd Don't close sockets passed by systemd socket activation Closes: #1077765 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077765
Bug#1077765: openssh: can't be started by ssh.socket anymore
On Thu, Aug 01, 2024 at 07:01:28PM +0200, Raphaël Halimi wrote: > Since the latest openssh upgrade, ssh.socket service can't start > ssh.service. > > It fails with the error message "fatal: Cannot bind any address", and gives > up after 5 tries (which is expected), leaving the machine unreachable. > > ssh.service on its own starts normally. > > This is a regression, as previous versions of ssh.socket were able to start > the service without problems. > > A simple workaround is to disable ssh.socket and enable ssh.service, but it > would be nice to have systemd socket activation working again. My best guess is that this has something to do with the refactoring of sshd into a listener binary and a per-session binary, which touched the re-exec path that's also involved in socket activation. I'll try to figure it out, but it may take a little while. I think we should probably also add an autopkgtest for the socket activation case. Since it's not the default and not otherwise automatically tested right now, it's easy for it to break accidentally. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1077735: libssh2: FTBFS with OpenSSH 9.8
Source: libssh2
Version: 1.11.0-6
Severity: serious
Tags: ftbfs
OpenSSH 9.8 disabled DSA by default at compile time
(https://www.openssh.com/releasenotes.html#9.8p1). As a result, libssh2
now fails to build with test failures, as follows:
make[6]: Entering directory '/<>/tests'
PASS: test_simple
PASS: mansyntax.sh
FAIL: test_sshd.test 1 - sshd-test_ssh2
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519
ERROR: test_sshd.test - exited with status 1
=
libssh2 -: tests/test-suite.log
=
# TOTAL: 5
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 1
.. contents:: :depth: 2
ERROR: test_sshd
/<>/tests/openssh_server/sshd_config line 2: Bad key types
'+ssh-rsa,ssh-dss,ssh-rsa-cert-...@openssh.com'.
Connection to 127.0.0.1:4711 attempt #0 failed: retrying...
Connection to 127.0.0.1:4711 attempt #1 failed: retrying...
Connection to 127.0.0.1:4711 attempt #2 failed: retrying...
Failure establishing SSH session: -43
Fingerprint: ./test_sshd.test: line 131: 2387220 Segmentation fault
"${test}"
Connection to 127.0.0.1:4711 attempt #0 failed: retrying...
Connection to 127.0.0.1:4711 attempt #1 failed: retrying...
Connection to 127.0.0.1:4711 attempt #2 failed: retrying...
Failed to connect to 127.0.0.1:4711
./test_sshd.test: line 1: kill: (2387095) - No such process
# sshd executable: '/usr/sbin/sshd' (OpenSSH_9.8p1 Debian)
# ssh executable: '/usr/bin/ssh' (OpenSSH_9.8p1 Debian-1, OpenSSL 3.2.2 4 Jun
2024)
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
# waiting for sshd...
1..2
not ok 1 - sshd-test_ssh2
FAIL: test_sshd.test 1 - sshd-test_ssh2
not ok 2 - sshd-test_auth_pubkey_ok_ed25519
FAIL: test_sshd.test 2 - sshd-test_auth_pubkey_ok_ed25519
ERROR: test_sshd.test - exited with status 1
Testsuite summary for libssh2 -
# TOTAL: 5
# PASS: 2
# SKIP: 0
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 1
See tests/test-suite.log
Please report to libssh2-de...@lists.haxx.se
make[6]: *** [Makefile:1241: test-suite.log] Error 1
https://github.com/libssh2/libssh2/commit/b7ab0faa70567a789419798fe079f5678ad4e156
seems to have been upstream's approach to this, so I suggest
cherry-picking that.
Thanks,
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1074669: marked as pending in python3-simpletal
Control: tag -1 pending Hello, Bug #1074669 in python3-simpletal 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/python3-simpletal/-/commit/953ba19a7b38919188dcca03758e3b0116dbab85 Use importlib rather than imp.load_source Closes: #1074669 (this message was generated automatically) -- Greetings https://bugs.debian.org/1074669
Bug#1077118: marked as pending in password-store
Control: tag -1 pending Hello, Bug #1077118 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/1746711e2b4d534c610ae5a3af59035a99eb72eb Rebuild against newer dh-elpa Closes: #1077118 (this message was generated automatically) -- Greetings https://bugs.debian.org/1077118
Bug#1074730: marked as pending in python-tenacity
Control: tag -1 pending Hello, Bug #1074730 in python-tenacity 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-tenacity/-/commit/501e253bcb6c17f00095cc29eb7a5c6f3d8b8339 Update upstream source from tag 'upstream/8.4.2+really8.4.1' Update to upstream version '8.4.2+really8.4.1' with Debian dir 674549fbc7ee0b71b8dca2270f5da185e6eea646 Closes: #1074690, #1074730 (this message was generated automatically) -- Greetings https://bugs.debian.org/1074730
Bug#1074690: marked as pending in python-tenacity
Control: tag -1 pending Hello, Bug #1074690 in python-tenacity 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-tenacity/-/commit/501e253bcb6c17f00095cc29eb7a5c6f3d8b8339 Update upstream source from tag 'upstream/8.4.2+really8.4.1' Update to upstream version '8.4.2+really8.4.1' with Debian dir 674549fbc7ee0b71b8dca2270f5da185e6eea646 Closes: #1074690, #1074730 (this message was generated automatically) -- Greetings https://bugs.debian.org/1074690
Bug#1076036: python3-setuptools: uninstallable in unstable
On Tue, Jul 09, 2024 at 07:57:51PM +0100, Colin Watson wrote:
> Following
> https://tracker.debian.org/news/1543129/accepted-python3-stdlib-extensions-3124-1-source-into-unstable/,
> python3-setuptools is uninstallable in unstable:
Indeed, setuptools Build-Depends: dh-python Depends: python3-setuptools,
so unstable's ability to build anything Python-related has been
completely botched and this should have been done in some other order.
I guess it can be fixed with a manual build of setuptools against an
older version of dh-python, although it will also be necessary to deal
with https://bugs.debian.org/1056198 ("src:setuptools: build depends on
dh-python but build conflicts with python3-setuptools").
--
Colin Watson (he/him) [cjwat...@debian.org]
Bug#1076036: python3-setuptools: uninstallable in unstable
Package: python3-setuptools Version: 68.1.2-2 Severity: grave Justification: renders package unusable Following https://tracker.debian.org/news/1543129/accepted-python3-stdlib-extensions-3124-1-source-into-unstable/, python3-setuptools is uninstallable in unstable: # apt install python3-setuptools Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Unsatisfied dependencies: python3-setuptools : Depends: python3-distutils but it is not installable Error: Unable to correct problems, you have held broken packages. # apt install python3-setuptools python3-distutils Package python3-distutils is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Error: Package 'python3-distutils' has no installation candidate This obviously seems likely to break builds of a large number of other packages - we noticed it in debusine's reprotest CI jobs. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1059658: jupyter-client autopkgtest situation
Control: block 1059658 by 1071879 Hi, I was looking at the RC bug https://bugs.debian.org/1059658, and I noticed that there've been unreleased commits in https://salsa.debian.org/python-team/packages/jupyter-client for months that seem to fix this. However, when I ran the autopkgtests for that version locally I found that they're a mess, with lots of repeats of this (trimmed for readability): jupyter_client/__init__.py:3: in from .asynchronous import AsyncKernelClient jupyter_client/asynchronous/__init__.py:1: in from .client import AsyncKernelClient # noqa jupyter_client/asynchronous/client.py:12: in from ..client import KernelClient, reqrep jupyter_client/client.py:20: in from .connect import ConnectionFileMixin jupyter_client/connect.py:22: in from jupyter_core.paths import jupyter_data_dir, jupyter_runtime_dir, secure_write /usr/lib/python3/dist-packages/jupyter_core/paths.py:208: in deprecation( /usr/lib/python3/dist-packages/jupyter_core/utils/__init__.py:90: in deprecation warnings.warn(message, DeprecationWarning, stacklevel=stacklevel + 1) E DeprecationWarning: Jupyter is migrating its paths to use standard platformdirs E given by the platformdirs library. To remove this warning and E see the appropriate new directories, set the environment variable E `JUPYTER_PLATFORM_DIRS=1` and then run `jupyter --paths`. E The use of platformdirs will be the default in `jupyter_core` v6 _internal = ['jupyter_core/'] internal = 'jupyter_core/' message= 'Jupyter is migrating its paths to use standard platformdirs\ngiven by the platformdirs library. To remove this warni...TER_PLATFORM_DIRS=1` and then run `jupyter --paths`.\nThe use of platformdirs will be the default in `jupyter_core` v6' stacklevel = 2 Now, tests/conftest.py does in fact set JUPYTER_PLATFORM_DIRS=1, so I think the problem is that the autopkgtests run "$py -m pytest jupyter_client" rather than just "$py -m pytest". But that has a different problem: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 865, in import_plugin __import__(importspec) ModuleNotFoundError: No module named 'pytest_jupyter' And: # apt install python3-pytest-jupyter Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: Unsatisfied dependencies: python3-pytest-jupyter : Depends: python3-jupyter-core (>= 5.7) but 5.3.2-2 is to be installed Error: Unable to correct problems, you have held broken packages. So I guess this is https://bugs.debian.org/1071879, and presumably the easiest way out would be to upgrade jupyter-core to a current upstream version. Any objections to me going ahead and doing that? I'm also a bit confused as to how it got this way. Julian must have been able to build pytest-jupyter in order to construct the upload in https://tracker.debian.org/news/1518227/accepted-pytest-jupyter-091-1-source-all-into-unstable/, but a sufficient version of jupyter-core wasn't in unstable then any more than it is now. Was this hacked up locally in some way? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1073381: git-build-recipe: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13
Control: reassign -1 python3-testtools 2.7.1-3 Control: affects -1 git-build-recipe Control: forwarded -1 https://github.com/testing-cabal/testtools/issues/372 On Sun, Jun 16, 2024 at 03:21:26PM +0200, Lucas Nussbaum wrote: > Source: git-build-recipe > Version: 0.3.7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240615 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > ERRORS > > > > _ ERROR collecting > > .pybuild/cpython3_3.11/build/gitbuildrecipe/tests/test_deb_version.py _ > > /usr/lib/python3/dist-packages/testtools/testcase.py:241: in __init__ > > test_method = self._get_test_method() > > /usr/lib/python3/dist-packages/testtools/testcase.py:696: in > > _get_test_method > > return getattr(self, method_name) > > E AttributeError: 'GitTestCase' object has no attribute 'runTest' This is https://github.com/testing-cabal/testtools/issues/372, and is fixed by testtools 2.7.2. Thomas, could we upgrade testtools to 2.7.2 in Debian, please? Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1057599: marked as pending in python-repoze.sphinx.autointerface
Control: tag -1 pending Hello, Bug #1057599 in python-repoze.sphinx.autointerface 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-repoze.sphinx.autointerface/-/commit/23fd649ca35193891d8b38294463fffc95cf9f0b Fix tests with Sphinx 7.2.x Closes: #1057599 (this message was generated automatically) -- Greetings https://bugs.debian.org/1057599
Bug#1073996: marked as pending in twisted
Control: tag -1 pending Hello, Bug #1073996 in twisted 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/twisted/-/commit/144b7904d2836e46877be780b57707cf3fed590b Patch: fix test_flatten in autopkgtest Closes: #1073996 (this message was generated automatically) -- Greetings https://bugs.debian.org/1073996
Bug#1069838: marked as pending in khard
Control: tag -1 pending Hello, Bug #1069838 in khard 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/khard/-/commit/03c0c75164f51cc49a85dec4d1917d71ba08052a Avoid circular imports Closes: #1069838 (this message was generated automatically) -- Greetings https://bugs.debian.org/1069838
Bug#1069838: khard: Builds fine here.
Control: forwarded -1 https://github.com/lucc/khard/pull/334 On Thu, Jun 20, 2024 at 12:06:27PM +0100, Colin Watson wrote: > On Thu, Jun 20, 2024 at 12:42:17PM +0200, Santiago Vila wrote: > > El 20/6/24 a las 10:13, Colin Watson escribió: > > > Santiago, is khard still failing to build for you? > > > > As of today (version 0.19.1-2 in unstable), yes, all the time. > > In that case I could use some help reproducing it, because > https://salsa.debian.org/python-team/packages/khard/-/pipelines and > https://buildd.debian.org/status/package.php?p=khard show no errors > either. (I know I didn't get very far when you gave me access to a > machine to debug gcr4, but I'm more optimistic about this one.) Thanks to Santiago for help. I've now reproduced this and sent a patch upstream; I'll apply it to the Debian package as well in a moment. I'm still mystified as to why I couldn't reproduce this locally, but oh well. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1069838: khard: Builds fine here.
On Thu, Jun 20, 2024 at 12:42:17PM +0200, Santiago Vila wrote: > El 20/6/24 a las 10:13, Colin Watson escribió: > > Santiago, is khard still failing to build for you? > > As of today (version 0.19.1-2 in unstable), yes, all the time. In that case I could use some help reproducing it, because https://salsa.debian.org/python-team/packages/khard/-/pipelines and https://buildd.debian.org/status/package.php?p=khard show no errors either. (I know I didn't get very far when you gave me access to a machine to debug gcr4, but I'm more optimistic about this one.) Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070112: marked as pending in ipykernel
Control: tag -1 pending Hello, Bug #1070112 in ipykernel 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/ipykernel/-/commit/09a2d18d16928cd5b4f1fdb07045efb1291ecbc6 Add compat with pytest 8 Closes: #1070112 (this message was generated automatically) -- Greetings https://bugs.debian.org/1070112
Bug#1069838: khard: Builds fine here.
On Sun, Jun 16, 2024 at 09:42:10PM +, Martin Dosch wrote: > I just built khard locally and it builds fine. I also can't reproduce this, and I wouldn't normally expect circular import issues to be semi-reproducible - in a given codebase they usually either fail or they don't. Santiago, is khard still failing to build for you? If so I'm happy to investigate further (I can see at least one approach that ought to help), but it's worth checking if the problem has gone away due to a change in some dependency or other. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1072780: src:transaction: fails to migrate to testing for too long: uploader built arch:all binary
Control: fixed -1 transaction/4.0-2 On Fri, Jun 07, 2024 at 09:39:20PM +0200, Paul Gevers wrote: > Your package is only blocked because the arch:all binary package(s) aren't > built on a buildd. Unfortunately the Debian infrastructure doesn't allow > arch:all packages to be properly binNMU'ed. Hence, I will shortly do a > no-changes source-only upload to DELAYED/15, closing this bug. Please let me > know if I should delay or cancel that upload. This was fixed by transaction 4.0-2, and it looks like either you cancelled your upload or it was automatically dropped from the DELAYED queue. transaction (4.0-2) unstable; urgency=medium * QA upload * Source-only reupload -- Bastian Germann Wed, 12 Jun 2024 20:49:57 + Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
Control: severity -1 important On Thu, May 16, 2024 at 12:10:41PM +, Dan Poltawski wrote: > Thanks for your response - I hadn't quite noticed that this was legacy grub > (and > had kinda made the assumption the Debian upgrades had forced the upgrade). > > I have migrated to GRUB 2 and can confirm this resolves the issue. OK, good. I tried reproducing this in a VM and couldn't; I suspect that it's something relatively subtle about the filesystem structure that doesn't happen to everyone. As such I'm downgrading this to just below release-critical, since on its own I don't think it quite justifies removing grub-legacy from testing. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1071893: marked as pending in ipywidgets
Control: tag -1 pending Hello, Bug #1071893 in ipywidgets 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/ipywidgets/-/commit/05c8043c28609207c5e24be1d255f036336a3a17 Fix compatibility with pytest 8 Closes: #1071893 (this message was generated automatically) -- Greetings https://bugs.debian.org/1071893
Bug#1066822: linuxtv-dvb-apps: diff for NMU version 1.1.1+rev1500-1.5
Control: tags 961967 + patch
Control: tags 961967 + pending
Control: tags 1066822 + patch
Control: tags 1066822 + pending
Dear maintainer,
I've prepared an NMU for linuxtv-dvb-apps (versioned as
1.1.1+rev1500-1.5) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.
I would have sent these as git merge requests of some form, but
Vcs-Git/Vcs-Browser are still set to the obsolete anonscm.debian.org and
I couldn't find any corresponding repositories on salsa, so this was the
best I could do; you should be able to find more detailed history via
"dgit clone linuxtv-dvb-apps" if you need it.
Regards,
--
Colin Watson (he/him) [cjwat...@debian.org]
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2020-07-26 19:42:38.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/changelog 2024-05-23 16:49:59.0 +0100
@@ -1,3 +1,11 @@
+linuxtv-dvb-apps (1.1.1+rev1500-1.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Work around UAPI break in Linux input events (Closes: #1066822).
+ * Set Architecture to linux-any (Closes: #961967).
+
+ -- Colin Watson Thu, 23 May 2024 16:49:59 +0100
+
linuxtv-dvb-apps (1.1.1+rev1500-1.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/control linuxtv-dvb-apps-1.1.1+rev1500/debian/control
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2016-04-07 17:11:50.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/control 2024-05-23 16:49:59.0 +0100
@@ -11,7 +11,7 @@
Homepage: http://www.linuxtv.org/wiki/index.php/LinuxTV_dvb-apps
Package: dvb-apps
-Architecture: any
+Architecture: linux-any
Depends:
${shlibs:Depends},
makedev | udev,
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2020-07-26 19:38:59.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/series 2024-05-23 16:49:59.0 +0100
@@ -11,3 +11,4 @@
dst_test-no-set-id.patch
glibc-stime.patch
gcc-10-sid-redefinition.patch
+work-around-uapi-break-in-linux-input-ev.patch
diff -Nru linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch
--- linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 1970-01-01 01:00:00.0 +0100
+++ linuxtv-dvb-apps-1.1.1+rev1500/debian/patches/work-around-uapi-break-in-linux-input-ev.patch 2024-05-23 16:49:59.0 +0100
@@ -0,0 +1,25 @@
+From: Colin Watson
+Date: Thu, 23 May 2024 16:38:37 +0100
+X-Dgit-Generated: 1.1.1+rev1500-1.5 5d2fca4cdce8ddcdf7e13a0681da7b381301
+Subject: Work around UAPI break in Linux input events
+
+See
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=152194fe9c3f.
+
+Closes: #1066822
+
+---
+
+diff --git a/test/evtest.c b/test/evtest.c
+index a61593e..73fb5af 100644
+--- a/test/evtest.c
b/test/evtest.c
+@@ -241,7 +241,7 @@ int main (int argc, char **argv)
+
+ for (i = 0; i < rd / (int) sizeof(struct input_event); i++)
+ printf("Event: time %ld.%06ld, type %d (%s), code %d (%s), value %d\n",
+-ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
++ev[i].input_event_sec, ev[i].input_event_usec, ev[i].type,
+ events[ev[i].type] ? events[ev[i].type] : "?",
+ ev[i].code,
+ names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? names[ev[i].type][ev[i].code] : "?") : "?",
Bug#1070733: linux-image-5.10.0-29-amd64 fails to boot with Error 16: Inconsistent filesystem structure
On Wed, May 08, 2024 at 06:31:53AM +0100, Dan Poltawski wrote: > After upgrading to linux-image-5.10.0-29 the system fails to boot with > grub 'Error 16: Inconsistent filesystem structure'. Booting into > linux-image-5.10.0-28-amd64 > and the system is once again bootable > > The console displays: > Booting 'Debian GNU/Linux, kernel 5.10.0-29-amd64' > root (hd0,0) > Filesystem type is ext2fs, partition type 0x83 > kernel /boot/vmlinuz-5.10.0-29-amd64 root=UUID=ca38e015-f8d1-4ef0-9dc9-b56d7c8 > le0f1 ro > [Linux-bzImage, setup=0x3c00, size=0x6b5f40] > Initrd /boot/initrd. img-5.10.0-29-amd64 > Error 16: Inconsistent filesystem structure > Press any key to continue...- If I find time I'll have a look at this (probably just by looking through GRUB 2 for candidate backports and hoping that one of them helps). However, I should warn you that GRUB Legacy is extremely very unmaintained at this point; I've really just been doing last-resort patching for years, and this normally hasn't included debugging its filesystem code. It'd be in your interests to migrate to GRUB 2. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1070403: marked as pending in openssh-ssh1
Control: tag -1 pending Hello, Bug #1070403 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/237920039b48da3992bd91a16a123e7a9d50e103 Handle OpenSSL >=3 ABI compatibility Closes: #1070403 (this message was generated automatically) -- Greetings https://bugs.debian.org/1070403
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]
