Bug#1059245: gdm3: GDM3 fails to start on Wayland, maybe due to org.freedesktop.systemd1 failing to activate
Package: gdm3 Version: 45.0.1-3 Followup-For: Bug #1059245 Dear Maintainer, I have just had the same bug happen on a different machine after an upgrade. See attached apt history for the differences in packages before/after the issue appeared. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? apt-get dist-upgrade * What exactly did you do (or not do) that was effective (or ineffective)? Forced Xorg, rather than Wayland (with WaylandEnable=true), but neither work, same as for the original issue. * What was the outcome of this action? GDM failed to start. * What outcome did you expect instead? GDM starts. *** End of the template - remove these template lines *** -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 23.13.9-6 ii adduser 3.137 ii dbus [default-dbus-system-bus]1.14.10-4 ii dbus-bin 1.14.10-4 ii dbus-daemon 1.14.10-4 ii dconf-cli 0.40.0-4+b1 ii dconf-gsettings-backend 0.40.0-4+b1 ii debconf [debconf-2.0] 1.5.86 ii gir1.2-gdm-1.045.0.1-3 ii gnome-session [x-session-manager] 45.0-2 ii gnome-session-bin 45.0-2 ii gnome-session-common 45.0-2 ii gnome-settings-daemon 46~beta-2 ii gnome-shell 44.9-1 ii gnome-terminal [x-terminal-emulator] 3.51.90-1 ii gsettings-desktop-schemas 46.0-1 ii libaccountsservice0 23.13.9-6 ii libaudit1 1:3.1.2-2 ii libc6 2.37-15 ii libcanberra-gtk3-00.30-11 ii libcanberra0 0.30-11 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libgdm1 45.0.1-3 ii libglib2.0-0 2.78.4-1 ii libglib2.0-bin2.78.4-1 ii libgtk-3-03.24.41-1 ii libgudev-1.0-0238-3 ii libkeyutils1 1.6.3-3 ii libpam-modules1.5.2-9.1+b1 ii libpam-runtime1.5.2-9.1 ii libpam-systemd [logind] 255.4-1 ii libpam0g 1.5.2-9.1+b1 ii librsvg2-common 2.54.7+dfsg-2 ii libselinux1 3.5-2 ii libsystemd0 255.4-1 ii libx11-6 2:1.8.7-1 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii mutter [x-window-manager] 44.8-3 ii polkitd 124-1 ii procps2:4.0.4-4 ii systemd-sysv 255.4-1 ii ucf 3.0043+nmu1 ii x11-common1:7.7+23 ii x11-xserver-utils 7.7+10 Versions of packages gdm3 recommends: ii at-spi2-core 2.50.0-1+b1 ii desktop-base 12.0.6+nmu1 ii gnome-session [x-session-manager] 45.0-2 ii x11-xkb-utils 7.7+8 ii xserver-xephyr 2:21.1.12-1 ii xserver-xorg 1:7.7+23 ii zenity 4.0.1-1 Versions of packages gdm3 suggests: pn libpam-fprintd ii libpam-gnome-keyring 42.1-1+b2 pn libpam-pkcs11 pn libpam-sss ii orca 46.1-1 -- Configuration Files: /etc/gdm3/daemon.conf changed: [daemon] WaylandEnable=false [security] [xdmcp] [chooser] [debug] Enable=true -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3 *** /home/shtrom/apt_history_gdm_issue.log Start-Date: 2024-04-20 20:59:25 Commandline: apt-get -y upgrade Requested-By: shtrom (1000) Upgrade: dpkg:amd64 (1.22.2, 1.22.4), fontconfig:amd64 (2.14.2-6, 2.15.0-1.1), libvulkan1:amd64 (1.3.268.0-1, 1.3.275.0-1), libvulkan1:i386 (1.3.268.0-1, 1.3.275.0-1), reportbug:amd64 (12.0.0, 13.0.1), libsvtav1enc1d1:amd64 (1.7.0+dfsg-2, 1.7.0+dfsg-2+b1), libsvtav1enc1d1:i386 (1.7.0+dfsg-2, 1.7.0+dfsg-2+b1), libbox2d2:amd64 (2.4.1-3, 2.4.1-3+b2), libgucharmap-2-90-7:amd64 (1:15.1.2-1, 1:15.1.2-1+b1), libsphinxbase3:amd64 (0.8+5prealpha+1-16+b1, 0.8+5prealpha+1-16+b2),
Bug#1069093: odbc-mariadb: Unknown system variable 'session_track_schema' error while using isql
Details on MySQL server with which issue was met are: Debian 7.2 mysql Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (x86_64) using readline 6.2
Bug#1069093: odbc-mariadb: Unknown system variable 'session_track_schema' error while using isql
Package: odbc-mariadb Version: 3.1.15-3 Severity: important X-Debbugs-Cc: oza.4...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? After Bullseye to Bookworm upgrade, ODBC connection with old MySQL/MariaDB cluster, ceased to work * What exactly did you do (or not do) that was effective (or ineffective)? $ isql -vvv foobar [S1000][unixODBC][ma-3.1.15]Unknown system variable ‘session_track_schema’ This bug seems to relate with [1] which can solved by 3.1.16 [1] https://jira.mariadb.org/browse/ODBC-362 At the same time, directly using mysql binary works OK. $ mysql -h foo -u bar -p mydb * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages odbc-mariadb depends on: ii libc6 2.36-9+deb12u4 ii libmariadb3 1:10.11.6-0+deb12u1 ii libodbcinst2 2.3.11-2+deb12u1 ii odbcinst 2.3.11-2+deb12u1 odbc-mariadb recommends no packages. odbc-mariadb suggests no packages. -- no debconf information
Bug#1067665: cvise 2.10.0-1 still build-depends on python-pytest-flake8 (broken with recent flake8)
Package: cvise Version: 2.10.0-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, In version 2.10.0, upstream dropped the dependency on pytest-flake8 because it is no longer maintained [1] and broken with modern flake8. However, in 2.10.0-1 in Debian, the build dependency on python3-pytest-flake8 is still present, albeit unused during the build process. This is preventing removal of python-pytest-flake8. In Ubuntu, the attached patch was applied to achieve the following: * Drop dependency on python-pytest-flake8 (broken with modern flake8) which was already dropped upstream in cvise 2.10 and is now unused (LP: #2058917) Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru cvise-2.10.0/debian/control cvise-2.10.0/debian/control --- cvise-2.10.0/debian/control 2024-03-12 16:49:12.0 +0100 +++ cvise-2.10.0/debian/control 2024-03-25 10:45:07.0 +0100 @@ -13,7 +13,6 @@ python3-pebble, python3-psutil, python3-pytest , - python3-pytest-flake8 , llvm-18-dev, libclang-18-dev, clang-18, clang-format-18, # clang-tools-18, clang-tidy-18, clangd-18, unifdef,
Bug#1067466: black autopkgtest fails because python3-typed-ast no longer in archive
Package: black Version: 24.2.0-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, Since the removal of python3-typed-ast from the archive [1], black cannot install its test dependencies anymore and therefore fails autopkg tests. https://tracker.debian.org/news/1469662/python3-typed-ast-removed-from-testing/ The AST library is provided by the Python standard library since Python 3.8 so the dependency has been unused for some time and can be safely dropped. In src:black 22.10.0-2, the dependency on python3-typed-ast was dropped from d/control but not from d/test/control: https://metadata.ftp-master.debian.org/changelogs//main/b/black/black_24.2.0-1_changelog In Ubuntu, the attached patch was applied to achieve the following: * d/test/control: drop unused dependency on python3-typed-ast, which was dropped from the archive. (LP: #2058692) Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers noble APT policy: (500, 'noble') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru black-24.2.0/debian/tests/control black-24.2.0/debian/tests/control --- black-24.2.0/debian/tests/control 2024-02-15 10:47:43.0 +0100 +++ black-24.2.0/debian/tests/control 2024-03-21 23:04:40.0 +0100 @@ -9,7 +9,6 @@ python3-pytest, python3-pathspec, python3-regex, - python3-typed-ast, python3-aiohttp, python3-tomli, python3-mypy-extensions,
Bug#1067168: urwid raises when rendering an empty Pile or Columns as a flow widget
Package: urwid
Version: 2.6.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
With the version of urwid 2.6.4-1 currently in trixie, the following
code fails with an exception:
```python
from urwid import Pile
Pile([
("pack", Pile([])),
]).render((10,))
```
File "/usr/lib/python3/dist-packages/urwid/widget/widget.py", line 112, in
cached_render
canv = fn(self, size, focus=focus)
^^^
File "/usr/lib/python3/dist-packages/urwid/widget/pile.py", line 822, in
render
_widths, heights, size_args = self.get_rows_sizes(size, focus)
File "/usr/lib/python3/dist-packages/urwid/widget/pile.py", line 730, in
get_rows_sizes
heights.append(w.pack(w_h_arg, item_focus)[1])
^^^
File "/usr/lib/python3/dist-packages/urwid/widget/pile.py", line 744, in pack
return super().pack(size, focus)
^
File "/usr/lib/python3/dist-packages/urwid/widget/widget.py", line 401, in
pack
raise WidgetError(f"Cannot pack (maxcol,) size, this is not a flow widget:
{self!r}")
urwid.widget.widget.WidgetError: Cannot pack (maxcol,) size, this is not a flow
widget:
The same code used to work with urwid 2.1.2-4 in bookworm.
I applied a fix from upstream [1] that was included in urwid 2.6.5. I
think the proper way forward would be to take a more recent upstream
version of urwid. That said, we are in feature freeze downstream in
Ubuntu so I skipped the refactoring bits.
In Ubuntu, the attached patch was applied to achieve the following:
* Apply upstream patch to fix a crash when rendering an empty Pile or an
empty Columns as a flow widget. (LP: #2058388)
+ d/patches/fix-crash-empty-pile.patch
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers noble
APT policy: (500, 'noble'), (100, 'noble-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.8.0-11-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
[1]
https://github.com/urwid/urwid/commit/83c278b53de431a9b41d7ddadf5f318914246593
diff -Nru urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch
urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch
--- urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch 1970-01-01
01:00:00.0 +0100
+++ urwid-2.6.4/debian/patches/fix-crash-empty-pile.patch 2024-03-19
14:23:31.0 +0100
@@ -0,0 +1,158 @@
+Description: Fix crash when rendering empty Pile or Columns as a flow widget
+ Special case: in case of `Columns`/`Pile` empty - use fallback sizing (#843)
+ .
+ * Extend `repr` to provide brief info about contents
+ .
+Author: Aleksei Stepanov
+Origin: upstream,
https://github.com/urwid/urwid/commit/83c278b53de431a9b41d7ddadf5f318914246593
+Bug-Ubuntu: https://launchpad.net/bugs/2058388
+Last-Update: 2024-03-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/urwid/widget/columns.py b/urwid/widget/columns.py
+index e3fa134..5a3421f 100644
+--- a/urwid/widget/columns.py
b/urwid/widget/columns.py
+@@ -66,40 +66,47 @@ class Columns(Widget, WidgetContainerMixin,
WidgetContainerListContentsMixin):
+
+ # BOX-only widget
+ >>> Columns((SolidFill("#"),))
+-
++
+
+ # BOX-only widget with "get height from max"
+ >>> Columns((SolidFill("#"),), box_columns=(0,))
+-
++
+
+ # FLOW-only
+ >>> Columns((Edit(),))
+-
++
+
+ # FLOW allowed by "box_columns"
+ >>> Columns((Edit(), SolidFill("#")), box_columns=(1,))
+-
++
+
+ # FLOW/FIXED
+ >>> Columns((Text("T"),))
+-
++
+
+ # GIVEN BOX only -> BOX only
+ >>> Columns(((5, SolidFill("#")),), box_columns=(0,))
+-
++
+
+ # No FLOW - BOX only
+ >>> Columns(((5, SolidFill("#")), SolidFill("*")), box_columns=(0, 1))
+-
++
+
+ # FIXED only -> FIXED
+ >>> Columns(((WHSettings.PACK, BigText("1", font)),))
+-
++
+
+ # Invalid sizing combination -> use fallback settings (and produce
warning)
+ >>> Columns(((WHSettings.PACK, SolidFill("#")),))
+-
++
++
++# Special case: empty columns widget sizing is impossible to calculate
++>>> Columns(())
++
+ """
++if not self.contents:
++return frozenset((urwid.BOX, urwid.FLOW))
++
+ strict_box = False
+ has_flow = False
+
+@@ -280,6 +287,13 @@ class
Bug#1058392: python-oauth2client: FTBFS: failed tests
Package: python-oauth2client
Followup-For: Bug #1058392
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
Python 3.12 dropped support in unittest.TestCase for assertRaisesRegexp and
assertEquals. These two functions were provided as a compability layer
since their deprecation in Python 3.2.
In Ubuntu, the attached patch was applied to achieve the following:
* Replace obsolete assert* calls (dropped from Python 3.12) with their
correct alternative to fix FTBFS.
- debian/patches/python312-support.patch
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500,
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-oauth2client-4.1.3/debian/patches/python312-support.patch
python-oauth2client-4.1.3/debian/patches/python312-support.patch
--- python-oauth2client-4.1.3/debian/patches/python312-support.patch
1970-01-01 01:00:00.0 +0100
+++ python-oauth2client-4.1.3/debian/patches/python312-support.patch
2024-02-16 10:51:37.0 +0100
@@ -0,0 +1,252 @@
+Description: Fix use of obsolete assert statements dropped in Python 3.12
+ Since Python 3.2, assertEquals and assertRaisesRegexp (+ others) have been
+ deprecated in favor of assertEqual and assertRaisesRegex.
+ In Python 3.12, the deprecated names got dropped, causing oauth2client to
+ FTBFS.
+ .
+ The patch is not meant for upstream inclusion since the project upstream is
+ deprecated (in favor of python-google-auth) and the repository is read only.
+Author: Olivier Gayot
+Bug-Debian: https://bugs.debian.org/1058392
+Forwarded: not-needed
+Last-Update: 2024-02-16
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/contrib/appengine/test_appengine.py
b/tests/contrib/appengine/test_appengine.py
+@@ -906,7 +906,7 @@
+ self.decorator = decorator
+ self.test_required()
+ http = self.decorator.http()
+-self.assertEquals('foo_access_token',
++self.assertEqual('foo_access_token',
+ http.request.credentials.access_token)
+
+ # revoke_uri is not required
+--- a/tests/contrib/test_devshell.py
b/tests/contrib/test_devshell.py
+@@ -205,7 +205,7 @@
+ def test_no_refresh_token(self):
+ with _AuthReferenceServer():
+ creds = devshell.DevshellCredentials()
+-self.assertEquals(None, creds.refresh_token)
++self.assertIsNone(creds.refresh_token)
+
+ @mock.patch('oauth2client.client._UTCNOW')
+ def test_reads_credentials(self, utcnow):
+--- a/tests/contrib/test_keyring_storage.py
b/tests/contrib/test_keyring_storage.py
+@@ -104,7 +104,7 @@
+autospec=True) as get_password:
+ store = keyring_storage.Storage('my_unit_test', 'me')
+ credentials = store.get()
+-self.assertEquals(None, credentials)
++self.assertIsNone(credentials)
+ get_password.assert_called_once_with('my_unit_test', 'me')
+
+ def test_get_with_malformed_json_credentials_stored(self):
+@@ -113,7 +113,7 @@
+autospec=True) as get_password:
+ store = keyring_storage.Storage('my_unit_test', 'me')
+ credentials = store.get()
+-self.assertEquals(None, credentials)
++self.assertIsNone(credentials)
+ get_password.assert_called_once_with('my_unit_test', 'me')
+
+ def test_get_and_set_with_json_credentials_stored(self):
+@@ -139,7 +139,7 @@
+return_value=None,
+autospec=True) as set_password:
+ store = keyring_storage.Storage('my_unit_test', 'me')
+-self.assertEquals(None, store.get())
++self.assertIsNone(store.get())
+
+ store.put(credentials)
+
+--- a/tests/test_client.py
b/tests/test_client.py
+@@ -436,7 +436,7 @@
+ 'File {0} \(pointed by {1} environment variable\) does not '
+ 'exist!'.format(
+ nonexistent_file, client.GOOGLE_APPLICATION_CREDENTIALS))
+-with
self.assertRaisesRegexp(client.ApplicationDefaultCredentialsError,
++with self.assertRaisesRegex(client.ApplicationDefaultCredentialsError,
+ expected_err_msg):
+ client._get_environment_variable_file()
+
+@@ -541,7 +541,7 @@
+ "'{1}' values\)&qu
Bug#1063782: python-oauth2client: FTBFS with flask 3
Package: python-oauth2client Followup-For: Bug #1063782 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Control: tags -1 patch Dear Maintainer, Flask 3.0 dropped support for _app_ctx_stack and _request_ctx_stack. Those attributes were deprecated since Flask 2.2. In Ubuntu, the attached patch was applied to achieve the following: * Replace use of flask._app_ctx_stack (dropped from flask 3) by flask.g to fix FTBFS. (LP: #2052771) - debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch --- python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch 1970-01-01 01:00:00.0 +0100 +++ python-oauth2client-4.1.3/debian/patches/flask3-use-g-instead-of-app_ctx_stack.patch 2024-02-16 10:51:37.0 +0100 @@ -0,0 +1,43 @@ +Description: Use flask.g instead of flask._app_ctx_stack + In flask 2.2, _app_ctx_stack and _request_ctx_stack got deprecated in favor of + using flask.g. The compatibility layer was dropped from flask 3, which now raises: + E ImportError: cannot import name '_app_ctx_stack' from 'flask' + Replaced by the use of flask.g as mentioned in the documentation. + . + The patch is not meant for upstream inclusion since the project upstream is + deprecated (in favor of python-google-auth) and the repository is read only. +Author: Olivier Gayot +Bug-Ubuntu: https://launchpad.net/bugs/2052771 +Bug-Debian: https://bugs.debian.org/1063782 +Forwarded: not-needed +Last-Update: 2024-02-16 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/oauth2client/contrib/flask_util.py b/oauth2client/contrib/flask_util.py +@@ -170,8 +170,8 @@ + + try: + from flask import Blueprint +-from flask import _app_ctx_stack + from flask import current_app ++from flask import g as flask_g + from flask import redirect + from flask import request + from flask import session +@@ -434,12 +434,10 @@ + @property + def credentials(self): + """The credentials for the current user or None if unavailable.""" +-ctx = _app_ctx_stack.top ++if not hasattr(flask_g, _CREDENTIALS_KEY): ++flask_g.google_oauth2_credentials = self.storage.get() + +-if not hasattr(ctx, _CREDENTIALS_KEY): +-ctx.google_oauth2_credentials = self.storage.get() +- +-return ctx.google_oauth2_credentials ++return flask_g.google_oauth2_credentials + + def has_credentials(self): + """Returns True if there are valid credentials for the current user.""" diff -Nru python-oauth2client-4.1.3/debian/patches/series python-oauth2client-4.1.3/debian/patches/series --- python-oauth2client-4.1.3/debian/patches/series 2023-08-17 18:22:35.0 +0200 +++ python-oauth2client-4.1.3/debian/patches/series 2024-02-16 10:51:37.0 +0100 @@ -1,3 +1,5 @@ +flask3-use-g-instead-of-app_ctx_stack.patch skip-network-doing-unit-test.patch remove-broken-tests.patch fix-hmac.new-call-in-py3.8.patch
Bug#1064017: python-requests-unixsocket: Please run python-requests-unixsocket test-suite as part of autopkgtest
Package: python-requests-unixsocket Severity: wishlist Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, The recent migration of urllib3 and src:requests broke python-requests-unixsocket (see bug 1063892 [1]). This could have been easily noticed if request_unisocket's test-suite had run as an autopkg test. python-requests-unixsocket does not use pybuild so I came up with a small d/t/control + d/t/python3-requests-unixsocket to make the test-suite run during autopkgtest execution. In Ubuntu, the attached patch was applied to achieve the following: * Execute test-suite as part of autopkgtest (LP: #2053267) Thanks for considering the patch. [1] https://bugs.debian.org/1063892 -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru python-requests-unixsocket-0.3.0/debian/tests/control python-requests-unixsocket-0.3.0/debian/tests/control --- python-requests-unixsocket-0.3.0/debian/tests/control 1970-01-01 01:00:00.0 +0100 +++ python-requests-unixsocket-0.3.0/debian/tests/control 2024-02-15 19:59:04.0 +0100 @@ -0,0 +1,2 @@ +Tests: python3-requests-unixsocket +Depends: @, @builddeps@ diff -Nru python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket --- python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket 1970-01-01 01:00:00.0 +0100 +++ python-requests-unixsocket-0.3.0/debian/tests/python3-requests-unixsocket 2024-02-15 19:59:02.0 +0100 @@ -0,0 +1,13 @@ +#!/bin/bash + +set -efu + +python3_all="$(py3versions -s 2>/dev/null)" + +cp -r requests_unixsocket/tests "$AUTOPKGTEST_TMP/" +cd "$AUTOPKGTEST_TMP" + +for py in $python3_all; do +echo "=== $py ===" +$py -m pytest --verbose 2>&1 +done
Bug#1063892: python-requests-unixsocket: HTTPConnection.request() got an unexpected keyword argument 'chunked' with requests 2.29+
Package: python-requests-unixsocket
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
When using python-requests-unixsocket 0.3.0-3 against requests 2.29+
(currently 2.31.0+dfsg-1 is in testing), the following code produces an
exception:
```python3
import requests_unixsocket
with requests_unixsocket.Session() as session:
session.get('http+unix://%2Ftmp/')
```
TypeError: HTTPConnection.request() got an unexpected keyword argument
'chunked'
There is a bug upstream [1] for it. And I think the regression was
introduced by PR 6226 [2] in the underlying library (requests).
I applied a patch that was proposed upstream but not yet merged.
In Ubuntu, the attached patch was applied to achieve the following:
* Fix incompatibility with requests 2.29 (LP: #2053016).
- d/p/0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
Thanks for considering the patch.
[1] https://github.com/msabramo/requests-unixsocket/issues/70
[2] https://github.com/psf/requests/pull/6226
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500,
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
python-requests-unixsocket-0.3.0/debian/patches/0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
python-requests-unixsocket-0.3.0/debian/patches/0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
---
python-requests-unixsocket-0.3.0/debian/patches/0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
1970-01-01 01:00:00.0 +0100
+++
python-requests-unixsocket-0.3.0/debian/patches/0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
2024-02-14 11:16:52.0 +0100
@@ -0,0 +1,47 @@
+Description: Inherit HTTPConnection through urllib3.connection, not httplib
+ By inheriting from `urllib3.connection.HTTPConnection` (that inherits
+ from `httplib.HTTPConnection` itself), we can adapt to the internal
+ changes in urllib3 2.0 that added a `request()` method that is
+ incompatible with httplib.HTTPConnection.request.
+ .
+ This fixes the incompatibility between urllib3 2.0 and requests 1.26+,
+ which was the first version that stopped vendoring urllib3.
+ .
+ Reference:
https://github.com/docker/docker-py/issues/3113#issuecomment-1531570788
+ Fixes: #70
+Author: Martin Roukala
+Origin: upstream, https://github.com/msabramo/requests-unixsocket/pull/69
+Bug: https://github.com/msabramo/requests-unixsocket/issues/70
+Bug-Ubuntu: https://launchpad.net/bugs/2053016
+Applied-Upstream: no
+Last-Update: 2024-02-14
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/requests_unixsocket/adapters.py b/requests_unixsocket/adapters.py
+index 83e1400..513c243 100644
+--- a/requests_unixsocket/adapters.py
b/requests_unixsocket/adapters.py
+@@ -3,11 +3,6 @@ import socket
+ from requests.adapters import HTTPAdapter
+ from requests.compat import urlparse, unquote
+
+-try:
+-import http.client as httplib
+-except ImportError:
+-import httplib
+-
+ try:
+ from requests.packages import urllib3
+ except ImportError:
+@@ -16,7 +11,7 @@ except ImportError:
+
+ # The following was adapted from some code from docker-py
+ # https://github.com/docker/docker-py/blob/master/docker/transport/unixconn.py
+-class UnixHTTPConnection(httplib.HTTPConnection, object):
++class UnixHTTPConnection(urllib3.connection.HTTPConnection, object):
+
+ def __init__(self, unix_socket_url, timeout=60):
+ """Create an HTTP connection to a unix domain socket
+--
+2.40.1
+
diff -Nru python-requests-unixsocket-0.3.0/debian/patches/series
python-requests-unixsocket-0.3.0/debian/patches/series
--- python-requests-unixsocket-0.3.0/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ python-requests-unixsocket-0.3.0/debian/patches/series 2024-02-14
11:12:51.0 +0100
@@ -0,0 +1 @@
+0001-Inherit-HTTPConnection-through-urllib3.connection-no.patch
Bug#1063782: python-oauth2client: FTBFS with flask 3
Source: python-oauth2client Severity: important Dear Maintainer, Building (or running autopkgtest) for python-oauth2client against flask 3.0 leads to an error when running the test-suite: Traceback: oauth2client/contrib/flask_util.py:173: in from flask import _app_ctx_stack E ImportError: cannot import name '_app_ctx_stack' from 'flask' (/usr/lib/python3/dist-packages/flask/__init__.py) With previous versions of flask, the same code would produce a warning instead: oauth2client/contrib/flask_util.py:173: DeprecationWarning: '_app_ctx_stack' is deprecated and will be removed in Flask 2.3. Flask decided to remove the deprecated _app_ctx_stack [1] in 3.0.0. The recommended approach is to "use 'g' to store data instead." Quote from Version 2.2.0 changelog [2]: > The app and request contexts are managed using Python context vars directly > rather than Werkzeug’s LocalStack. This should result in better performance > and memory use. #4682 > > Extension maintainers, be aware that _app_ctx_stack.top and > _request_ctx_stack.top are deprecated. Store data on g instead using a unique > prefix, like g._extension_name_attr. > Nowadays oauth2client is marked deprecated [3] and the upstream repository [4] has been read only for four years. NOTE: When building with python3.12, there are other errors but they have already been reported as part of bug 1058392 [5] Thank you [1] https://github.com/pallets/flask/pull/5223 [2] https://flask.palletsprojects.com/en/2.3.x/changes/#version-2-2-0 [3] https://google-auth.readthedocs.io/en/latest/oauth2client-deprecation.html [4] https://github.com/googleapis/oauth2client [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058392 -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic'), (100, 'mantic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1061240: bugs.debian.org: ALSA don't recognize Mackie ProFxV3 USB sound cards since 5.10 linux kernel
Package: bugs.debian.org Severity: important Tags: upstream Hi, The Mackie ProFX16 is a mixer with a 2x4 USB interface. When I plug it on my computer, kern.log reports : --8<- Jan 4 13:07:22 studio kernel: [ 649.029717] usb 1-1.3: new high-speed USB device number 4 using ehci-pci Jan 4 13:07:22 studio kernel: [ 649.108708] usb 1-1.3: New USB device found, idVendor=0a73, idProduct=0023, bcdDevice= 6.f2 Jan 4 13:07:22 studio kernel: [ 649.108715] usb 1-1.3: New USB device strings: Mfr=1, Product=3, SerialNumber=0 Jan 4 13:07:22 studio kernel: [ 649.108718] usb 1-1.3: Product: ProFx Jan 4 13:07:22 studio kernel: [ 649.108721] usb 1-1.3: Manufacturer: LOUD Technologies Inc. Jan 4 13:07:22 studio kernel: [ 649.109785] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32) Jan 4 13:07:22 studio kernel: [ 649.111946] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32) Jan 4 13:07:22 studio kernel: [ 649.113822] usb 1-1.3: parse_audio_format_rates_v2v3(): unable to find clock source (clock -32) -->8- I can't get no sound from the card, neither can I play anything to it. I did'nt find any information regarding this -32 error code. The alsa-info output is available at http://alsa- project.org/db/?f=c58140b0af84b98de7b97959cf5b48d94c64787c and the lsusb is attached bellow. If I change the kernel with a 4.19 or a 5.4 one, it works fine. I encountered this bug whith any post 5.4 kernel I tried, even 6 ones. The alsa-info output from a 5.4 custom kernel (from Librazik project) is available here: http://alsa- project.org/db/?f=9c94425e5b696704d956955714aaf94fb2ee8fc6 I've tried genuine debian kernel also and notice no differences regarding this bug compared to the Librazik custom kernel.
Bug#1059245: gdm3: GDM3 fails to start on Wayland, maybe due to org.freedesktop.systemd1 failing to activate
Package: gdm3 Version: 45.0.1-2 Followup-For: Bug #1059245 Thanks for the reply, Simon. I have done some more investigation, comparing to a freshly installed VM, and see this difference in the debug logs of gdm-wayland-session, which seems to be what misbehaves in my previous logs. $ sudo journalctl -t gdm-wayland-session Dec 26 14:01:56 desktop gdm-wayland-session[1469]: Gdm: Enabling debugging Dec 26 14:01:56 desktop gdm-wayland-session[1469]: Gdm: Running session message bus Dec 26 14:01:56 desktop gdm-wayland-session[1469]: GLib: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead Dec 26 14:01:56 desktop gdm-wayland-session[1469]: GLib: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead Dec 26 14:01:56 desktop gdm-wayland-session[1469]: Gdm: could not fetch environment: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1 Dec 26 14:01:56 desktop gdm-wayland-session[1469]: Gdm: Running wayland session Dec 26 14:01:56 desktop gdm-wayland-session[1469]: GLib: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead Dec 26 14:01:56 desktop gdm-wayland-session[1469]: GLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3) Dec 26 14:01:56 desktop gdm-wayland-session[1469]: Gdm: Could not register display: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Aucun affichage disponible This compared to a healthier test VM $ sudo journalctl -t gdm-wayland-session Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: Gdm: Enabling debugging Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: Gdm: Running session message bus Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: GLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3) Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: Gdm: session message bus already running, not starting another one Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: Gdm: Running wayland session Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: GLib-GIO: Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3) Dec 26 07:29:00 test-vm gdm-wayland-session[2232]: Gdm: gdm-wayland-session: Session will register itself So the error seems to be that “Aucun affichange disponible” (No display available), so this would confirm the permission issue somewhere. I indeed can't see a running Xwayland on the impacted system. -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=en_AU (charmap=UTF-8) (ignored: LC_ALL set to en_AU.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 gdm3 depends on: ii accountsservice 22.08.8-6 ii adduser 3.134 ii dbus [default-dbus-system-bus]1.14.10-1~deb12u1 ii dbus-bin 1.14.10-1~deb12u1 ii dbus-daemon 1.14.10-1~deb12u1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.045.0.1-2 ii gnome-session [x-session-manager] 43.0-1+deb12u1 ii gnome-session-bin 43.0-1+deb12u1 ii gnome-session-common 43.0-1+deb12u1 ii gnome-settings-daemon 43.0-4 ii gnome-shell 43.9-0+deb12u1 ii gnome-terminal [x-terminal-emulator] 3.46.8-1 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-6 ii libaudit1 1:3.0.9-1 ii libc6 2.36-9+deb12u3 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45.0.1-2 ii libglib2.0-0 2.78.3-1 ii libglib2.0-bin2.78.3-1 ii libgtk-3-03.24.38-2~deb12u1 ii libgudev-1.0-0237-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-6+deb12u1 ii libpam-runtime1.5.2-6+deb12u1 ii libpam-systemd [logind] 252.19-1~deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii libselinux1 3.4-1+b6 ii libsystemd0
Bug#1059245: gdm3: GDM3 fails to start on Wayland, maybe due to org.freedesktop.systemd1 failing to activate
Package: gdm3 Version: 45.0.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, GDM3 doesn't seem to be able to start a Wayland session (nor a fallback Xorg session, but I'm less concerned about this, and this seems to be a separate permission issue). This seems to be related to org.freedesktop.systemd1 failing to activate (and triggering the fallback to Xorg). The smoking gun implicating org.freedesktop.systemd1 is déc. 22 03:17:17 desktop gdm-launch-environment][28769]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm(uid=113) by (uid=0) déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28792]: dbus-daemon[28792]: [session uid=113 pid=28792] Activating service name='org.freedesktop.systemd1' requested by ':1.0' (uid=113 pid=28785 comm="/usr/libexec/gdm-wayland-session dbus-run-session ") déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28792]: dbus-daemon[28792]: [session uid=113 pid=28792] Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 déc. 22 03:17:17 desktop /usr/libexec/gdm-wayland-session[28785]: Unable to register display with display manager déc. 22 03:17:17 desktop gdm-launch-environment][28769]: pam_unix(gdm-launch-environment:session): session closed for user Debian-gdm *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Rebooting the machine after a long uptime and some updates. This was with gdm3-43 on bookworm; the same is observed after installing gdm3-45 from testing. libgdm1:amd64 (43.0-3) was updated on 2023-10-10 via unattended upgrades, but the system successfully rebooted a few times since then. * What exactly did you do (or not do) that was effective (or ineffective)? * Re-rebooting the machine. * Making sure that the the system was not in degraded mode according to systemd (systemctl stop and systemctl reset-failed). * Configuring the Wi-Fi network with nmcli (in addition to pre-existing functional ethernet connectivity, just in case some network dependency blocked the org.freedesktop.systemd1 activatio) * Installing gdm3-45 from testing * What was the outcome of this action? Nothing fixed the issue. * What outcome did you expect instead? Getting a graphical login prompt. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (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 gdm3 depends on: ii accountsservice 22.08.8-6 ii adduser 3.134 ii dbus [default-dbus-system-bus]1.14.10-1~deb12u1 ii dbus-bin 1.14.10-1~deb12u1 ii dbus-daemon 1.14.10-1~deb12u1 ii dconf-cli 0.40.0-4 ii dconf-gsettings-backend 0.40.0-4 ii debconf [debconf-2.0] 1.5.82 ii gir1.2-gdm-1.045.0.1-1 ii gnome-session [x-session-manager] 43.0-1+deb12u1 ii gnome-session-bin 43.0-1+deb12u1 ii gnome-session-common 43.0-1+deb12u1 ii gnome-settings-daemon 43.0-4 ii gnome-shell 43.9-0+deb12u1 ii gnome-terminal [x-terminal-emulator] 3.46.8-1 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-6 ii libaudit1 1:3.0.9-1 ii libc6 2.36-9+deb12u3 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgdm1 45.0.1-1 ii libglib2.0-0 2.78.3-1 ii libglib2.0-bin2.78.3-1 ii libgtk-3-03.24.38-2~deb12u1 ii libgudev-1.0-0237-2 ii libkeyutils1 1.6.3-2 ii libpam-modules1.5.2-6+deb12u1 ii libpam-runtime1.5.2-6+deb12u1 ii libpam-systemd [logind] 252.19-1~deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii libselinux1 3.4-1+b6 ii libsystemd0 252.19-1~deb12u1 ii libx11-6 2:1.8.4-2+deb12u2 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6
Bug#1057967: Fixed - Was: Re: Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable
Le Mon, Dec 11, 2023 at 02:55:50AM +0100, Kevin Price a écrit : > When booting 6.1.0-15, my physical amd64/bookworm/gnome computer > misbehaves in many ways, rendering it largely unusable. With kernels up > to 6.1.0-13, and even briefly with the otherwise broken 6.1.0-14, all of > this seemed fine. > FWIW, I experienced the same kind of behaviour, linked to a broken wifi with rtl88x2bu DKMS driver. Fixed now with: linux-image-6.1.0-16-amd64-unsigned 6.1.67-1 $ uname -a Linux pcpapa 6.1.0-16-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) x86_64 GNU/Linux Thanks a lot. Best regards, -- Olivier BERGER (OpenPGP: 4096R/7C5BB6A5) http://www.olivierberger.com/weblog/
Bug#1054172: nextcloud-desktop: Header of main window displays black zone without widgets (XFCE)
forwarded 1054172 https://github.com/nextcloud/desktop/issues/6066 thanks Indeed, this seems to be upstream, and not limited to a GNU/Linux implementation. Thanks for your help. Best regards, Hefee writes: > Control: tags -1 +upstream > > Hey, > > That is not a packaging issue on Debian side, this is an upstream one. Search > for a corresponding this issue or report a new one: > https://github.com/nextcloud/desktop/issues > > Please report back the url of the upstream bugreport, so we can link this > issue to the upstream bug report. > > Regards, > > hefee > > On Sonntag, 10. Dezember 2023 17:22:37 CET you wrote: >> Le Wed, Oct 18, 2023 at 05:52:42PM +0200, Olivier Berger a écrit : >> > I'm running Nextcloud-Desktop on XFCE, and just noticed that a recent >> > update of my testing system caused the main dialog to display weirdly. >> > >> > The zone which usually contains a dropbox allowing to switch the current >> > account is display as a fully black zone (see attached screenshot). >> > >> > Ths makes it quite difficult to use. >> >> Responding to myself, I figured out that this may be related to the >> configuration of the Nextcloud server, which displays its Web interface >> with a dark theme. >> >> When configuring another Nextcloud server in the same Desktop instance, I >> can switch to the view of the other server's sync, and then it is displayed >> with a different color (as the new server's display theme is different. See >> attached screenshot. >> >> Unfortunately I'm not able to configure the initial server's Web display >> preferences. >> >> Hope this helps, > -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1054172: nextcloud-desktop: Header of main window displays black zone without widgets (XFCE)
Le Wed, Oct 18, 2023 at 05:52:42PM +0200, Olivier Berger a écrit : > I'm running Nextcloud-Desktop on XFCE, and just noticed that a recent update > of my testing system caused the main dialog to display weirdly. > > The zone which usually contains a dropbox allowing to switch the current > account is display as a fully black zone (see attached screenshot). > > Ths makes it quite difficult to use. > Responding to myself, I figured out that this may be related to the configuration of the Nextcloud server, which displays its Web interface with a dark theme. When configuring another Nextcloud server in the same Desktop instance, I can switch to the view of the other server's sync, and then it is displayed with a different color (as the new server's display theme is different. See attached screenshot. Unfortunately I'm not able to configure the initial server's Web display preferences. Hope this helps, -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1057913: powerline: Changes bash prompt to two 'theme_kwargs' lines
Package: powerline Version: 2.8.3-4 Severity: normal Dear Maintainer, I've recently stumbled upon my bash prompts being rendered as : 'theme_kwargs' 'theme_kwargs' I'm enabling powerline through the following in .bashrc: . /usr/share/powerline/bindings/bash/powerline.sh Thnaks in advance. Hope this helps, -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages powerline depends on: ii debconf [debconf-2.0] 1.5.82 ii init-system-helpers1.66 ii libc6 2.37-12 ii python33.11.4-5+b1 ii python3-powerline 2.8.3-4 Versions of packages powerline recommends: ii fonts-powerline 2.8.3-4 Versions of packages powerline suggests: pn powerline-doc pn python3-i3ipc pn vim-addon-manager -- debconf-show failed -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1057530: nvme-stas: autopkgtest fail when runners have esoteric network interfaces
Package: nvme-stas Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, When an autopkgtest runner has esoteric network interfaces configured, the test-suite (i.e., test-udev.py and/or test-iputil.py) is likely to fail. The following types of interfaces are known to cause failures on autopkgtest runners in Ubuntu: * vlan * gre * dummy * veth I am not sure if Debian autopkgtest runners would be affected but the test suite is a bit fragile at the moment, so I think the patches would make sense. NOTE: Ubuntu is ahead of Debian by two patches, so the autopkgtest failures might not unravel until the following are addressed: * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054533 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057031 In Ubuntu, the attached patch was applied to achieve the following: * Skip mac2iface test for esoteric network interfaces (LP: #2045690) * Add upstream patch to fix udev test for esoteric network interfaces Thanks for considering the patch. -- System Information: Debian Release: trixie/sid APT prefers mantic-updates APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru nvme-stas-2.3/debian/patches/fix-test-udev-with-dummy-interfaces.patch nvme-stas-2.3/debian/patches/fix-test-udev-with-dummy-interfaces.patch --- nvme-stas-2.3/debian/patches/fix-test-udev-with-dummy-interfaces.patch 1970-01-01 01:00:00.0 +0100 +++ nvme-stas-2.3/debian/patches/fix-test-udev-with-dummy-interfaces.patch 2023-12-05 21:04:32.0 +0100 @@ -0,0 +1,26 @@ +Description: Fix test-udev with dummy interfaces +Author: Martin Belanger +Origin: upstream, https://github.com/linux-nvme/nvme-stas/commit/371c1e875a9a660adca241265e4cd460ee7e5e5c +Bug: https://github.com/linux-nvme/nvme-stas/issues/407 +Last-Update: 2023-12-05 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +diff --git a/test/test-udev.py b/test/test-udev.py +index ba484e0..9621edc 100755 +--- a/test/test-udev.py b/test/test-udev.py +@@ -295,6 +295,11 @@ class Test(unittest.TestCase): + def test__cid_matches_tid(self): + ifaces = iputil.net_if_addrs() + for ifname, addrs in self.ifaces.items(): ++# contains a subset of the interfaces found in . ++# So, let's make sure that we only test with the interfaces found in both. ++if ifname not in ifaces: ++continue ++ + ## + # IPV4 + +-- +2.40.1 + diff -Nru nvme-stas-2.3/debian/patches/series nvme-stas-2.3/debian/patches/series --- nvme-stas-2.3/debian/patches/series 2023-11-28 11:01:46.0 +0100 +++ nvme-stas-2.3/debian/patches/series 2023-12-05 21:04:32.0 +0100 @@ -1,3 +1,5 @@ fix-test-libnvme-version.patch fix-test-udev-failing-multiple-IPv6.patch fix-iputil-endianness-issue.patch +skip-mac2iface-test-for-esoteric-interfaces.patch +fix-test-udev-with-dummy-interfaces.patch diff -Nru nvme-stas-2.3/debian/patches/skip-mac2iface-test-for-esoteric-interfaces.patch nvme-stas-2.3/debian/patches/skip-mac2iface-test-for-esoteric-interfaces.patch --- nvme-stas-2.3/debian/patches/skip-mac2iface-test-for-esoteric-interfaces.patch 1970-01-01 01:00:00.0 +0100 +++ nvme-stas-2.3/debian/patches/skip-mac2iface-test-for-esoteric-interfaces.patch 2023-12-05 21:04:32.0 +0100 @@ -0,0 +1,70 @@ +Description: Skip mac2iface test for esoteric interfaces + mac2iface takes a MAC address as argument and returns the corresponding + interface (if any). + The mac2iface tests will however invoke mac2iface with invalid MAC addresses + when esoteric network interfaces are present on the system. As an example, + armhf autopkgtest runners in Ubuntu have gre interfaces configured so the + test-suite fails. + . + We now ensure that the test-suite calls mac2iface with only valid MAC + addresses. + . + Furthermore, sometimes the same MAC address is assigned to more than one + interface on the system (this is true for VLAN interfaces for instance). This + confuses mac2iface, which returns only the first match. This scenario is + possibly more of a nvme-stas bug than a test-suite bug, but for now we will + just skip the interfaces that have a duplicate MAC address. +Author: Olivier Gayot +Bug-Ubuntu: https://launchpad.net/bugs/2045690 +Forwarded: https://github.com/linux-nvme/nvme-stas/pull/411 +Last-Update: 2023-12-05 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/test
Bug#1057467: lomiri-download-manager: Use of GetConnectionAppArmorSecurityContext dropped from DBus years ago
Package: lomiri-download-manager
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
During runtime, lomiri-download-manager still tries to consume the
GetConnectionAppArmorSecurityContext DBus method, which was added in
Ubuntu around 10 years ago and never made it upstream. Instead, upstream
DBus added another way to access the AppArmor security context through
GetConnectionCredentials [1].
The GetConnectionAppArmorSecurityContext method does not exist anymore
in Debian ; so there is no point trying to use it.
I also submitted the patch upstream [2].
In Ubuntu, the attached patch was applied to achieve the following:
* Replace deprecated calls to GetConnectionAppArmorSecurityContext by calls
to GetConnectionCredentials (LP: #1489489).
Thanks for considering the patch.
[1]
https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials
[2]
https://gitlab.com/ubports/development/core/lomiri-download-manager/-/merge_requests/24
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
lomiri-download-manager-0.1.2/debian/patches/1001-drop-deprecated-GetConnectionAppArmorSecurityContext.patch
lomiri-download-manager-0.1.2/debian/patches/1001-drop-deprecated-GetConnectionAppArmorSecurityContext.patch
---
lomiri-download-manager-0.1.2/debian/patches/1001-drop-deprecated-GetConnectionAppArmorSecurityContext.patch
1970-01-01 01:00:00.0 +0100
+++
lomiri-download-manager-0.1.2/debian/patches/1001-drop-deprecated-GetConnectionAppArmorSecurityContext.patch
2023-12-05 10:20:56.0 +0100
@@ -0,0 +1,386 @@
+Description: Drop deprecated calls to GetConnectionAppArmorSecurityContext
+ Around 10 years ago, we introduced GetConnectionAppArmorSecurityContext() in
+ DBus in Ubuntu. Upstream pushed back and instead exposed the AppArmor's
+ context in org.freedesktop.DBus.GetConnectionCredentials().
+ So far, we have maintained GetconnectionAppArmorSecurityContext() as a delta
+ in Ubuntu so that existing software do not break.
+ However, the recommended way (and the only portable way) is to use
+ GetConnectionCredentials() instead. Furthermore, it is about time we drop
+ support for the former in Ubuntu.
+ .
+ The patch is inspired from 4c4d7961261b41ac41f24c8ce75563ab12f6b74c from the
+ https://gitlab.com/ubports/development/core/lomiri-thumbnailer/ repository.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/1489489
+Forwarded:
https://gitlab.com/ubports/development/core/lomiri-download-manager/-/merge_requests/24
+Last-Update: 2023-12-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/common/priv/lomiri/transfers/system/apparmor.cpp
b/src/common/priv/lomiri/transfers/system/apparmor.cpp
+@@ -19,6 +19,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -37,6 +38,8 @@
+ namespace System {
+
+ QString AppArmor::UNCONFINED_ID = "unconfined";
++QString AppArmor::LINUX_SECURITY_LABEL = "LinuxSecurityLabel";
++
+
+ AppArmor::AppArmor(DBusConnection* connection,
+ QObject* parent)
+@@ -68,15 +71,38 @@
+ }
+
+ QString
++AppArmor::labelFromCredentials(const QVariantMap )
++{
++// The contents of this map are described in the specification here:
++//
http://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials
++QByteArray label = map.value(LINUX_SECURITY_LABEL).value();
++
++if (label.size() == 0) {
++return "";
++}
++
++// The label is null terminated.
++assert(label[label.size()-1] == '\0');
++label.truncate(label.size() - 1);
++// Trim the mode off the end of the label.
++int pos = label.lastIndexOf(' ');
++if (pos > 0 && label.endsWith(')') && label[pos+1] == '(')
++{
++label.truncate(pos); // LCOV_EXCL_LINE
++}
++return QString::fromUtf8(label.constData(), label.size());
++}
++
++QString
+ AppArmor::appId(QString caller) {
+-QScopedPointer > reply(
+-_dbus->GetConnectionAppArmorSecurityContext(caller));
++QScopedPointer > reply(
++_dbus->GetConnectionCredentials(caller));
+ // blocking but should be ok for now
+ reply->waitForFinished();
+ if (reply->isError()) {
+ return "";
+ }
+-return reply->value();
++return labelFro
Bug#1056533: testresources autopkg tests fail with Python 3.12
Package: testresources
Followup-For: Bug #1056533
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
The testresources autopkgtest test-suite currently fails with Python
3.12 because it still uses unittest.TestCase.failIf.
failIf was a deprecated alias for assertFalse and was dropped from
Python 3.12.
Applying a patch from upstream allows the test-suite to pass with Python
3.12.
In Ubuntu, the attached patch was applied to achieve the following:
* Fix test-suite so it can run with Python 3.12. (LP: #2045302)
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru testresources-2.0.1/debian/patches/python3.12.patch
testresources-2.0.1/debian/patches/python3.12.patch
--- testresources-2.0.1/debian/patches/python3.12.patch 1970-01-01
01:00:00.0 +0100
+++ testresources-2.0.1/debian/patches/python3.12.patch 2023-11-30
18:59:39.0 +0100
@@ -0,0 +1,35 @@
+Description: Refactor failIf to assertFalse for Python 3.12 Compatibility
+ This commit replaces deprecated failIf calls with assertFalse in the
+ test_resourced_test_case.py file. The failIf method was removed in
+ Python 3.12 [1-3].
+ .
+ [1] https://docs.python.org/3.12/whatsnew/3.12.html#removed
+ [2] https://github.com/python/cpython/issues/89325
+ [3] https://github.com/python/cpython/pull/28268
+Author: Petr Vaněk
+Origin: upstream, https://github.com/testing-cabal/testresources/pull/15
+Bug: https://launchpad.net/bugs/2045302
+Bug-Ubuntu: https://launchpad.net/bugs/2045302
+Bug-Debian: https://bugs.debian.org/1056533
+Applied-Upstream:
https://github.com/testing-cabal/testresources/commit/7bb62a13fa1d28717c10f3152b5e8ea479c8e9d2
+Last-Update: 2023-11-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/testresources/tests/test_resourced_test_case.py
b/testresources/tests/test_resourced_test_case.py
+@@ -129,7 +129,7 @@
+ self.resourced_case.resources = [("foo", self.resource_manager)]
+ self.resourced_case.setUpResources()
+ self.resourced_case.tearDownResources()
+-self.failIf(hasattr(self.resourced_case, "foo"))
++self.assertFalse(hasattr(self.resourced_case, "foo"))
+
+ def testTearDownResourcesStopsUsingResource(self):
+ # tearDownResources records that there is one less use of each
+@@ -158,5 +158,5 @@
+ self.assertEqual(self.resourced_case.foo, self.resource)
+ self.assertEqual(self.resource_manager._uses, 1)
+ self.resourced_case.tearDown()
+-self.failIf(hasattr(self.resourced_case, "foo"))
++self.assertFalse(hasattr(self.resourced_case, "foo"))
+ self.assertEqual(self.resource_manager._uses, 0)
diff -Nru testresources-2.0.1/debian/patches/series
testresources-2.0.1/debian/patches/series
--- testresources-2.0.1/debian/patches/series 2022-10-17 12:22:49.0
+0200
+++ testresources-2.0.1/debian/patches/series 2023-11-30 18:59:07.0
+0100
@@ -1,2 +1,3 @@
remove-non-deterministic-ftbfs-testBasicSortTests.patch
python3.10.patch
+python3.12.patch
Bug#1055571: cracklib2 tests fail with Python 3.12
Package: cracklib2
Followup-For: Bug #1055571
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
When attempting to build src:cracklib2 against Python 3.12, the
build-time test-suite fails, making the package FTBFS.
The test-suite still uses unittest.TestCase.assertEquals() which was
a deprecated alias for unittest.TestCase.assertEqual() (without the s).
The alias was dropped from Python 3.12.
In Ubuntu, the attached patch was applied to achieve the following:
* Fix build against Python 3.12. (LP: #2045290)
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru cracklib2-2.9.6/debian/patches/python3.12-support.patch
cracklib2-2.9.6/debian/patches/python3.12-support.patch
--- cracklib2-2.9.6/debian/patches/python3.12-support.patch 1970-01-01
01:00:00.0 +0100
+++ cracklib2-2.9.6/debian/patches/python3.12-support.patch 2023-11-30
17:46:13.0 +0100
@@ -0,0 +1,77 @@
+Description: Fix build against Python 3.12
+ The build-time test suite still used the obsolete assertEquals function -
+ which was obsolete and got dropped from Python 3.12. Use the replacement
+ instead so we can build with Python 3.12.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/2045290
+Bug-Debian: https://bugs.debian.org/1055571
+Forwarded: https://github.com/cracklib/cracklib/pull/75
+Last-Update: 2023-11-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/python/test_cracklib.py
b/python/test_cracklib.py
+@@ -76,41 +76,41 @@
+ def test_simple_lower(self):
+ for passwd in ['t' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.LOW_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ 't' * (cracklib.MIN_LENGTH - cracklib.LOW_CREDIT)))
+
+ def test_simple_upper(self):
+ for passwd in ['T' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.UP_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ 'T' * (cracklib.MIN_LENGTH - cracklib.UP_CREDIT)))
+
+ def test_simple_digit(self):
+ for passwd in ['1' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.DIG_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ '1' * (cracklib.MIN_LENGTH - cracklib.DIG_CREDIT)))
+
+ def test_simple_other(self):
+ for passwd in ['#' * i for i in range(
+ cracklib.MIN_LENGTH - cracklib.OTH_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ '#' * (cracklib.MIN_LENGTH - cracklib.OTH_CREDIT)))
+
+ def test_simple_combinations(self):
+@@ -119,11 +119,11 @@
+ cracklib.MIN_LENGTH -
+ cracklib.LOW_CREDIT -
+ cracklib.OTH_CREDIT)]:
+-self.assertEquals(
++self.assertEqual(
+ 1, cracklib.simple(passwd),
+ 'password {0} should be detected as too simple'.format(
+ passwd))
+-self.assertEquals(0, cracklib.simple(
++self.assertEqual(0, cracklib.simple(
+ testset[:(cracklib.MIN_LENGTH - cracklib.LOW_CREDIT -
+ cracklib.OTH_CREDIT)]))
+
diff -Nru cracklib2-2.9.6/debian/patches/series
cracklib2-2.9.6/debian/patches/series
--- cracklib2-2.9.6/debian/patches/series 2022-11-29 08:26:33.0
+0100
+++ cracklib2
Bug#1055687: khmer ftbfs with Python 3.12
Hi, Thank you for uploading 3.0.0~a3+dfsg-6! I was about to request a sync in Ubuntu. Sadly, I noticed that I forgot to forward one change that was done as an intermediate upload in Ubuntu. The change is required for Python 3.12 support. Sorry about that! I've just opened https://salsa.debian.org/med-team/khmer/-/merge_requests/1 with the missing bits to correct the mistake. Best regards, Olivier
Bug#1055687: khmer ftbfs with Python 3.12
Hi Andreas, On Wed, 29 Nov 2023 14:26:01 +0100 Andreas Tille wrote: When looking at the first patch > it applies to a series file containing the patches > > refresh_cython > find_object_files_at_right_loc.patch > > at the end. I'd love to profit from all those patches. Where > can I find these? > You can find all the patches that are currently used for khmer 3.0.0~a3+dfsg-5 in the khmer tree from Debian Med: https://salsa.debian.org/med-team/khmer/-/tree/master/debian/patches Thanks, Olivier
Bug#1057031: nvme-stas: autopkgtest hanging on s390x
Hello, nvme-stas v2.3.1 is out now :) https://github.com/linux-nvme/nvme-stas/releases/tag/v2.3.1 Best regards, Olivier
Bug#1057031: nvme-stas: autopkgtest hanging on s390x
Thanks Daniel! FYI Martin Bélanger (from nvme-stas upstream) will be preparing a 2.3.1 release of nvme-stas. It should contain some of the patches needed so if we are not in a hurry, we might as well wait for 2.3.1 to be out. Thanks, Olivier On 11/28/23 11:38, Daniel Baumann wrote: > Hi Olivier, > > thanks you, that is much apperciated. I've been mostly away/VAC the last > two weeks, but I'll take care about this and the other patch later today. > > Regards, > Daniel
Bug#1057031: nvme-stas: autopkgtest hanging on s390x
Package: nvme-stas
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
After applying fixes from bug 1054533 [1], autopkgtest
for nvme-stas hangs on s390x and ends up failing on timeout.
Excerpt from an autopkgtest run on Ubuntu [2].
> 96s test__data_matches_ip (test-iputil.Test.test__data_matches_ip) ... ok
> 596s test_get_interface (test-iputil.Test.test_get_interface)
> 10600s Check that get_interface() returns the right info ... autopkgtest
> [02:09:30]: ERROR: timed out on command "su -s /bin/bash ubuntu -c set -e;
> [...]
This is caused by an endianness issue in staslib.iputil when
packing/unpacking netlink data structures. It can be fixed by using host
byte ordering instead of "hard-coding" little endian.
I forwarded the fix upstream [3].
In Ubuntu, the attached patch was applied to achieve the following:
* Fix endianness issues in staslib.iputil causing hangs on s390x.
(LP: #2045000)
Thanks for considering the patch.
[1] https://bugs.debian.org/1054533
[2]
https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/s390x/n/nvme-stas/20231128_021002_94626@/log.gz
[3] https://github.com/linux-nvme/nvme-stas/pull/406
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru nvme-stas-2.3/debian/control nvme-stas-2.3/debian/control
--- nvme-stas-2.3/debian/control2023-11-27 17:45:04.0 +0100
+++ nvme-stas-2.3/debian/control2023-11-28 11:01:46.0 +0100
@@ -1,8 +1,7 @@
Source: nvme-stas
Section: net
Priority: optional
-Maintainer: Ubuntu Developers
-XSBC-Original-Maintainer: Daniel Baumann
+Maintainer: Daniel Baumann
Uploaders:
Benjamin Drung ,
Build-Depends:
diff -Nru nvme-stas-2.3/debian/patches/fix-iputil-endianness-issue.patch
nvme-stas-2.3/debian/patches/fix-iputil-endianness-issue.patch
--- nvme-stas-2.3/debian/patches/fix-iputil-endianness-issue.patch
1970-01-01 01:00:00.0 +0100
+++ nvme-stas-2.3/debian/patches/fix-iputil-endianness-issue.patch
2023-11-28 11:01:46.0 +0100
@@ -0,0 +1,103 @@
+Description: iputil: pack and unpack using native byte ordering
+ On big-endian architectures (such as s390x), tests defined in
+ test-iputil.py would hang:
+ .
+ > 596s test_get_interface (test-iputil.Test.test_get_interface)
+ > 10600s Check that get_interface() returns the right info ...
+ .
+ Indeed, running the following hangs as well:
+ .
+ > from staslib import iputil
+ >
+ > iputil.net_if_addrs()
+ .
+ This is an endianness issue that can be fixed by using native
+ byte-ordering when packing and unpacking netlink data structures such as
+ ifaddrmsg.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/2045000
+Forwarded: https://github.com/linux-nvme/nvme-stas/pull/406
+Last-Update: 2023-11-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/staslib/iputil.py
b/staslib/iputil.py
+@@ -42,7 +42,7 @@
+ __u32 nlmsg_pid; /* Sending process port ID */
+ };
+ '''
+-return struct.pack('
Bug#1054533: nvme-stas: autopkgtest fails on all architectures
Package: nvme-stas
Followup-For: Bug #1054533
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
Several test cases in nvme-stas 2.3-1 were making the autopkgtest fail.
In Ubuntu, the attached patch was applied to achieve the following:
* Add Test-Depends on nvme-cli to fix the absence of /etc/nvme/host{nqn,id}
when running the test suite. (LP: #2043792)
- This is only a workaround for autopkgtests. stafd can still fail with
the same error at runtime outside of autopkgtests when configured with
an appropriate "controller =" directive.
* Fix failing test from mocked libnvme version. (LP: #2043792)
* Fix legacy Udev test failing when multiples IPv6 addresses are set.
(LP: #2043792)
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru nvme-stas-2.3/debian/patches/fix-test-libnvme-version.patch
nvme-stas-2.3/debian/patches/fix-test-libnvme-version.patch
--- nvme-stas-2.3/debian/patches/fix-test-libnvme-version.patch 1970-01-01
01:00:00.0 +0100
+++ nvme-stas-2.3/debian/patches/fix-test-libnvme-version.patch 2023-11-21
09:29:41.0 +0100
@@ -0,0 +1,52 @@
+Description: Fix mock libnvme test so it works in GitHub actions & autopkgtest
+ Different Python test frameworks manage Python processes differently
+ when running tests. When running `python3 -m unittest` for instance, it
+ looks like the same process executes all the tests. Therefore when one
+ test module T1 imports a module, the module is not re-imported if needed
+ by T2.
+ .
+ This causes issues with test-defs.py which tries to mock the libnvme
+ module. Indeed, when it is previously imported by staslib, the mocked
+ libnvme module does not get re-imported.
+ .
+ Fixed by removing staslib and staslib.defs from the imported modules
+ before executing the test.
+Author: Olivier Gayot
+Origin: upstream,
https://github.com/linux-nvme/nvme-stas/commit/2efebdb4dec6d5a6341a577273a1ce7b57fe488c
+Bug-Ubuntu: https://launchpad.net/bugs/2043792
+Bug-Debian: https://bugs.debian.org/1054533
+Last-Update: 2023-11-27
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/test/test-defs.py
b/test/test-defs.py
+@@ -1,4 +1,5 @@
+ #!/usr/bin/python3
++import contextlib
+ import os
+ import sys
+ import unittest
+@@ -9,13 +10,17 @@
+ '''Testing defs.py by mocking the libnvme package'''
+
+ def test_libnvme_version(self):
+-# For unknown reasons, this test does
+-# not work when run from GitHub Actions.
+-if not os.getenv('GITHUB_ACTIONS'):
+-from staslib import defs
++# Ensure that we re-import staslib & staslib.defs if the current
Python
++# process has them already imported.
++with contextlib.suppress(KeyError):
++sys.modules.pop('staslib.defs')
++with contextlib.suppress(KeyError):
++sys.modules.pop('staslib')
+
+-libnvme_ver = defs.LIBNVME_VERSION
+-self.assertEqual(libnvme_ver, '?.?')
++from staslib import defs
++
++libnvme_ver = defs.LIBNVME_VERSION
++self.assertEqual(libnvme_ver, '?.?')
+
+ @classmethod
+ def setUpClass(cls): # called once before all the tests
diff -Nru
nvme-stas-2.3/debian/patches/fix-test-udev-failing-multiple-IPv6.patch
nvme-stas-2.3/debian/patches/fix-test-udev-failing-multiple-IPv6.patch
--- nvme-stas-2.3/debian/patches/fix-test-udev-failing-multiple-IPv6.patch
1970-01-01 01:00:00.0 +0100
+++ nvme-stas-2.3/debian/patches/fix-test-udev-failing-multiple-IPv6.patch
2023-11-21 09:29:41.0 +0100
@@ -0,0 +1,29 @@
+Description: Fix test-udev failing when multiple IPv6 addresses are used
+ test-udev was failing when an interface had more than one IPv6
+ addresses assigned. This was due to the test checking that the
+ number of assigned IPv6 addresses was exactly 1 (== 1) instead of
+ checking greater-equal to 1 (>= 1).
+Author: Martin Belanger
+Origin: upstream,
https://github.com/linux-nvme/nvme-stas/commit/66b42bdd83bb6a83b30da3aed5fea9ed4da882f6
+Bug: https://github.com/linux-nvme/nvme-stas/issues/403
+Bug-Ubuntu: https://launchpad.net/bugs/2043792
+Bug-Debian: https://bugs.debian.org/1054533
+Last-Update: 2023-11-27
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/test/test-udev.py b/test/test-udev.py
+index be257d9..ba484e0 100755
+--
Bug#1055687: khmer ftbfs with Python 3.12
Package: khmer
Followup-For: Bug #1055687
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
My previous patch was unfortunately very incomplete. I am submitting
another patch that fixes the remaining issues when building with Python
3.12. Both debdiffs should be applied for the build to succeed.
Additional fixes that were needed for the build to succeed:
* Python 3.12 dropped the "imp" module. Updated to use importlib
instead.
* Python 3.12 is much less forgiving when a script opens a file for
writing and forgets to close it. Most Python scripts in scripts/ failed
to do so or did so inconsistently. This resulted in the test suite
either hanging or failing. I went through all invocations of open() /
get_file_writer() and ensured that the resources are cleaned up. The
resulting patch is sadly difficult to read though.
I submitted all changes upstream, although I doubt somebody will pick
them up:
https://github.com/dib-lab/khmer/pull/1922
In Ubuntu, the attached patch was applied to achieve the following:
* Fix build against Python 3.12 (LP: #2044383).
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru khmer-3.0.0~a3+dfsg/debian/control khmer-3.0.0~a3+dfsg/debian/control
--- khmer-3.0.0~a3+dfsg/debian/control 2023-11-25 17:44:28.0 +0100
+++ khmer-3.0.0~a3+dfsg/debian/control 2023-11-26 02:28:32.0 +0100
@@ -1,6 +1,5 @@
Source: khmer
-Maintainer: Ubuntu Developers
-XSBC-Original-Maintainer: Debian Med Packaging Team
+Maintainer: Debian Med Packaging Team
Uploaders: Michael R. Crusoe ,
Kevin Murray
Section: science
diff -Nru khmer-3.0.0~a3+dfsg/debian/patches/close-opened-files.patch
khmer-3.0.0~a3+dfsg/debian/patches/close-opened-files.patch
--- khmer-3.0.0~a3+dfsg/debian/patches/close-opened-files.patch 1970-01-01
01:00:00.0 +0100
+++ khmer-3.0.0~a3+dfsg/debian/patches/close-opened-files.patch 2023-11-26
02:28:32.0 +0100
@@ -0,0 +1,1124 @@
+Description: ensure that Python scripts close files that they open for writing
+ Python scripts under scripts/ in the source tree do not consistently close
+ files that they open for writing. While some of the scripts use context
+ managers, most of them do not (or do so inconsistently).
+ In previous releases of Ubuntu, this apparently was not much of a concern.
+ However, Python 3.12 seems to be much less forgiving when files are not
+ properly closed. When running the test suite, many of the files that are not
+ explicitly closed appear truncated. This leads to various tests failing or
+ hanging and causing FTBFS when the test suite runs at build time.
+ .
+ Furthermore, khmer defines the get_file_writer() function, but it cannot be
+ consistently used as a context manager because it sometimes closes the
+ underlying file descriptor ; and sometimes does not depending on the
+ arguments.
+ .
+ Fixed by defining a new FileWriter context manager and ensuring that
+ each call to open() / get_file_writer() frees up resources properly.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/2044383
+Bug-Debian: https://bugs.debian.org/1055687
+Forwarded: https://github.com/dib-lab/khmer/pull/1922
+Last-Update: 2023-11-26
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: khmer-3.0.0~a3+dfsg/scripts/abundance-dist.py
+===
+--- khmer-3.0.0~a3+dfsg.orig/scripts/abundance-dist.py 2023-11-26
20:23:39.915485717 +0100
khmer-3.0.0~a3+dfsg/scripts/abundance-dist.py 2023-11-26
20:23:39.911485747 +0100
+@@ -42,6 +42,7 @@
+ Use '-h' for parameter help.
+ """
+
++import contextlib
+ import sys
+ import csv
+ import khmer
+@@ -143,26 +144,28 @@
+ sys.exit(1)
+
+ if args.output_histogram_filename in ('-', '/dev/stdout'):
+-countgraph_fp = sys.stdout
++countgraph_ctx = contextlib.nullcontext(enter_result=sys.stdout)
+ else:
+-countgraph_fp = open(args.output_histogram_filename, 'w')
+-countgraph_fp_csv = csv.writer(countgraph_fp)
+-# write headers:
+-countgraph_fp_csv.writerow(['abundance', 'count', 'cumulative',
+-'cumulative_fraction'])
+-
+-sofar = 0
+-for _, i in enumerate(abundances):
+-if i == 0 and not args.output_zero:
+-continue
++countgraph_ctx = open(args.outp
Bug#1056919: ardour: Appears in menus as Ardour7
Hi and thanks for the report. I've already fixed that the 29 october but didn't ask for a new build since it's only a small thing that can wait for the next upload. In other words, next time something will be done on the build (probably next version if nothing important comes up before), it will be there. All the best, Olivier -- Site web : https://librazik.tuxfamily.org/ Donation : https://liberapay.com/LibraZiK/ Diaspora : https://framasphere.org/people/8c184af0c9450134f6682a053625 Mastodon : https://mastodon.xyz/@LibraZiK
Bug#1056707: debsecan: Recent suite codenames not allowed in debconf
Package: debsecan Version: 0.4.20.1 Followup-For: Bug #1056707 Here's a patchset which should fix the issue. Also, I realised a tad too late that this is a more generic version/dupe of #1038952. >From a70b0f7290ad8fcc7176963c48cf5f335c51f1ac Mon Sep 17 00:00:00 2001 From: Olivier Mehani Date: Sat, 25 Nov 2023 17:56:54 +1100 Subject: [PATCH 1/3] Add recent suites to debconf fixes: #1038952, #1056707 Signed-off-by: Olivier Mehani --- debian/debsecan.templates | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/debsecan.templates b/debian/debsecan.templates index 36e7bde..58b380d 100644 --- a/debian/debsecan.templates +++ b/debian/debsecan.templates @@ -16,7 +16,8 @@ _Description: Email address to which daily reports should be sent: Template: debsecan/suite Type: select -Choices: GENERIC, jessie, stretch, buster, bullseye, sid +Choices: GENERIC, jessie, stretch, buster, bullseye, bookworm, trixie, sid + Default: GENERIC _Description: Main suite from which packages are installed: To present more useful data, debsecan needs to know -- 2.42.0 >From 23fcc4a88d1bef951421ed6a15f023968821160e Mon Sep 17 00:00:00 2001 From: Olivier Mehani Date: Sat, 25 Nov 2023 17:57:23 +1100 Subject: [PATCH 2/3] Remove old suites from debconf Signed-off-by: Olivier Mehani --- debian/debsecan.templates | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/debsecan.templates b/debian/debsecan.templates index 58b380d..bfeaa1b 100644 --- a/debian/debsecan.templates +++ b/debian/debsecan.templates @@ -16,7 +16,7 @@ _Description: Email address to which daily reports should be sent: Template: debsecan/suite Type: select -Choices: GENERIC, jessie, stretch, buster, bullseye, bookworm, trixie, sid +Choices: GENERIC, buster, bullseye, bookworm, trixie, sid Default: GENERIC _Description: Main suite from which packages are installed: -- 2.42.0 >From a0429fdc708839e023e2d7b898416b85902b8678 Mon Sep 17 00:00:00 2001 From: Olivier Mehani Date: Sat, 25 Nov 2023 18:02:44 +1100 Subject: [PATCH 3/3] Update changelog Signed-off-by: Olivier Mehani --- debian/changelog | 8 1 file changed, 8 insertions(+) diff --git a/debian/changelog b/debian/changelog index c2fbb1b..c4e22bc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +debsecan (0.4.20.1+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add recent suites to debconf. Closes: #1038952, #1056707. + * Remove old suites from debconf. + + -- Olivier Mehani Sat, 25 Nov 2023 18:02:00 +1100 + debsecan (0.4.20.1) unstable; urgency=low * Source-only upload for testing transition. -- 2.42.0
Bug#1056707: debsecan: Recent suite codenames not allowed in debconf
Package: debsecan Version: 0.4.20.1 Severity: important Tags: patch Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing debsecan on bookworm * What exactly did you do (or not do) that was effective (or ineffective)? Using debconf to set suite to bookworm * What was the outcome of this action? /etc/default/debsecan has SUITE=GENERIC * What outcome did you expect instead? /etc/default/debsecan has SUITE=bookwarm *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.2 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (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 debsecan depends on: ii ca-certificates20230311 ii debconf [debconf-2.0] 1.5.82 ii python33.11.2-1+b1 ii python3-apt2.6.0 Versions of packages debsecan recommends: ii cron [cron-daemon]3.0pl1-162 ii msmtp-mta [mail-transport-agent] 1.8.23-1 debsecan suggests no packages. -- debconf information: * debsecan/suite: bookworm * debsecan/report: true * debsecan/source: * debsecan/mailto: shtrom+ad...@ssji.net
Bug#1056591: acedb FTBFS against glibc 2.38
Package: acedb
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Dear Maintainer,
Trying to build with glibc 2.38 fails with the following error:
../wh/utils.h:34:7: error: conflicting types for ‘strcasestr’; have ‘char
*(char *, char *)’
34 | char *strcasestr (char *str1, char *str2);
| ^~
In file included from ../wh/mystdlib.h:227,
from ../wh/regular.h:51,
from utils.c:37:
/usr/include/string.h:380:14: note: previous declaration of ‘strcasestr’ with
type ‘char *(const char *, const char *)’
Before glibc 2.38, the strcasestr function was only made available when
building with _GNU_SOURCE. Starting with glibc 2.38, the function is
available by default.
In Ubuntu, the attached patch was applied to achieve the following:
* Fix build against glibc 2.38 (LP: #2044385)
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch
acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch
--- acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch1970-01-01
01:00:00.0 +0100
+++ acedb-4.9.39+dfsg.02/debian/patches/glibc-2.38.patch2023-11-23
16:07:13.0 +0100
@@ -0,0 +1,47 @@
+Description: Fix build against glibc 2.38
+ In previous glibc versions, strcasestr would only be available if building
+ with _GNU_SOURCE.
+ Starting with glibc 2.38, strcasestr is now available by default.
+ Ensure that acedb does not redefine the function if we're building with a
modern glibc.
+Author: Olivier Gayot
+Bug:
+Bug-Ubuntu: https://launchpad.net/bugs/2044385
+Forwarded: no
+Last-Update: 2023-11-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: acedb-4.9.39+dfsg.02/w1/utils.c
+===
+--- acedb-4.9.39+dfsg.02.orig/w1/utils.c 2005-10-04 15:15:00.0
+0200
acedb-4.9.39+dfsg.02/w1/utils.c2023-11-23 16:48:20.118800952 +0100
+@@ -774,7 +774,7 @@
+ //
+ /* case-insensitive version of strstr */
+
+-#ifndef DARWIN
++#ifndef HAS_STRCASESTR
+ char *strcasestr(char *str1, char *str2)
+ {
+ g_strup(str1);
+Index: acedb-4.9.39+dfsg.02/wh/utils.h
+===
+--- acedb-4.9.39+dfsg.02.orig/wh/utils.h 2023-11-23 16:19:02.454527757
+0100
acedb-4.9.39+dfsg.02/wh/utils.h2023-11-23 16:47:40.099066905 +0100
+@@ -29,7 +29,16 @@
+ *---
+ */
+
+-#ifndef DARWIN
++/* Ensure that features.h or an equivalent is included. */
++#include
++
++#if defined(DARWIN) || defined(_GNU_SOURCE)
++# define HAS_STRCASESTR
++#elif __GLIBC__ >= 2 && __GLIBC_MINOR__ >= 38
++# define HAS_STRCASESTR
++#endif
++
++#ifndef HAS_STRCASESTR
+ /* case-insensitive version of strstr */
+ char *strcasestr (char *str1, char *str2);
+ #endif
diff -Nru acedb-4.9.39+dfsg.02/debian/patches/series
acedb-4.9.39+dfsg.02/debian/patches/series
--- acedb-4.9.39+dfsg.02/debian/patches/series 2023-08-15 16:23:13.0
+0200
+++ acedb-4.9.39+dfsg.02/debian/patches/series 2023-11-23 16:07:13.0
+0100
@@ -13,3 +13,4 @@
glibc2.32.patch
# drop_gtk2.patch
just_build_efetch.patch
+glibc-2.38.patch
Bug#1055687: khmer ftbfs with Python 3.12
Package: khmer
Followup-For: Bug #1055687
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* Fix build against Python 3.12 (LP: #2044383).
Thanks for considering the patch.
-- System Information:
Debian Release: trixie/sid
APT prefers mantic-updates
APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch
khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch
--- khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch 1970-01-01
01:00:00.0 +0100
+++ khmer-3.0.0~a3+dfsg/debian/patches/python3.12-support.patch 2023-11-23
15:24:51.0 +0100
@@ -0,0 +1,24 @@
+Description: Add support for Python 3.12
+ Ever since Python 3.2, configparser.SafeConfigParser has been deprecated in
+ favor of configparser.ConfigParser. An alias existed for backward compability
+ but the alias was dropped from Python 3.12.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/2044383
+Bug-Debian: https://bugs.debian.org/1055687
+Forwarded: https://github.com/dib-lab/khmer/pull/1922
+Last-Update: 2023-11-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: khmer-3.0.0~a3+dfsg/versioneer.py
+===
+--- khmer-3.0.0~a3+dfsg.orig/versioneer.py 2019-03-13 14:42:12.0
+0100
khmer-3.0.0~a3+dfsg/versioneer.py 2023-11-23 15:19:50.025827413 +0100
+@@ -339,7 +339,7 @@
+ # configparser.NoOptionError (if it lacks "VCS="). See the docstring at
+ # the top of versioneer.py for instructions on writing your setup.cfg .
+ setup_cfg = os.path.join(root, "setup.cfg")
+-parser = configparser.SafeConfigParser()
++parser = configparser.ConfigParser()
+ with open(setup_cfg, "r") as f:
+ parser.readfp(f)
+ VCS = parser.get("versioneer", "VCS") # mandatory
diff -Nru khmer-3.0.0~a3+dfsg/debian/patches/series
khmer-3.0.0~a3+dfsg/debian/patches/series
--- khmer-3.0.0~a3+dfsg/debian/patches/series 2023-09-09 08:30:33.0
+0200
+++ khmer-3.0.0~a3+dfsg/debian/patches/series 2023-11-23 15:19:31.0
+0100
@@ -17,3 +17,4 @@
stringio-buffer.patch
refresh_cython
find_object_files_at_right_loc.patch
+python3.12-support.patch
Bug#1054533: nvme-stas: autopkgtest fails on all architectures
Although this issue appears as a regression in nvme-stas 2.3-1, it looks like it was already affecting the usability of the nvme-stas version in testing (i.e., 2.2.2-2) - outside of autopkgtests. Here with nvme-stas 2.2.2-2 (after configuring a controller in /etc/stas/stafd.conf): Nov 17 11:14:05 usable-whippet systemd[1]: Reloaded stafd.service - STorage Appliance Finder (STAF). Nov 17 11:14:07 usable-whippet stafd[1268]: Error reading mandatory Host NQN (see stasadm --help): [Errno 2] No such file or directory: '/etc/nvme/hostnqn' Nov 17 11:14:07 usable-whippet systemd[1]: stafd.service: Main process exited, code=exited, status=1/FAILURE Nov 17 11:14:07 usable-whippet systemd[1]: stafd.service: Failed with result 'exit-code'. To make the autopkgtest pass, I believe we can either: * add a Test-Depends on nvme-cli; or * running those commands as part of the autopkgtest: * mkdir --parents /etc/nvme * systemctl start stas-config@hostnqn * systemctl start stas-config@hostid That said, I suggest we look for a solution that also resolves the issue outside of autopkgtests. Would introducing a Depends on nvme-cli be a bad thing? Kind regards, Olivier
Bug#1056018: partman-base: parted_devices hangs with process in D state during Debian installer Detect Disks step
Source: partman-base Version: 226 Severity: critical Tags: d-i Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Updating from Debian 8 to Debian 12 from an USB stick. * What exactly did you do (or not do) that was effective (or ineffective)? Ineffective: Tried disconnecting external disks & USB storage HUB, and switching SATA setting from AHCI to IDE in BIOS. Also tried expert mode & text mode. * What was the outcome of this action? Debian Installer is stuck on Detect Disks. Switching to a console and running ps shows that a parted_devices process is in D state. * What outcome did you expect instead? parted_devices should only take a few seconds and Debian Installer should continue to the partionning step. Note: I'm reporting from another computer. System information from the old OS is irrelevant anyway as the computer is booted on the Debian 12 installer image when the problem occurs. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-12-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1055076: glibc: wrong _PATH_NOLOGIN in paths.h
Woops! I didn't know that. Thanks for the explanation :) -- Olivier Duclos On Tue, Oct 31, 2023, at 20:02, Aurelien Jarno wrote: > Hi, > > On 2023-10-30 22:17, Olivier Duclos wrote: >> Package: libc6-dev >> Source: glibc >> Version: 2.38-3 >> Severity: normal >> >> In /usr/include/paths.h at line 56 we have: >> >> #define _PATH_NOLOGIN "/etc/nologin" >> >> This path is incorrect and should be replaced by "/usr/sbin/nologin". > > I think you are missing two different things: > - The /etc/nologin file that prevent non-root users to log on a > machine if it exists. > - The nologin shell that can be used in /etc/passwd to prevent the > corresponding users to login. > > Changing _PATH_NOLOGIN to "/usr/sbin/nologin", as you suggest, might > prevent users to log on there system once packages are rebuild against > the changed paths.h as this binary is provided by an essential package > present on all systems. "might" because pam does not use the glibc > paths.h and hard codes the path instead. But OpenSSH seems to use it. > > Regards > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://aurel32.net
Bug#1055076: glibc: wrong _PATH_NOLOGIN in paths.h
Package: libc6-dev Source: glibc Version: 2.38-3 Severity: normal In /usr/include/paths.h at line 56 we have: #define _PATH_NOLOGIN "/etc/nologin" This path is incorrect and should be replaced by "/usr/sbin/nologin". Debian has a patch that could be amended to fix this: https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/any/local-fhs-linux-paths.diff -- Olivier Duclos
Bug#1054172: nextcloud-desktop: Header of main window displays black zone without widgets (XFCE)
Package: nextcloud-desktop Version: 3.10.0-1 Severity: normal Dear Maintainer, I'm running Nextcloud-Desktop on XFCE, and just noticed that a recent update of my testing system caused the main dialog to display weirdly. The zone which usually contains a dropbox allowing to switch the current account is display as a fully black zone (see attached screenshot). Ths makes it quite difficult to use. Hope this helps, Best regards, -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nextcloud-desktop depends on: ii libc6 2.37-12 ii libcloudproviders0 0.3.4-1 ii libgcc-s1 13.2.0-4 ii libglib2.0-0 2.78.0-2 ii libkf5archive5 5.107.0-1 ii libnextcloudsync0 3.10.0-1 ii libqt5core5a 5.15.10+dfsg-3 ii libqt5dbus55.15.10+dfsg-3 ii libqt5gui5 5.15.10+dfsg-3 ii libqt5keychain10.14.1-1 ii libqt5network5 5.15.10+dfsg-3 ii libqt5qml5 5.15.10+dfsg-2 ii libqt5quick5 5.15.10+dfsg-2 ii libqt5quickcontrols2-5 5.15.10+dfsg-2 ii libqt5sql5-sqlite 5.15.10+dfsg-3 ii libqt5svg5 5.15.10-2 ii libqt5webenginecore5 5.15.15+dfsg-2+b1 ii libqt5webenginewidgets55.15.15+dfsg-2+b1 ii libqt5widgets5 5.15.10+dfsg-3 ii libssl33.0.11-1 ii libstdc++6 13.2.0-4 ii nextcloud-desktop-common 3.10.0-1 ii nextcloud-desktop-l10n 3.10.0-1 ii qml-module-qt-labs-platform5.15.10+dfsg-2 ii qml-module-qtgraphicaleffects 5.15.10-2 ii qml-module-qtqml 5.15.10+dfsg-2 ii qml-module-qtqml-models2 5.15.10+dfsg-2 ii qml-module-qtquick-controls2 5.15.10+dfsg-2 ii qml-module-qtquick-dialogs 5.15.10-2 ii qml-module-qtquick-layouts 5.15.10+dfsg-2 ii qml-module-qtquick-window2 5.15.10+dfsg-2 ii qml-module-qtquick25.15.10+dfsg-2 Versions of packages nextcloud-desktop recommends: ii nextcloud-desktop-doc 3.10.0-1 nextcloud-desktop suggests no packages. -- debconf-show failed -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1051887: ecryptfs-utils: Permission denied for wrapped-passphrase
Package: ecryptfs-utils Version: 111-6 Severity: normal X-Debbugs-Cc: olivier.caill...@gmail.com Dear Maintainer, On my system, the command ecryptfs-migrate-home fails to create a working setup, despite following instructions at https://wiki.debian.org/TransparentEncryptionForHomeFolder . When login as the encrypted user, it refuses to mount the encrypted folder, and syslog logs: “gdm-password]: Failed to detect wrapped passphrase version: Permission denied”. The command had created a folder /home/.ecryptfs that was only readable by root. I added “all” permissions to read and traverse, and the problem was solved. I suspect that the command ecryptfs-migrate-home should make sure that the folder /home/.ecryptfs/ has the right permissions. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ecryptfs-utils depends on: ii gettext-base0.21-12 ii keyutils1.6.3-2 ii libc6 2.36-9+deb12u1 ii libecryptfs1111-6 ii libgpgme11 1.18.0-3+b1 ii libkeyutils11.6.3-2 ii libpam-runtime 1.5.2-6 ii libpam0g1.5.2-6 ii libtspi10.3.15-0.3 ecryptfs-utils recommends no packages. Versions of packages ecryptfs-utils suggests: pn cryptsetup ii rsync 3.2.7-1 -- no debconf information
Bug#1025537: nfsd: Kernel Oops while serving NFS
Package: src:linux Followup-For: Bug #1025537 Dear Maintainer, Just a heads up that, after some uptime and an utimely reboot, I am now on 6.4.0-3, which no longer seems to exhibit the issue from earlier 6.x series. While we didn't get to the root cause, I think this bug can be tentatively closed. -- Package-specific info: ** Version: Linux version 6.4.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-2) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.4.11-1 (2023-08-17) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.4.0-3-amd64 root=UUID=0c917590-acc7-464c-8961-64f79e1d1c69 ro init=/lib/systemd/systemd init=/lib/systemd/systemd ** Not tainted ** Kernel log: ** Model information sys_vendor: [ 513.266864] veth75b1ef3: entered allmulticast mode [ 513.278803] veth75b1ef3: entered promiscuous mode [ 513.318708] eth0: renamed from veth289468d [ 513.350910] IPv6: ADDRCONF(NETDEV_CHANGE): vethd452ab0: link becomes ready [ 513.354043] br-167ce2d5a745: port 1(vethd452ab0) entered blocking state [ 513.357003] br-167ce2d5a745: port 1(vethd452ab0) entered forwarding state [ 513.360079] IPv6: ADDRCONF(NETDEV_CHANGE): br-167ce2d5a745: link becomes ready [ 516.185425] br-8faf6cb95741: port 3(veth3348892) entered blocking state [ 516.189032] br-8faf6cb95741: port 3(veth3348892) entered disabled state [ 516.203888] veth3348892: entered allmulticast mode [ 516.210796] veth3348892: entered promiscuous mode [ 529.090856] eth0: renamed from vethd1244c6 [ 529.111282] IPv6: ADDRCONF(NETDEV_CHANGE): veth20d9bda: link becomes ready [ 529.114664] br-410ffb6f054c: port 1(veth20d9bda) entered blocking state [ 529.117918] br-410ffb6f054c: port 1(veth20d9bda) entered forwarding state [ 529.121900] IPv6: ADDRCONF(NETDEV_CHANGE): br-410ffb6f054c: link becomes ready [ 550.583717] br-8faf6cb95741: port 4(vethabeb253) entered blocking state [ 550.587030] br-8faf6cb95741: port 4(vethabeb253) entered disabled state [ 550.593753] vethabeb253: entered allmulticast mode [ 550.597325] vethabeb253: entered promiscuous mode [ 566.713758] eth0: renamed from vetha110c01 [ 566.736720] IPv6: ADDRCONF(NETDEV_CHANGE): veth6843607: link becomes ready [ 566.740228] br-167ce2d5a745: port 2(veth6843607) entered blocking state [ 566.743665] br-167ce2d5a745: port 2(veth6843607) entered forwarding state [ 566.982165] eth0: renamed from vethb129f19 [ 567.004696] IPv6: ADDRCONF(NETDEV_CHANGE): veth7291cce: link becomes ready [ 567.008299] br-8faf6cb95741: port 1(veth7291cce) entered blocking state [ 567.011785] br-8faf6cb95741: port 1(veth7291cce) entered forwarding state [ 567.020597] IPv6: ADDRCONF(NETDEV_CHANGE): br-8faf6cb95741: link becomes ready [ 569.328071] eth0: renamed from veth0690f82 [ 569.345031] IPv6: ADDRCONF(NETDEV_CHANGE): veth908ed4d: link becomes ready [ 569.348796] br-8fa0fed72bf0: port 2(veth908ed4d) entered blocking state [ 569.352495] br-8fa0fed72bf0: port 2(veth908ed4d) entered forwarding state [ 570.025027] eth0: renamed from veth8259256 [ 570.045606] IPv6: ADDRCONF(NETDEV_CHANGE): vetha2c6a28: link becomes ready [ 570.050336] br-8fa0fed72bf0: port 3(vetha2c6a28) entered blocking state [ 570.054287] br-8fa0fed72bf0: port 3(vetha2c6a28) entered forwarding state [ 570.469070] eth0: renamed from veth452c69a [ 570.489637] IPv6: ADDRCONF(NETDEV_CHANGE): vethd58db50: link becomes ready [ 570.493575] br-410ffb6f054c: port 2(vethd58db50) entered blocking state [ 570.497349] br-410ffb6f054c: port 2(vethd58db50) entered forwarding state [ 570.841451] eth0: renamed from vethd61b822 [ 570.865532] IPv6: ADDRCONF(NETDEV_CHANGE): veth3fcbeaa: link becomes ready [ 570.870006] br-8faf6cb95741: port 2(veth3fcbeaa) entered blocking state [ 570.874333] br-8faf6cb95741: port 2(veth3fcbeaa) entered forwarding state [ 572.555320] eth0: renamed from vethb7b0199 [ 572.581041] IPv6: ADDRCONF(NETDEV_CHANGE): veth75b1ef3: link becomes ready [ 572.584993] br-8fa0fed72bf0: port 4(veth75b1ef3) entered blocking state [ 572.588752] br-8fa0fed72bf0: port 4(veth75b1ef3) entered forwarding state [ 575.757608] eth0: renamed from veth55404ed [ 575.777370] IPv6: ADDRCONF(NETDEV_CHANGE): veth3348892: link becomes ready [ 575.781477] br-8faf6cb95741: port 3(veth3348892) entered blocking state [ 575.785425] br-8faf6cb95741: port 3(veth3348892) entered forwarding state [ 579.384248] eth0: renamed from vethdd62334 [ 579.406715] IPv6: ADDRCONF(NETDEV_CHANGE): vethabeb253: link becomes ready [ 579.411269] br-8faf6cb95741: port 4(vethabeb253) entered blocking state [ 579.415641] br-8faf6cb95741: port 4(vethabeb253) entered forwarding state [ 649.519156] kauditd_printk_skb: 8 callbacks suppressed [ 649.519163] audit: type=1400 audit(1693550398.502:20): apparmor="DENIED" operation="capable" class="cap" profile="/usr/sbin/cupsd" pid=6365 comm="cupsd" capability=12 capname="net_admin" [22570.680650] systemd-journald[328]:
Bug#999458: zynaddsubfx: Feature Request: Integration of Zyn-fusion (new GUI)
Hi all, I'm adding some information here. By the way, some people tell that Zyn-fusion is not working well (see messages on http://lists.sourceforge.net/mailman/listinfo/zynaddsubfx-user). I didn't test it myself but upgrading to Zyn-fusion does not seem to be a priority. Caution here, if I'm not wrong, the upstream developement is on Zyn-Fusion rather than the oldish-GUI. Hence a few new features are only usable in the zyn-fusion GUI which can make it a priority. Another solution (if possible): compile two versions of zynaddsubfx, the "old" interface and the new one (zyn-fusion). Agreed here, that would be the best solution. Bye all and take care. Olivier
Bug#1040801: mcomix: pillow 10.0.0 not recognized as higher than 6.0.0
Hi,
On Mon, 10 Jul 2023 22:08:46 +0200 Sebastien KALT wrote:
Package: mcomix
Version: 2.1.0-2
Severity: grave
Justification: renders package unusable
Same issue here (Debian testing up to date).
The issue is here :
/usr/lib/python3/dist-packages/mcomix/run.py:
if PIL.__version__ < '6.0.0':
I guess that issue root cause is due to "<", who is probably not the
good way to compare strings under python. Python look like understand
that "6.0" is after "10.0", due to comparison-only between 6 and 1...
I'm not a python developer, so here a quick and dirty patch:
# diff /usr/lib/python3/dist-packages/mcomix/run.py.bak
/usr/lib/python3/dist-packages/mcomix/run.py
143c143
< if PIL.__version__ < '6.0.0':
---
> if PIL.__version__ < '10.0.0':
With this modification, mcomix work fine.
Real python developers, or packagers should provide a better and more
python-style than me ! :)
Best regards,
Olivier
Bug#1042544: systemd: Can't increase user default file descriptors (nofile) soft limit above 1024 for gnome-terminal.
Hello, Thanks for the warning, Luca Boccassi. I'm aware of the implications of increasing the soft limit. I read many discussions on the subject on the web while looking for a solution, and understand the rationale of the Debian decision to set the soft limit to 1024 and the hard limit to 1048576 in recent releases. I agree to that and expect that modern, non-select()-using applications set the soft limit themselves to deliberately indicate that they want more file descriptors. I filed a bug for Wine as it didn't work as expected in this case. (https://bugs.winehq.org/show_bug.cgi?id=55363) That should not be discussed here, though. What I report is that after changing every possible settings I could find documentation for on the web, the soft limit stays unchanged in the initial session of a freshly opened gnome-terminal in the graphical DE. The higher soft limit gets properly set everywhere else as expected, including opening a new session in the gnome-terminal with sudo to the same user, or temporarily setting the value with 'ulimit -n '. This means to me that something overrides the global settings from systemd & pam_limits.so in gnome-terminal initialization or a parent process, or that it takes a path that simply doesn't load the systemd/pam_limits settings. I would like to know if I simply missed something in my attempt to configure a higher soft limit, or if the issue lies within systemd or another component/application. How can I check that? Regards. P.S. Quoting the original message seems broken for me when using the 'reply' link on the Debian Bug page. The generated quote was limited to a few lines of my own quoted message in your reply. I removed it as it was meaningless. -- Olivier F. R. Dierick o.dier...@piezo-forte.be
Bug#1042449: libprotocol-http2-perl: Test-suite fails if OpenSSL configured with seclevel 2
On 7/28/23 13:48, gregor herrmann wrote: > On Fri, 28 Jul 2023 12:30:38 +0200, Olivier Gayot wrote: > >> Debian is currently unaffected (I assume the security level is set to 1 >> at build-time) but in the future OpenSSL 3.1 will reject TLSv1 at >> security level 1. > > Thanks for forwarding before this hits Debian! Anytime, thanks for applying the fix so quickly! Olivier
Bug#1042449: libprotocol-http2-perl: Test-suite fails if OpenSSL configured with seclevel 2
Package: libprotocol-http2-perl
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
Dear Maintainer,
The package uses the hardcoded tlsv1 value in its test-suite.
When OpenSSL has been built with security level 2 (or is set to level 2
at runtime), the TLSv1 protocol is rejected. This makes the
libprotocol-http2-perl build / autopkgtest fail.
There is an upstream bug report:
https://github.com/vlet/p5-Protocol-HTTP2/issues/15
And a PR was opened usptream:
https://github.com/vlet/p5-Protocol-HTTP2/pull/16
Debian is currently unaffected (I assume the security level is set to 1
at build-time) but in the future OpenSSL 3.1 will reject TLSv1 at
security level 1.
In Ubuntu, the attached patch was applied to achieve the following:
* Do not hardcode the test-suite TLS version to tlsv1 - which is disabled by
OpenSSL seclevel 2 on Ubuntu (LP: #2023586).
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers lunar-updates
APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'),
(100, 'lunar-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch
libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch
--- libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch 1970-01-01
01:00:00.0 +0100
+++ libprotocol-http2-perl-1.10/debian/patches/no-tlsv1.patch 2023-07-28
11:43:40.0 +0200
@@ -0,0 +1,32 @@
+Description: Remove hardcoded tlsv1 protocol version
+ The test-suite of libprotocol-http2-perl uses a hardcoded value of tlsv1 -
+ which is disabled in Ubuntu by means of OpenSSL seclevel. Specifying another
+ version like tlsv1_2 would work but it seems sensible to leave that up to the
+ system decide.
+Author: Olivier Gayot
+Bug-Ubuntu: https://launchpad.net/bugs/2023586
+Forwarded: https://github.com/vlet/p5-Protocol-HTTP2/pull/16
+Last-Update: 2023-07-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: b/t/lib/PH2ClientServerTest.pm
+===
+--- a/t/lib/PH2ClientServerTest.pm 2023-07-28 11:35:33.957861624 +0200
b/t/lib/PH2ClientServerTest.pm 2023-07-28 11:43:04.843734902 +0200
+@@ -43,7 +43,6 @@
+ if ( !$h{upgrade} && ( $h{npn} || $h{alpn} ) ) {
+ eval {
+ $tls = AnyEvent::TLS->new(
+-method=> 'tlsv1',
+ cert_file => $tls_crt,
+ key_file => $tls_key,
+ );
+@@ -122,7 +121,7 @@
+ }
+ elsif ( $h{npn} || $h{alpn} ) {
+ eval {
+-$tls = AnyEvent::TLS->new( method => 'tlsv1', );
++$tls = AnyEvent::TLS->new();
+
+ if ( delete $h{npn} ) {
+
diff -Nru libprotocol-http2-perl-1.10/debian/patches/series
libprotocol-http2-perl-1.10/debian/patches/series
--- libprotocol-http2-perl-1.10/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ libprotocol-http2-perl-1.10/debian/patches/series 2023-07-28
11:43:11.0 +0200
@@ -0,0 +1 @@
+no-tlsv1.patch
Bug#1042079: onednn 2.7.4-1 FTBFS on arm64
Package: onednn
Version: 2.7.4-1
Followup-For: Bug #1042079
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
Control: tags -1 patch
Dear Maintainer,
In Ubuntu, the attached patch was applied to achieve the following:
* Apply upstream patches to fix build on arm64 (LP: #2028759)
+
d/patches/lp2028759/cpu-aarch64-update-xbyak_aarch64-into-the-lastes-ver(1).patch
+ d/patches/lp2028759/cpu-aarch64-fix-getting-cache-sizes-on-macOS.patch
+
d/patches/lp2028759/cpu-aarch64-update-xbyak_aarch64-into-the-lastes-ver(2).patch
The second patch (macOS specific) is not essential but allows the third
patch to apply with fewer modifications.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers lunar-updates
APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'),
(100, 'lunar-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-fix-getting-cache-sizes-on-macOS.patch
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-fix-getting-cache-sizes-on-macOS.patch
---
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-fix-getting-cache-sizes-on-macOS.patch
1970-01-01 01:00:00.0 +0100
+++
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-fix-getting-cache-sizes-on-macOS.patch
2023-07-26 12:14:38.0 +0200
@@ -0,0 +1,49 @@
+Description: cpu: aarch64: fix getting cache sizes on macOS
+ Notes from ogayot: This is not strictly needed for Ubuntu but allows the
+ subsequent patch (i.e.,
+ cpu-aarch64-update-xbyak_aarch64-into-the-latest-ver(2).patch) to apply
without
+ too many modifications.
+Author: Denis Samoilov
+Bug-Ubuntu: https://launchpad.net/bugs/2028759
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042079
+Forwarded: not-needed
+Applied-Upstream:
https://github.com/oneapi-src/oneDNN/commit/ba91a536cb59558b3f3880951def160fe24b2820
+Last-Update: 2023-07-26
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/src/cpu/aarch64/xbyak_aarch64/src/util_impl.cpp
b/src/cpu/aarch64/xbyak_aarch64/src/util_impl.cpp
+index 59f712c7b..cb800b250 100644
+--- a/src/cpu/aarch64/xbyak_aarch64/src/util_impl.cpp
b/src/cpu/aarch64/xbyak_aarch64/src/util_impl.cpp
+@@ -52,17 +52,25 @@ void Cpu::setCacheHierarchy() {
+ }
+ } else {
+ /**
+- * @ToDo Get chache information by `sysconf`
++ * @ToDo Get cache information by `sysconf`
+ * for the case thd dictionary is unavailable.
+ */
++
++// _SC_LEVEL_DCACHE_SIZE macros are not defined on macOS.
++#if defined(__APPLE__)
++#define GET_CACHE_SIZE(ID) 0
++#else
++#define GET_CACHE_SIZE(ID) sysconf(ID)
++#endif
++
+ #define XBYAK_AARCH64_CACHE_SIZE(LEVEL, SIZE, ID, CORES, VAL)
\
+- cache_size = sysconf(ID);
\
++ cache_size = GET_CACHE_SIZE(ID);
\
+ VAL[LEVEL] = cache_size ? (cache_size / (CORES)) : ((SIZE) / (CORES));
+
+ uint32_t cache_size;
+
+ /* If `sysconf` returns zero as cache sizes, 32KiB, 1MiB, 0 and 0 is set
as
+- 1st, 2nd, 3rd and 4th level cache sizes. 2nd cahce is assumed as
sharing cache. */
++ 1st, 2nd, 3rd and 4th level cache sizes. 2nd cache is assumed as
sharing cache. */
+ XBYAK_AARCH64_CACHE_SIZE(0, 1024 * 32, _SC_LEVEL1_DCACHE_SIZE, 1,
coresSharingDataCache_);
+ XBYAK_AARCH64_CACHE_SIZE(1, 1024 * 1024, _SC_LEVEL2_CACHE_SIZE, 1,
coresSharingDataCache_);
+ XBYAK_AARCH64_CACHE_SIZE(2, 0, _SC_LEVEL3_CACHE_SIZE, 1,
coresSharingDataCache_);
+--
+2.39.2
+
diff -Nru
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-update-xbyak_aarch64-into-the-latest-ver(1).patch
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-update-xbyak_aarch64-into-the-latest-ver(1).patch
---
onednn-2.7.4/debian/patches/lp2028759/cpu-aarch64-update-xbyak_aarch64-into-the-latest-ver(1).patch
Bug#1042079: onednn 2.7.4-1 FTBFS on arm64
Source: onednn Version: 2.7.4-1 Severity: normal Dear Maintainer, Building onednn 2.7.4-1 on arm64 fails with many of the following errors: In file included from /<>/src/cpu/aarch64/xbyak_aarch64/src/xbyak_aarch64_impl.cpp:17: /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:70:7: error: ‘uint64_t’ does not name a type 70 | const uint64_t SP_IDX = 31; | ^~~~ /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:56:1: note: ‘uint64_t’ is defined in header ‘’; did you forget to ‘#include ’? 55 | #include +++ |+#include 56 | /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:71:7: error: ‘uint64_t’ does not name a type 71 | const uint64_t NUM_VREG_BYTES = 16; | ^~~~ /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:71:7: note: ‘uint64_t’ is defined in header ‘’; did you forget to ‘#include ’? /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:72:7: error: ‘uint64_t’ does not name a type 72 | const uint64_t NUM_ZREG_BYTES = 64; | ^~~~ /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:72:7: note: ‘uint64_t’ is defined in header ‘’; did you forget to ‘#include ’? In file included from /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64_adr.h:19, from /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64_gen.h:21, from /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64.h:73: /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64_reg.h:96:3: error: ‘uint32_t’ does not name a type 96 | uint32_t bit_; | ^~~~ /<>/src/cpu/aarch64/xbyak_aarch64/xbyak_aarch64/xbyak_aarch64_reg.h:19:1: note: ‘uint32_t’ is defined in header ‘’; did you forget to ‘#include ’? Build log: https://buildd.debian.org/status/fetch.php?pkg=onednn=arm64=2.7.4-1=1689851490=0 There is an existing bug report upstream and the issue seems to have been fixed in onednn 3.1: https://github.com/oneapi-src/oneDNN/issues/1600 Thanks, Oilvier -- System Information: Debian Release: bookworm/sid APT prefers lunar-updates APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), (100, 'lunar-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1037454: zulucrypt autopkgtests fail
Package: zulucrypt Followup-For: Bug #1037454 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu mantic ubuntu-patch Control: tags -1 patch Dear Maintainer, The test-suite seems to fail on virt-servers that use sudo to run as root. For some reason, zuluCrypt reads the SUDO_UID variable and calls seteuid(SUDO_UID) if it exists - before attemping to open the test luks file (that was created as root earlier). I opened an upstream bug report: https://github.com/mhogomchungu/zuluCrypt/issues/209 Unsetting the SUDO_UID variable helps making the autopkgtest succeeds - although it does not prevent somebody from manually invoking $ sudo /usr/bin/zuluCrypt-cli --test on the target system In Ubuntu, the attached patch was applied to achieve the following: * Unset SUDO_UID when running the test suite - to make autopkgtest succeed on all virt-servers (LP: #2023614). Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers lunar-updates APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), (100, 'lunar-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru zulucrypt-6.2.0/debian/tests/control zulucrypt-6.2.0/debian/tests/control --- zulucrypt-6.2.0/debian/tests/control2022-09-19 04:02:31.0 +0200 +++ zulucrypt-6.2.0/debian/tests/control2023-07-25 09:44:49.0 +0200 @@ -1,2 +1,2 @@ -Test-Command: zuluCrypt-cli --test +Test-Command: env -u SUDO_UID zuluCrypt-cli --test Restrictions: allow-stderr,isolation-machine,needs-root
Bug#1040566: let logol be removed
Le mer. 19 juil. 2023, 06:58, Andreas Tille a écrit : > Hi Olivier, > > Am Mon, Jul 17, 2023 at 12:13:30PM +0200 schrieb olivier sallou: > > logol is not maintained anymore for quite some time now > > > > effort to keep in line with swi-prolog updates (need to recompile on each > > ABI break of swi-prolog) AND biojava requires frequent work for an old > > software with low usage. > > > > I would let it be removed > > You introduced the package so you know its usage best. I think any > removal should be announced on debian-med@l.d.o which I'm doing hereby. > > IMHO if the fix would be "simple" (in terms of needs only less than > 10min) keeping it might be worth it. Otherwise its a good time in the > beginning of the release process to remove packages that just drain > developer resources and do not serve a mentionable amount of users. > It would require analysis and many updates, so quite some efforts for unmaintained software and targetting low number of users (sure of that), so i am for removal. Olivier > > Kind regards > Andreas. > > -- > http://fam-tille.de > >
Bug#1040566: biojava not shipping biojava.jar anymore
seems biojava now ships several jar files (core, biosql, ...) and not a bundle anymore, used by logol, see list of jar files available: https://packages.debian.org/sid/all/libbiojava1.9-java/filelist would need to patch logol to import/load expected jar files (and find which ones are needed...) in command line tools
Bug#1040566: let it be removed
logol is not maintained anymore for quite some time now effort to keep in line with swi-prolog updates (need to recompile on each ABI break of swi-prolog) AND biojava requires frequent work for an old software with low usage. I would let it be removed -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1040348: gnucash 5.1 fails to run finance-quote
Hi Doug,
same issue here.
Nevertheless, I'd find a way to fix it:
- the file exist into Debian source repository
- so download
http://deb.debian.org/debian/pool/main/g/gnucash/gnucash_5.1.orig.tar.xz
see https://packages.debian.org/source/trixie/gnucash for information
- uncompress it: tar xJvf gnucash_5.1.orig.tar.xz
gnucash-5.1/libgnucash/quotes/finance-quote-wrapper.in
- apply attached patch (because the "finance-quote-wrapper.in" is not a
ready to use perl script)
- copy new "finance-quote-wrapper" into /usr/bin/finance-quote-wrapper
- you can test result into you gnucash, or with simple test:
gnucash-cli --quotes info
gnucash-cli --quotes dump alphavantage IBM
Regards,
Olivier1c1
< #!@PERL@ -w
---
> #!/usr/bin/perl -w
9,19c9,19
< ###
< ### This program is free software; you can redistribute it and/or
< ### modify it under the terms of the GNU General Public License as
< ### published by the Free Software Foundation; either version 2 of
< ### the License, or (at your option) any later version.
< ###
< ### This program is distributed in the hope that it will be useful,
< ### but WITHOUT ANY WARRANTY; without even the implied warranty of
< ### MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
< ### GNU General Public License for more details.
< ###
---
> ###
> ### This program is free software; you can redistribute it and/or
> ### modify it under the terms of the GNU General Public License as
> ### published by the Free Software Foundation; either version 2 of
> ### the License, or (at your option) any later version.
> ###
> ### This program is distributed in the hope that it will be useful,
> ### but WITHOUT ANY WARRANTY; without even the implied warranty of
> ### MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ### GNU General Public License for more details.
> ###
30,72d29
<
< =head1 NAME
<
< finance-quote-wrapper - internal interface between gnucash and Finance::Quote
<
< =head1 SYNOPSIS
<
< finance-quote-wrapper
<
< =head1 DESCRIPTION
<
< Input: a JSON encoded hash of namespaces and commodities to query prices for.
< Currencies all go under the "currency' namespace, other commodities are
< grouped according to the quotes source they should be queried from
< There should also be a "defaultcurrency" key with the currency to be used as
< base currency for currency quotes.
<
< {
< "defaultcurrency": "EUR",
< "currency": {
< "XAG": "",
< "HKD": "",
< "USD": ""
< },
< "yahoo_json": {
< "CSCO": ""
< }
< }
<
< Output (on standard output):
<
< The retrieved quotes in JSON format for further processing. These are
< the raw values returned by Finance::Quote. The caller is responsible for
< parsing and interpreting the results.
<
< If there are program failures, an error message will be printed on standard error.
<
< Exit status
<
< 0 - success
< non-zero - failure
<
< =cut
Bug#910273: severity of 910273 is important
Hi. Ouch, I had lst track myself of this issue. Obviously it kinda solved itself in between (or I have a disk filling-up unnoticed ;-). I guess we can probably close now (Oh, I don't remember how to close properly in the BTS when no longer applicable :-/). Thanks for caring. Best regards, Yves-Alexis Perez writes: > On Fri, Oct 05, 2018 at 04:14:41PM +0200, Olivier Berger wrote: >> severity 910273 important >> thanks >> >> I wasn't quite sure, but the impact is quite nasty, so raising severity >> in the hope someone more knowledgable has hints on the likeliness it may >> happen to anyone else in the next stable... > > Hey Olivier, it seems this one went under my radar for a *long time*. > Did it get solved in the end? I never experienced this one myself. > > Regards, > -- > Yves-Alexis Perez > -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1039562: package install error is "fine"
Installation shows an "error" because it tries to connect to database with configuration defaults (will fail at first install if default user/password does not exists in database, and this is fine). In case of "failure" using found configuration (/usr/share/gmod/chado/conf/gmod-chado.conf) , it explains the expected setup steps to user and exists with code 0. So "error" is not a real error , but just an install setup test to check if user need to configure database access, and exit as expected with error code 0 (and package is installed as expected). -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1040243: php-doctrine-cache: test-suite fails when using php-cache-integration-tests 0.17.0-4 (experimental)
Package: php-doctrine-cache Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu mantic ubuntu-patch Dear Maintainer, php-doctrine-cache requires php-cache-tag-interop which used to be provided by php-cache-integration-tests. Starting with php-cache-integration-tests 0.17.0-4, the dependency on php-cache-tag-interop was dropped so the dependencies of php-doctrine-cache are no longer satisfied. In Ubuntu, the attached patch was applied to achieve the following: * Merge with Debian unstable (LP: #2025673). Remaining changes: - d/control: Add b-d for php-cache-tag-interop removed from php-cache-integration-tests. - d/t/control: Add test dependency on php-cache-tag-interop removed from php-cache-integration-tests. Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers lunar-updates APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), (100, 'lunar-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru php-doctrine-cache-2.2.0/debian/control php-doctrine-cache-2.2.0/debian/control --- php-doctrine-cache-2.2.0/debian/control 2023-06-25 10:20:40.0 +0200 +++ php-doctrine-cache-2.2.0/debian/control 2023-07-03 19:47:31.0 +0200 @@ -7,6 +7,7 @@ memcached, php-apcu, php-cache-integration-tests, + php-cache-tag-interop, php-memcache, php-memcached, php-psr-cache, diff -Nru php-doctrine-cache-2.2.0/debian/tests/control php-doctrine-cache-2.2.0/debian/tests/control --- php-doctrine-cache-2.2.0/debian/tests/control 2022-10-17 08:08:20.0 +0200 +++ php-doctrine-cache-2.2.0/debian/tests/control 2023-07-03 19:47:31.0 +0200 @@ -3,6 +3,7 @@ Depends: memcached, php-apcu, php-cache-integration-tests, + php-cache-tag-interop, php-memcache, php-memcached, php-psr-cache,
Bug#1038890: pyparted: Testsuite fails against parted 3.6
Package: pyparted
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
Dear Maintainer,
Running the pyparted test-suite against parted 3.6 leads to the
following exception:
399s ==
399s FAIL: runTest (tests.test__ped_disktype.DiskTypeStrTestCase.runTest)
399s --
399s Traceback (most recent call last):
399s File
"/tmp/autopkgtest.kQxzZO/build.bFs/src/tests/test__ped_disktype.py", line 78,
in runTest
399s self.assertEqual(str(self.disktype['msdos']), '_ped.DiskType instance
--\n name: msdos features: 1')
399s AssertionError: '_ped.DiskType instance --\n name: msdos features: 5' !=
'_ped.DiskType instance --\n name: msdos features: 1'
399s _ped.DiskType instance --
399s - name: msdos features: 5? ^
399s + name: msdos features: 1? ^
The failure is visible in the following autopkgtest report.
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pyparted/34699773/log.gz
A patch exists upstream: https://github.com/dcantrell/pyparted/pull/100
In Ubuntu, the attached patch was applied to achieve the following:
* Apply upstream patch to fix test-suite against parted 3.6 (LP: #2024678)
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers lunar-updates
APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'),
(100, 'lunar-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
pyparted-3.12.0/debian/patches/0001-tests-Remove-feature-values-from-DiskTypeStrTestCase.patch
pyparted-3.12.0/debian/patches/0001-tests-Remove-feature-values-from-DiskTypeStrTestCase.patch
---
pyparted-3.12.0/debian/patches/0001-tests-Remove-feature-values-from-DiskTypeStrTestCase.patch
1970-01-01 01:00:00.0 +0100
+++
pyparted-3.12.0/debian/patches/0001-tests-Remove-feature-values-from-DiskTypeStrTestCase.patch
2023-06-22 18:08:47.0 +0200
@@ -0,0 +1,43 @@
+Description: tests: Remove feature values from DiskTypeStrTestCase
+ These inevitably cause pyparted to fail when built against a new version
+ of parted. They don't provide any additional validation, other tests
+ already check for the expected features.
+Author: "Brian C. Lane"
+Origin: upstream, https://github.com/dcantrell/pyparted/pull/100
+Bug-Ubuntu: https://launchpad.net/bugs/2024678
+Last-Update: 2023-06-22
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: pyparted-3.12.0/tests/test__ped_disktype.py
+===
+--- pyparted-3.12.0.orig/tests/test__ped_disktype.py 2023-06-22
18:02:36.965289725 +0200
pyparted-3.12.0/tests/test__ped_disktype.py2023-06-22
18:05:14.716398913 +0200
+@@ -75,13 +75,18 @@
+
+ class DiskTypeStrTestCase(RequiresDiskTypes):
+ def runTest(self):
+-self.assertEqual(str(self.disktype['msdos']), '_ped.DiskType instance
--\n name: msdos features: 1')
+-self.assertEqual(str(self.disktype['aix']), '_ped.DiskType instance
--\n name: aix features: 0')
+-self.assertEqual(str(self.disktype['sun']), '_ped.DiskType instance
--\n name: sun features: 0')
+-self.assertEqual(str(self.disktype['amiga']), '_ped.DiskType instance
--\n name: amiga features: 2')
+-self.assertEqual(str(self.disktype['gpt']), '_ped.DiskType instance
--\n name: gpt features: 2')
+-self.assertEqual(str(self.disktype['mac']), '_ped.DiskType instance
--\n name: mac features: 2')
+-self.assertEqual(str(self.disktype['bsd']), '_ped.DiskType instance
--\n name: bsd features: 0')
+-self.assertEqual(str(self.disktype['pc98']), '_ped.DiskType instance
--\n name: pc98 features: 2')
+-self.assertEqual(str(self.disktype['loop']), '_ped.DiskType instance
--\n name: loop features: 0')
+-self.assertEqual(str(self.disktype['dvh']), '_ped.DiskType instance
--\n name: dvh features: 3')
++types = {
++"msdos": '_ped.DiskType instance --\n name: msdos features:',
++'aix': '_ped.DiskType instance --\n name: aix features: ',
++'sun': '_ped.DiskType instance --\n name: sun features: ',
++'amiga': '_ped.DiskType instance --\n name: amiga features: ',
++'gpt': '_ped.DiskType instance --\n name: gpt features: ',
++'mac': '_ped.DiskType instance --\n name: mac features: ',
++'bsd': '_ped.DiskType instance --\n name: bsd features: ',
++
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
Le Mon, Jun 12, 2023 at 12:49:25PM +0200, Olivier Berger a écrit : > Hi. > > I can confirm the reproduction of the same kind of crash, this time without > wifi activated. > > It seems to occur whenever I'm away from the machine for a while, probably > linked to screen saving condition. > For the records, the video card is reported as "00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)", offering a HDMI port (on Dell HP ProBook laptop), on which I connect a screen via an HDMI to Display Port adapter. I suspect some kind of weird corner case linked to that adapter, which is the "HDMI to DisplayPort Adapter - 4K Ready" from Cable Matters (https://www.cablematters.com/pc-825-139-hdmi-to-displayport-adapter-4k-ready.aspx ) Just my 2 more cents, -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
Hi. I can confirm the reproduction of the same kind of crash, this time without wifi activated. It seems to occur whenever I'm away from the machine for a while, probably linked to screen saving condition. Hope this helps, Le Fri, Jun 09, 2023 at 08:58:52AM +0200, Olivier Berger a écrit : > > As a followup, I've been able to get another crash, this time when netconsole > was on, and got a bunch of traces, in the attached logs. > > Hope this helps identify the culprit... probably i915/drm ? > > The title of the bug report should be changed, but I'm not sure how best to > retitle. > -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) [ 1192.922330] netpoll: netconsole: local port [ 1192.922341] netpoll: netconsole: local IPv4 address 192.168.1.32 [ 1192.922345] netpoll: netconsole: interface 'enp2s0' [ 1192.922347] netpoll: netconsole: remote port [ 1192.922350] netpoll: netconsole: remote IPv4 address 192.168.1.25 [ 1192.922352] netpoll: netconsole: remote ethernet address 38:2c:4a:b1:63:94 [ 1192.922461] printk: console [netcon0] enabled [ 1192.922468] netconsole: network logging started [ 1793.154776] mce: CPU#1: Unexpected int18 (Machine Check) [ 1793.154809] mce: CPU#5: Unexpected int18 (Machine Check) [ 1794.400586] [ cut here ] [ 1794.400600] DPLL 0 assertion failure (expected on, current off) [ 1794.400763] WARNING: CPU: 1 PID: 1163 at drivers/gpu/drm/i915/display/intel_dpll_mgr.c:191 assert_shared_dpll+0x10a/0x120 [i915] [ 1794.400977] Modules linked in: netconsole xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) ctr ccm rfcomm snd_seq_dummy snd_hrtimer snd_seq cmac algif_hash algif_skcipher af_alg qrtr cpufreq_ondemand cpufreq_conservative cpufreq_powersave overlay squashfs cpufreq_userspace bnep binfmt_misc snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_soc_dmic snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp iwlmvm snd_sof snd_sof_utils snd_soc_hdac_hda x86_pkg_temp_thermal snd_hda_ext_core intel_powerclamp snd_soc_acpi_intel_match coretemp mac80211 snd_soc_acpi snd_soc_core [ 1794.401079] mei_hdcp snd_compress soundwire_bus intel_rapl_msr btusb libarc4 btrtl pmt_telemetry pmt_class btbcm btintel btmtk bluetooth kvm_intel snd_hda_intel snd_intel_dspcfg iwlwifi kvm uvcvideo jitterentropy_rng snd_intel_sdw_acpi irqbypass cfg80211 snd_usb_audio videobuf2_vmalloc snd_hda_codec videobuf2_memops drbg snd_usbmidi_lib videobuf2_v4l2 ansi_cprng snd_hda_core hp_wmi processor_thermal_device_pci_legacy rapl snd_rawmidi processor_thermal_device videobuf2_common nls_ascii platform_profile ecdh_generic snd_hwdep iTCO_wdt snd_seq_device processor_thermal_rfim intel_cstate ucsi_acpi intel_uncore snd_pcm videodev snd_timer typec_ucsi pcspkr nls_cp437 processor_thermal_mbox processor_thermal_rapl intel_pmc_bxt vfat mei_me snd roles intel_rapl_common iTCO_vendor_support fat wmi_bmof ee1004 mc int3403_thermal watchdog soundcore ecc mei rfkill intel_vsec typec joydev igen6_edac intel_soc_dts_iosf int340x_thermal_zone ac intel_hid int3400_thermal intel_pmc_core acpi_thermal_rel [ 1794.401185] sparse_keymap acpi_pad hid_multitouch evdev serio_raw nfsd auth_rpcgss msr parport_pc nfs_acl ppdev lockd lp grace parport fuse loop dm_mod efi_pstore configfs sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 hid_logitech_hidpp hid_logitech_dj usbhid btrfs blake2b_generic zstd_compress efivarfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod i915 nvme drm_buddy crc32_pclmul i2c_algo_bit crc32c_intel nvme_core drm_display_helper t10_pi hid_generic xhci_pci ghash_clmulni_intel xhci_hcd cec crc64_rocksoft_generic rc_core rtsx_pci_sdmmc crc64_rocksoft crc_t10dif ttm crct10dif_generic mmc_core usbcore i2c_i801 drm_kms_helper r8169 intel_lpss_pci intel_lpss i2c_hid_acpi realtek i2c_hid crct10dif_pclmul crc64 mdio_devres aesni_intel drm crypto_simd cryptd libphy rtsx_pci i2c_smbus crct10dif_common idma64 vmd usb_common battery hid video wmi button sha512_ssse3 [ 1794.401312] sha512_generic [ 1794.401328] CPU: 1 PID: 1163 Comm: Xorg Tainted: G OE 6.1.0-9-amd64 #1 Debian 6.1.27-1 [ 1794.401339] Hardware name: HP HP ProBook 450 G8 Notebook PC/87E1, BIOS T70 Ver. 01.13.01 03/30/2023 [ 1794.401346] RIP: 0010:assert_shared_dpll+0x10a/0x120 [i915]
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
Hi.
As a followup, I've been able to get another crash, this time when netconsole
was on, and got a bunch of traces, in the attached logs.
Hope this helps identify the culprit... probably i915/drm ?
The title of the bug report should be changed, but I'm not sure how best to
retitle.
Best regards,
Le Wed, May 24, 2023 at 01:35:31PM +0200, Olivier Berger a écrit :
> The i915 hint is interesting.
>
> Salvatore Bonaccorso writes:
>
> >
> > Would you be able to bisect the changes between 6.1.20 and 6.1.27 to
> > identify the culprit, though not instantntly triggerable? Maybe
> > focusing around the i915 changes, I stumpled over a2b6e99d8a62
> > ("drm/i915: Disable DC states for all commits") which was backported
> > to 6.1.23.
> >
--
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
[ 118.158855] netpoll: netconsole: local port
[ 118.158865] netpoll: netconsole: local IPv4 address 192.168.0.35
[ 118.158870] netpoll: netconsole: interface 'wlp0s20f3'
[ 118.158872] netpoll: netconsole: remote port
[ 118.158874] netpoll: netconsole: remote IPv4 address 192.168.0.47
[ 118.158877] netpoll: netconsole: remote ethernet address 38:2c:4a:b1:63:94
[ 118.159010] [ cut here ]
[ 118.159012] WARNING: CPU: 3 PID: 3290 at net/mac80211/tx.c:3723
ieee80211_tx_dequeue+0xcb3/0xd30 [mac80211]
[ 118.159102] Modules linked in: netconsole(+) xt_conntrack nft_chain_nat
xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink
br_netfilter bridge stp llc vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) ctr ccm
rfcomm snd_seq_dummy snd_hrtimer snd_seq cmac algif_hash algif_skcipher af_alg
squashfs cpufreq_ondemand qrtr cpufreq_conservative cpufreq_powersave overlay
bnep cpufreq_userspace hid_logitech_hidpp binfmt_misc nls_ascii nls_cp437 vfat
fat snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common
snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_hdmi hid_logitech_dj
snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_soc_dmic
snd_sof_pci_intel_tgl iwlmvm snd_sof_intel_hda_common btusb btrtl btbcm btintel
soundwire_intel btmtk soundwire_generic_allocation mac80211 soundwire_cadence
snd_sof_intel_hda snd_sof_pci bluetooth snd_sof_xtensa_dsp snd_sof
snd_usb_audio snd_sof_utils
[ 118.159163] snd_soc_hdac_hda libarc4 snd_hda_ext_core
snd_soc_acpi_intel_match snd_usbmidi_lib snd_soc_acpi snd_rawmidi
x86_pkg_temp_thermal intel_powerclamp usbhid snd_seq_device snd_soc_core
iwlwifi coretemp snd_compress jitterentropy_rng soundwire_bus joydev drbg
snd_hda_intel mei_hdcp kvm_intel snd_intel_dspcfg snd_intel_sdw_acpi
pmt_telemetry snd_hda_codec intel_rapl_msr pmt_class ansi_cprng uvcvideo
cfg80211 kvm snd_hda_core hp_wmi videobuf2_vmalloc snd_hwdep platform_profile
irqbypass ecdh_generic videobuf2_memops videobuf2_v4l2 snd_pcm
processor_thermal_device_pci_legacy processor_thermal_device rapl
processor_thermal_rfim videobuf2_common processor_thermal_mbox snd_timer
iTCO_wdt intel_cstate processor_thermal_rapl ucsi_acpi intel_uncore videodev
typec_ucsi intel_pmc_bxt snd iTCO_vendor_support roles mei_me intel_rapl_common
mc pcspkr ecc wmi_bmof ee1004 watchdog soundcore mei rfkill intel_vsec
igen6_edac typec intel_soc_dts_iosf int3403_thermal int340x_thermal_zone
[ 118.159218] int3400_thermal acpi_thermal_rel intel_hid sparse_keymap
intel_pmc_core acpi_pad ac hid_multitouch serio_raw evdev nfsd msr parport_pc
auth_rpcgss ppdev nfs_acl lockd lp grace parport fuse loop dm_mod efi_pstore
configfs sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs
blake2b_generic zstd_compress efivarfs raid10 raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic
raid1 raid0 multipath linear md_mod i915 drm_buddy i2c_algo_bit crc32_pclmul
drm_display_helper nvme crc32c_intel nvme_core cec hid_generic rc_core
rtsx_pci_sdmmc t10_pi ghash_clmulni_intel mmc_core ttm i2c_hid_acpi
crc64_rocksoft_generic crc64_rocksoft drm_kms_helper r8169 crc_t10dif realtek
xhci_pci mdio_devres crct10dif_generic i2c_hid aesni_intel xhci_hcd
intel_lpss_pci crct10dif_pclmul crypto_simd i2c_i801 intel_lpss crc64 cryptd
drm usbcore i2c_smbus libphy rtsx_pci crct10dif_common idma64 usb_common vmd
hid battery video wmi button
[ 118.159289] sha512_ssse3 sha512_generic
[ 118.159292] CPU: 3 PID: 3290 Comm: modprobe Tainted: G OE
6.1.0-9-amd64 #1 Debian 6.1.27-1
[ 118.159298] Hardware name: HP HP ProBook 450 G8 Notebook PC/87E1, BIOS T70
Ver. 01.13.01 03/30/2023
[ 118.159300] RIP: 0010:ieee80211_tx_dequeue+0xcb3/0xd30 [mac80211]
[ 118.159374] Code: ff ff 01 ce 48 89 ef 29 d6 e8 09 ab 35 d5 48 85 c0 0f 84
23 f8 ff ff 0f b7 85 b8 00 0
Bug#990336: This still affects the current bullseye package
Hi Le Thu, Jul 28, 2022 at 12:59:18PM +0100, Athanasius a écrit : > I've just noticed this myself. Our smtp.log is from 2020-08-08 > onwards, so almost 2 years worth of logging. It's 28 MiB in size, so > not disasterously big. > > I've added specific rotation of the other logfiles manually for now. > Would you mind sharing the snippet that you used for the logrotate config ? It seems that maybe the smtp.log file might need special treatment, if I refer to the discussion at https://gitlab.com/mailman/mailman/-/issues/931 (following https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/RRFWGZY56OHAXPRCIQD5RLU3SLW5W2LH/ ) Hope this helps, Best regards, -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1031046: Asterisk packaging
Hello, I lately discovered this thread. I volunteer to help to package Asterisk either in current official Debian repo or in an alternative repository. The perspectives of Asterisk Deb packaging is talked about in [1] (I'm the original author of this thread). One thing that comes to mind reading [1] is that several people recommend packaging from scratch while it seems to me, that contributing in coordinated activities may lower the amount of work (no need to build a repo, to configure host to use a custom repo, ...) and increase the outcome quality as Debian standards are quite high. If having Asterisk distributed with Bookwom is a lost cause, maybe we can try to have latest Asterisk 20.3 be packaged "the Debian way" in unstable repo and self assign the goal that this build would done by new contributors, under the control of experienced mainteners ? Then, what could be the best media to read or add doc about Asterisk packaging ? [1] https://community.asterisk.org/t/status-and-perspectives-of-asterisk-package-on-debian-bookworm/97087/11 Regards
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
Hi.
I'm afraid this would be much beyond my capacity, sorry.
The i915 hint is interesting.
Thanks.
Best regards,
Salvatore Bonaccorso writes:
> Control: tags -1 + moreinfo
>
> Hi Olivier,
>
>
> Would you be able to bisect the changes between 6.1.20 and 6.1.27 to
> identify the culprit, though not instantntly triggerable? Maybe
> focusing around the i915 changes, I stumpled over a2b6e99d8a62
> ("drm/i915: Disable DC states for all commits") which was backported
> to 6.1.23.
>
> Regards,
> Salvatore
>
--
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
Hi. Diederik de Haas writes: > > The stack traces should be useful for someone who understands those (which > isn't me), but I did notice several other items: > > - [ 465.284645] GPT: Use GNU Parted to correct GPT errors > That happened after you plugged in an USB drive? > I would follow that advice, but it would be useful to get that USB drive > 'out of the equation'. > Does the issue also occur when that USB drive isn't used? > The kernel seems to assign both sda and sdb before settling on sda(1)? > Not sure what to make of that, but it doesn't look good > I guess the USB drive has nothing to do with the issue, AFAIU. Actually, I just wanted to be sure that netconsole was indeed capturing kernel events, as suggested by a howto on remote debugging of kernel panics with netconsole. And FYI, this is a USB key that embeds a SD card reader, hence the 2 drives that popup... as for GPT, dunno, maybe a formatting mistake. In any case, the laptop crashed in the past whenever no such USB key was being plugged. > - [ 535.857315] EXT4-fs (dm-0): recovery complete > I can understand a FS recovery when you're dealing with a freeze/crash, > but I find the timing a 'bit' unusual. After 9.5 minutes, I doubt it's the > primary/boot drive (and we had the USB drive before that), so where > is that coming from? > Thats a LUKS partition being mounted after a while by me, for secrets stored on the hard drive in a dedicated partition. As the laptop crashed in the previous execution with the partition mounted, it explains the FS recovery at mount time. Nothing strange here either. > - [ 543.576681] systemd-journald[428]: Sent WATCHDOG=1 notification > I'm not really sure what that means, but afaik a watchdog is used to > (automatically) reboot the machine if the system hangs. > So seeing that message numerous times, is worrisome. And it looks like it > doesn't do its actual job? > I booted with 'debug ignore_loglevel' as kernel arguments... maybe that explains the occurence of such logs... dunno exactly if this is worrysome. > - BIOS T70 Ver. 01.13.01 03/30/2023 > Can you check whether there is a newer BIOS version available? > I believe 'NMI' is BIOS related, so it may have an effect. I just updated the HP BIOS to the latest available the last day, but crashes were occuring before too... maybe related, but nothing can be updated more for the moment, at least from what the Windows HP Support Assistant can show. Thanks for your help. Best regards, -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
Hi. Just in order to provide a bit more useful hints, maybe, the latest version working fine is linux-image-6.1.0-7-amd64 as 6.1.20-2. Sorry about the lack of clarity in the initial report. Le Tue, May 23, 2023 at 06:49:00PM +0200, Olivier Berger a écrit : > > I'm experiencing crashes (computer reset or completely shutting down) without > much details available on why. It used to work fine with 6.1.0-7 but has had > problems with the 2 later updates of the testing kernel. > > I've managed to get a log of the kernel panic with netconsole (otherwise > wouldn't get any hints whatsoever in logs on disks after restarting), bellow. > > I guess this is nasty as being close to the freeze. I've had the issue for a > few days now, but only managed to test a netconsole remote log today. > > It seems to me that the crash mainly happen when I'm away from the laptop for > several minutes, so maybe related to some kind of energy saving stuff... > > Hope this provides enough details to help. > -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1036644: linux-image-6.1.0-9-amd64: System crashes. Netconsole reports CPUs not responding to MCE broadcast
D 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 007: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 003 Device 006: ID 0c45:6341 Microdia Defender G-Lens 2577 HD720p Camera Bus 003 Device 005: ID 0d8c:0134 C-Media Electronics, Inc. BIRD UM1 Bus 003 Device 003: ID 05e3:0610 Genesys Logic, Inc. Hub Bus 003 Device 002: ID 0408:5374 Quanta Computer, Inc. HP HD Camera Bus 003 Device 004: ID 8087:0026 Intel Corp. AX201 Bluetooth Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-6.1.0-9-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.142 ii kmod30+20221128-1 ii linux-base 4.9 Versions of packages linux-image-6.1.0-9-amd64 recommends: ii apparmor 3.0.8-3 ii firmware-linux-free 20200122-1 Versions of packages linux-image-6.1.0-9-amd64 suggests: pn debian-kernel-handbook ii extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1 ii grub-efi-amd64 2.06-12 pn linux-doc-6.1 Versions of packages linux-image-6.1.0-9-amd64 is related to: ii firmware-amd-graphics 20230210-5 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium ii firmware-intel-sound 20230210-5 pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20230210-5 pn firmware-libertas ii firmware-linux-nonfree20230210-5 ii firmware-misc-nonfree 20230210-5 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20230210-5 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- debconf-show failed -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1036289: dicomscope: Please do not depend on default jre
Package: dicomscope Version: 3.6.0-25 Severity: normal X-Debbugs-Cc: olivier.caill...@gmail.com Dear Maintainer, dicomscope should be satisfied with any sufficiently recent JRE, not just with default-jre. As an example, I have JRE 17 installed but dicomscope wants me to install JRE 11 (the current default on my system), which does not make sense (and takes a lot of space). -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Versions of packages dicomscope depends on: pn default-jre pn jarwrapper pn libdicomscope-jni ii tk [wish] 8.6.11+1 ii tk8.6 8.6.11-2 dicomscope recommends no packages. dicomscope suggests no packages.
Bug#1035965: python-ansible-pygments: Autopkgtest fails against pygments 2.15
Package: python-ansible-pygments
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch
Dear Maintainer,
Since the move to pygments 2.15, the autopkgtest testsuite fails with
the following error:
Traceback (most recent call last):
File "/home/olivier/dev/canonical/ansible-pygments/tests/lexer_test.py", line
131, in
test_ansible_output_lexer()
File "/home/olivier/dev/canonical/ansible-pygments/tests/lexer_test.py", line
78, in test_ansible_output_lexer
assert result == R"""ok: [windows] =
{
^^
AssertionError
The bug was fixed upstream by
https://github.com/ansible-community/ansible-pygments/pull/34.
In Ubuntu, the attached patch was applied to achieve the following:
* Add patch from upstream to fix test suite against pygments 2.15
Added patch:
debian/patches/Make-lexer-test-compare-tokens.patch
(LP: #2019237)
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers lunar-updates
APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
---
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
1970-01-01 01:00:00.0 +0100
+++
python-ansible-pygments-0.1.1/debian/patches/Make-lexer-test-compare-tokens.patch
2023-05-11 21:30:42.0 +0200
@@ -0,0 +1,342 @@
+Description: Make lexer test compare tokens
+ With new releases of `pygments`, this test was getting broken again
+ and again because it originally relied on HTML the formatted text
+ output. Hence, it was prone to external influence for no good reason.
+ .
+ This patch rewrites it to solely rely on the underlying tokens that
+ our lexer produces, therefore reducing the dependence on unrelated
+ changes in the `pygments` library.
+Author: Sviatoslav Sydorenko
+Origin: upstream, https://github.com/ansible-community/ansible-pygments/pull/34
+Bug: https://github.com/ansible-community/ansible-pygments/issues/33
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2019237
+Applied-Upstream:
https://github.com/ansible-community/ansible-pygments/commit/179c74e9f1a5dc870dec6d4db6cab60d2dca1ed2
+Last-Update: 2023-05-11
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/tests/lexer_test.py b/tests/lexer_test.py
+index 5b700a9..a842a7c 100644
+--- a/tests/lexer_test.py
b/tests/lexer_test.py
+@@ -1,26 +1,24 @@
+ # Author: Felix Fontein
+ # License: BSD-2-Clause
+ # Copyright: Felix Fontein , 2021
+-"""Tests for Pygments lexers."""
++"""Tests for Pygments lexers.
+
+-from pygments import highlight
+-# pylint: disable=no-name-in-module
+-# Ref: https://github.com/PyCQA/pylint/issues/491
+-from pygments.formatters import HtmlFormatter
+-
+-from ansible_pygments.lexers import AnsibleOutputLexer
++They rely on token comparison for stability reasons. Relying on
++additional style formatting is known to break with updates to
++the pygments library itself.
++"""
+
++from pygments import __version__ as _pygments_version
++from pygments.lexers import get_lexer_by_name as _get_lexer_by_name
++from pygments.token import Token
+
+-def run_test(data, lexer):
+-"""Format the data snippet as HTML using a given lexer."""
+-formatter = HtmlFormatter()
+-result = highlight(data, lexer, formatter)
+-return formatter.get_style_defs('.highlight'), result
++PYGMENTS_VERSION_INFO = tuple(map(int, _pygments_version.split('.')))
++IS_OLD_PYGMENTS_PRE_2_14 = PYGMENTS_VERSION_INFO <= (2, 14, 0)
+
+
+ def test_ansible_output_lexer():
+-"""Test that AnsibleOutputLexer produces expected HTML output."""
+-data = R"""
++"""Test that ``AnsibleOutputLexer`` produces expected tokens."""
++ansible_play_output_example = R"""
+ ok: [windows] => {
+ "account": {
+ "account_name": "vagrant-domain",
+@@ -71,58 +69,226 @@ Sunday 11 November 2018 20:19:25 +0100 (0:00:00.607)
0:10:36.974 **
Bug#1035758: backupninja: Config defaults leads to node-exporter error
Package: backupninja Version: 1.2.2-1 Severity: minor Tags: upstream Dear Maintainer, With the default config in backupninja.conf, and prometheus-node-exporter isn't installed, an error is reported at the end of backups like: Error: /var/lib/prometheus/node-exporter does not exist! I believe that the default value isn't suitable: reportprom = false Instead, it should be: reportprom = if I interpret https://0xacab.org/liberate/backupninja/-/blob/8f81c85274cd7a21d4bff819bf800b300a7488d2/src/backupninja.in#L609 correctly. Hope this is correct. Best regards, -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages backupninja depends on: ii bash5.2.15-2+b2 ii dialog 1.3-20230209-1 ii gawk1:5.2.1-2 ii mawk1.3.4.20200120-3.1 Versions of packages backupninja recommends: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii mailutils [mailx] 1:3.15-4 Versions of packages backupninja suggests: ii borgbackup 1.2.4-1 ii bzip2 1.0.8-5+b1 ii debconf-utils 1.5.82 pn duplicity ii fdisk 2.38.1-5+b1 ii genisoimage9:1.1.11-3.4 ii hwinfo 21.82-1 ii mdadm 4.2-5 ii rdiff-backup 2.2.2-1 pn restic ii rsync 3.2.7-1 pn subversion ii trickle1.07-12 ii util-linux 2.38.1-5+b1 pn wodim -- Configuration Files: /etc/backupninja.conf changed: loglevel = 4 reportprom = reportemail = root reportsuccess = yes reportinfo = no reportwarning = yes reportspace = no reporthost = reportuser = ninja reportdirectory = /var/lib/backupninja/reports admingroup = root logfile = /var/log/backupninja.log configdirectory = /etc/backup.d scriptdirectory = /usr/share/backupninja libdirectory = /usr/lib/backupninja usecolors = yes when = everyday at 01:00 -- debconf-show failed -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#866523: Duplicate systemd units
According to the OpenVPN wiki [0]: - openvpn@.service is deprecated. - openvpn.service is obsoleted. (This is only used for backward compatibility) The openvpn-client@ and openvpn-server@ units worked very nicely for me, is it possible to add a header to both units to point to the recommended units? # Using this unit file is not recommended, use openvpn-client@ and openvpn-server@ instead # Further information: https://community.openvpn.net/openvpn/wiki/Systemd [0] https://community.openvpn.net/openvpn/wiki/Systemd OpenPGP_0x7CFB94AF1C953A69.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1034608: system-config-printer: Wrong french translation of "Off" into "Hors tension"
Package: system-config-printer Version: 1.5.18-1 Severity: minor Dear Maintainer, The Printer parameters displays some settings as Off in the gui. However the french translation displays "Hors Tension". Whereas "Hors Tension" applies for a printer which would be off-line for instance (litteraly off-voltage), settings set to "off" should translate in a different way, like "Désactivé" (I guess this is a FAQ in translation, and I've been far away from translation groups for too long, sorry). Hope this helps, Best regards, -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 'testing'), (500, 'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages system-config-printer depends on: ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-glib-2.0 1.74.0-3 ii gir1.2-gtk-3.03.24.37-2 ii gir1.2-handy-11.8.1-1 ii gir1.2-notify-0.7 0.8.1-1 ii gir1.2-packagekitglib-1.0 1.2.6-3 ii gir1.2-pango-1.0 1.50.12+ds-1 ii gir1.2-polkit-1.0 122-3 ii python3 3.11.2-1+b1 ii python3-cups 2.0.1-5+b4 ii python3-cupshelpers 1.5.18-1 ii python3-dbus 1.3.2-4+b1 ii python3-gi3.42.2-3+b1 ii system-config-printer-common 1.5.18-1 Versions of packages system-config-printer recommends: ii avahi-utils 0.8-9 ii system-config-printer-udev 1.5.18-1 Versions of packages system-config-printer suggests: ii gnome-software 43.4-1 -- debconf-show failed -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1034485: os-prober expects to run in a new private mount namespace, but new namespace is not private
Dear maintainer, I opened the following PR: https://salsa.debian.org/installer-team/os-prober/-/merge_requests/20 Best regards, Olivier
Bug#1034485: os-prober expects to run in a new private mount namespace, but new namespace is not private
Package: os-prober Version: 1.81 Severity: normal Dear Maintainer, During execution of os-prober, other processes on the system can see the temporary mounts to /var/lib/os-prober/mount even though os-prober runs in a separate mount namespace. In order to run os-prober in a more isolated mode, we introduced the newns.c source file a while ago. We build it to a binary and ship it in os-prober and os-prober-udeb. The original idea was to run os-prober in a private mount namespace. Sadly, calling the unshare(CLONE_NEWNS) system call is only enough to create a new mount namespace. But it is not enough to make the new namespace private. While we can patch newns.c to make the new mount namespace private, relying on unshare(1) from util-linux (which is an essential package) seems like a more viable option. I will open a PR with a potential fix. Thanks, Olivier See also: https://github.com/util-linux/util-linux/commit/f0f22e9c6f109f8c1234caa3173368ef43b023eb -- System Information: Debian Release: bookworm/sid APT prefers lunar APT policy: (500, 'lunar') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-16-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages os-prober depends on: ii grub-common 2.06-2ubuntu16 ii libc62.37-0ubuntu2 ii mount2.38.1-4ubuntu1 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information
Bug#956226: Not fixed in Debian 12 D-I Alpha2 as of 2023-03-16
Dear all, This sitation also arises in the latest Debian Instaler (Netinst ISO) for Debian 12 available in Testing. LVM-Thin Physical Volume previously created by a Proxmox-VE installer ISO cannot be removed by the Debian Installer. Normal LVM (non-thin) PV also created by the same Proxmox Instal successfully removed. Cheers, Olivier
Bug#1032596: zfs-initramfs: cannot boot (dropped to shell) if mountpoint=legacy for boot dataset
Package: zfs-initramfs Version: 2.1.9-2 Severity: important Tags: upstream Dear Maintainer, * What led up to the situation? Upgrading from 2.1.9-1 to 2.1.9-2 My root dataset has mountpoint=legacy I reported this upstream https://github.com/openzfs/zfs/issues/14599 * What exactly did you do (or not do) that was effective (or ineffective)? I modified /usr/share/initramfs-tools/scripts/zfs (see upstream bug report) * What was the outcome of this action? This fixed my issue -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zfs-initramfs depends on: ii busybox 1:1.35.0-4+b2 ii initramfs-tools 0.142 ii zfs-dkms [zfs-modules] 2.1.9-2 ii zfsutils-linux 2.1.9-2 zfs-initramfs recommends no packages. zfs-initramfs suggests no packages. -- no debconf information
Bug#1025537: nfsd: Kernel Oops while serving NFS
Source: linux Followup-For: Bug #1025537 The 6.1.0 Changelog had some notes about a gnarly bug in the NFS bug having been fixed, so I thought I'd give it a try. Unfortunately, the problem reported here is still present. It has made the machine quite unstable, but I was able to retrieve logs of previous Oopses. 2023-03-02T12:51:02.923421+11:00 supahwinch kernel: [0.00] Linux version 6.1.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) [SNIP]-8< 2023-03-02T13:11:21.468088+11:00 supahwinch kernel: [ 1262.015083] stack segment: [#1] PREEMPT SMP NOPTI 2023-03-02T13:11:21.473246+11:00 supahwinch kernel: [ 1262.019939] CPU: 0 PID: 3345 Comm: nfsd Not tainted 6.1.0-5-amd64 #1 Debian 6.1.12-1 2023-03-02T13:11:21.473258+11:00 supahwinch kernel: [ 1262.024779] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013 2023-03-02T13:11:21.473261+11:00 supahwinch kernel: [ 1262.029613] RIP: 0010:release_pages+0xcd/0x4d0 2023-03-02T13:11:21.473264+11:00 supahwinch kernel: [ 1262.034410] Code: 84 c0 74 1a 48 8b 04 24 48 8d 4c 24 30 49 89 46 08 48 89 44 24 30 4c 89 75 08 48 89 4d 10 49 83 c7 08 4c 39 fb 74 75 49 8b 2f <48> 8b 45 08 a8 01 0f 85 58 01 00 00 0f 1f 44 00 00 4d 85 ed 74 0e 2023-03-02T13:11:21.473268+11:00 supahwinch kernel: [ 1262.044534] RSP: 0018:bc550156fe30 EFLAGS: 00010206 2023-03-02T13:11:21.473271+11:00 supahwinch kernel: [ 1262.049614] RAX: 0007 RBX: 97c2ae3b4b78 RCX: bc550156fe60 2023-03-02T13:11:21.473274+11:00 supahwinch kernel: [ 1262.054703] RDX: bc550156fe60 RSI: bc550156fe60 RDI: de0185ba2148 2023-03-02T13:11:21.473277+11:00 supahwinch kernel: [ 1262.059850] RBP: 000fc000 R08: de0180d57d08 R09: 00019198 2023-03-02T13:11:21.473279+11:00 supahwinch kernel: [ 1262.064975] R10: 0003 R11: R12: 2023-03-02T13:11:21.473282+11:00 supahwinch kernel: [ 1262.070058] R13: R14: de0180d57d08 R15: 97c2ae3b4b28 2023-03-02T13:11:21.473284+11:00 supahwinch kernel: [ 1262.075101] FS: () GS:97c357c0() knlGS: 2023-03-02T13:11:21.473287+11:00 supahwinch kernel: [ 1262.080166] CS: 0010 DS: ES: CR0: 80050033 2023-03-02T13:11:21.473290+11:00 supahwinch kernel: [ 1262.085268] CR2: 7f6e0e512416 CR3: 000109c92000 CR4: 06f0 2023-03-02T13:11:21.473292+11:00 supahwinch kernel: [ 1262.090377] Call Trace: 2023-03-02T13:11:21.473295+11:00 supahwinch kernel: [ 1262.095402] 2023-03-02T13:11:21.473298+11:00 supahwinch kernel: [ 1262.100346] ? nfsd_shutdown_threads+0x90/0x90 [nfsd] 2023-03-02T13:11:21.473300+11:00 supahwinch kernel: [ 1262.105417] __pagevec_release+0x1b/0x30 2023-03-02T13:11:21.473303+11:00 supahwinch kernel: [ 1262.110399] svc_xprt_release+0x1a3/0x1e0 [sunrpc] 2023-03-02T13:11:21.473306+11:00 supahwinch kernel: [ 1262.115547] svc_send+0x59/0x160 [sunrpc] 2023-03-02T13:11:21.473308+11:00 supahwinch kernel: [ 1262.120602] nfsd+0xd5/0x190 [nfsd] 2023-03-02T13:11:21.473311+11:00 supahwinch kernel: [ 1262.125538] kthread+0xe9/0x110 2023-03-02T13:11:21.473313+11:00 supahwinch kernel: [ 1262.130372] ? kthread_complete_and_exit+0x20/0x20 2023-03-02T13:11:21.473315+11:00 supahwinch kernel: [ 1262.135195] ret_from_fork+0x22/0x30 2023-03-02T13:11:21.473318+11:00 supahwinch kernel: [ 1262.139953] 2023-03-02T13:11:21.473321+11:00 supahwinch kernel: [ 1262.144620] Modules linked in: veth xt_nat nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype br_netfilter bridge stp llc overlay cmac algif_hash ecb algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc amdgpu isofs gpu_sched cdrom drm_buddy xc2028 zl10353 rc_fusionhdtv_mce ir_kbd_i2c cx23885 altera_ci tda18271 altera_stapl m88ds3103 i2c_mux btusb btrtl cx2341x btbcm tveeprom btintel videobuf2_dvb dvb_core btmtk bluetooth videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 amd64_edac jitterentropy_rng videobuf2_common edac_mce_amd radeon sha512_generic kvm_amd videodev video ctr ccp wmi mc drbg cp210x rng_core snd_pcm ansi_cprng usbserial drm_display_helper ecdh_generic snd_timer joydev snd rfkill kvm cec soundcore evdev ecc pcspkr rc_core drm_ttm_helper xfs ttm irqbypass drm_kms_helper sp5100_tco watchdog i2c_algo_bit acpi_cpufreq sg button 2023-03-02T13:11:21.473327+11:00 supahwinch kernel: [ 1262.144868] k10temp w83795 jc42 tun loop nfsd msr auth_rpcgss nfs_acl lockd parport_pc grace ppdev sunrpc lp drm parport efi_pstore fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_compress raid10 raid456
Bug#1005411: deluge: log spammed with findCaller exception
Dear Maintainer, same issue here (Debian Testing / amd64 / up to date), after python 3.10 to 3.11 standard Debian Testing upgrade. In order to fix it, I've to apply 2 patchs: - Same as Daniel from current bug #1005411 : https://git.deluge-torrent.org/deluge/commit/?h=develop=351664ec071daa04161577c6a1c949ed0f2c3206 - And a second patch, found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016044 https://github.com/deluge-torrent/deluge/commit/89189adb24321c3db6bfa816ec557d7d8367ba24 Run deluged during 12h, no more abnormal messages into journal Thanks for your help. Best regards, Olivier
Bug#1023586: texlive-extra-utils: pythontex won't find python (when on python3)
Hilmar Preuße writes: > In the Debian package the python interpreter is hard coded to python3 in > the pythontex scripts. Hence I do not really understand, what is going > on here. Could you provide a minimal input file for problem reproduction? > I'm afraid it's a bit hard for me to find time to prepare that, as I initially used it inside an Auto-Multiple-Choice exams, which is a complete mess of its own in terms of providing a minimal reproducible set (see original report stack traces) :-/ Sorry. Maybe that'll go away after some time in testing. Thanks for caring. Best regards, -- Olivier BERGER https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France)
Bug#1030305: django-rich: FTBFS when building with TERM=unknown
Package: django-rich Followup-For: Bug #1030305 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar ubuntu-patch Control: tags -1 patch Hi, The patch was merged upstream after receiving some modifications. I'm attaching an updated debdiff which backports the patch applied upstream. Best regards, diff -Nru django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch --- django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch 1970-01-01 01:00:00.0 +0100 +++ django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch 2023-02-02 12:05:10.0 +0100 @@ -0,0 +1,57 @@ +Description: Fix failing tests if the TERM variable is set to unknown +Origin: upstream, https://github.com/adamchainz/django-rich/commit/d437e9248322540b976d25f8a78a413e581c5dac +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030305 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/django-rich/+bug/2004553 +Applied-Upstream: django-rich >> 1.4.0 +Last-Update: 2023-02-03 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: django-rich-1.4.0/tests/test_management.py +=== +--- django-rich-1.4.0.orig/tests/test_management.py2023-02-03 09:25:32.460627256 +0100 django-rich-1.4.0/tests/test_management.py 2023-02-03 09:28:26.431930919 +0100 +@@ -1,12 +1,16 @@ + from __future__ import annotations + ++import os + from functools import partial + from inspect import Parameter, Signature, signature + from io import StringIO ++from typing import Any + from unittest import mock + + import pytest +-from django.core.management import BaseCommand, CommandError, call_command ++from django.core.management import BaseCommand ++from django.core.management import call_command as base_call_command ++from django.core.management import CommandError + from django.test import SimpleTestCase + from rich.console import Console + +@@ -28,6 +32,12 @@ + return True + + ++def call_command(*args: str, **kwargs: Any) -> None: ++# Ensure rich uses colouring and consistent width ++with mock.patch.dict(os.environ, TERM="", COLUMNS="80"): ++base_call_command(*args, **kwargs) ++ ++ + class RichCommandTests(SimpleTestCase): + def test_init_signature(self): + rc_signature = strip_annotations(signature(RichCommand.__init__)) +Index: django-rich-1.4.0/tests/test_test.py +=== +--- django-rich-1.4.0.orig/tests/test_test.py 2023-02-03 09:25:32.460627256 +0100 django-rich-1.4.0/tests/test_test.py 2023-02-03 09:25:32.460627256 +0100 +@@ -88,6 +88,9 @@ + **os.environ, + "DJANGO_SETTINGS_MODULE": "tests.settings", + "COVERAGE_PROCESS_START": str(SETUP_CFG_PATH), ++# Ensure rich uses colouring and consistent width ++"TERM": "", ++"COLUMNS": "80", + }, + **kwargs, + ) diff -Nru django-rich-1.4.0/debian/patches/series django-rich-1.4.0/debian/patches/series --- django-rich-1.4.0/debian/patches/series 2023-01-15 08:16:57.0 +0100 +++ django-rich-1.4.0/debian/patches/series 2023-02-02 12:05:10.0 +0100 @@ -1,3 +1,4 @@ Use-python3-within-test-call.patch tests-Drop-various-python-version-handling.patch tests-Another-bunch-of-adoptions-for-Python-3.11.patch +0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch
Bug#1013395: mpdecimal: FTBFS with Sphinx 5.0, docutils 0.18: make[1]: *** [debian/rules:60: override_dh_sphinxdoc] Error 255
Hi, > This happens because mpdecimal does not rebuild documentation from > source, but installs pre-built files provided by upstream. > I recommend to rebuild the documentation from source. I had a look but could not find the sources of the documentation. The upstream tarball only contains the pre-built version. Have we ever asked upstream if they would be okay to provide the sources of the doc? I would check but I can't find a link to archives of the libmpdec mailing lists [1]. Also, the website suggests that the mailing lists are not operational since Jan 2021 so I don't know how likely we will find out. [1] https://www.bytereef.org/mpdecimal/mailinglists.html Olivier
Bug#1030305: django-rich: FTBFS when building with TERM=unknown
Package: django-rich Followup-For: Bug #1030305 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar ubuntu-patch Control: tags -1 patch Adding a revised debdiff. This version applies the patch that I submitted upstream: https://github.com/adamchainz/django-rich/pull/103 The patch modifies the upstream test-suite rather than overriding the TERM variable at dh_auto_test time. Thanks! -- System Information: Debian Release: bookworm/sid APT prefers kinetic-updates APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 'kinetic'), (100, 'kinetic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-29-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch --- django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch 1970-01-01 01:00:00.0 +0100 +++ django-rich-1.4.0/debian/patches/0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch 2023-02-02 12:05:10.0 +0100 @@ -0,0 +1,41 @@ +Description: Fix failing tests if the TERM variable is set to unknown + When running the test-suite with TERM=unknown, the tests fail because + the generated output is not "rich". + . + This happens because python rich will disable color and style if the TERM + variable is set to either "unknown" or "dumb" [1] + . + This patch monkey-patches the environment to make the test suite + insensitive to the TERM variable. + . + [1] https://rich.readthedocs.io/en/stable/console.html?highlight=unknown#environment-variables +Author: Olivier Gayot +Origin: upstream, https://github.com/adamchainz/django-rich/pull/103/commits/ac19f46572fb0550a9b7a688114c298dd7b6c872 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030305 +Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/django-rich/+bug/2004553 +Forwarded: https://github.com/adamchainz/django-rich/pull/103 +Last-Update: 2023-02-02 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: django-rich-1.4.0/tests/test_management.py +=== +--- django-rich-1.4.0.orig/tests/test_management.py2023-02-02 15:06:49.343335475 +0100 django-rich-1.4.0/tests/test_management.py 2023-02-02 15:06:49.343335475 +0100 +@@ -3,6 +3,7 @@ + from functools import partial + from inspect import Parameter, Signature, signature + from io import StringIO ++import os + from unittest import mock + + import pytest +@@ -28,6 +29,9 @@ + return True + + ++# python rich will disable color/style if TERM is set to "unknown" or "dumb" ++# https://rich.readthedocs.io/en/stable/console.html?highlight=unknown#environment-variables ++@mock.patch.dict(os.environ, TERM="") + class RichCommandTests(SimpleTestCase): + def test_init_signature(self): + rc_signature = strip_annotations(signature(RichCommand.__init__)) diff -Nru django-rich-1.4.0/debian/patches/clear-TERM-variable.patch django-rich-1.4.0/debian/patches/clear-TERM-variable.patch --- django-rich-1.4.0/debian/patches/clear-TERM-variable.patch 1970-01-01 01:00:00.0 +0100 +++ django-rich-1.4.0/debian/patches/clear-TERM-variable.patch 2023-02-02 12:05:10.0 +0100 @@ -0,0 +1,20 @@ +Index: django-rich-1.4.0/tests/test_management.py +=== +--- django-rich-1.4.0.orig/tests/test_management.py2022-06-05 17:27:00.0 +0200 django-rich-1.4.0/tests/test_management.py 2023-02-02 14:50:44.876420552 +0100 +@@ -3,6 +3,7 @@ + from functools import partial + from inspect import Parameter, Signature, signature + from io import StringIO ++import os + from unittest import mock + + import pytest +@@ -28,6 +29,7 @@ + return True + + ++@mock.patch.dict(os.environ, TERM="") + class RichCommandTests(SimpleTestCase): + def test_init_signature(self): + rc_signature = strip_annotations(signature(RichCommand.__init__)) diff -Nru django-rich-1.4.0/debian/patches/series django-rich-1.4.0/debian/patches/series --- django-rich-1.4.0/debian/patches/series 2023-01-15 08:16:57.0 +0100 +++ django-rich-1.4.0/debian/patches/series 2023-02-02 12:05:10.0 +0100 @@ -1,3 +1,4 @@ Use-python3-within-test-call.patch tests-Drop-various-python-version-handling.patch tests-Another-bunch-of-adoptions-for-Python-3.11.patch +0001-Fix-failing-tests-if-the-TERM-variable-is-set-to-unk.patch
Bug#1030305: django-rich: FTBFS when building with TERM=unknown
Package: django-rich
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Dear Maintainer,
When building on Ubuntu, the build-time test suite fails with the
following error:
self =
def test_output_force_color(self):
stdout = StringIO()
call_command("example", "--force-color", stdout=stdout)
> assert stdout.getvalue() == "\x1b[1;31mAlert!\x1b[0m\n"
E AssertionError: assert 'Alert!\n' == '\x1b[1;31mAlert!\x1b[0m\n'
E - [1;31mAlert![0m
E + Alert!
This happens because the underlying python rich library disables
color/style when the TERM variable is set to unknown (which is what the
Ubuntu builders have):
> Setting the environment variable TERM to "dumb" or "unknown" will
> disable color/style and some features that require moving the cursor,
> such as progress bars.
https://rich.readthedocs.io/en/stable/console.html?highlight=unknown#environment-variables
Although currently Debian is not affected (I believe builders have a
different value for TERM), it feels wrong that the build-time test-suite
would depend on the TERM environment variable. Therefore, I think the
patch still makes sense.
In Ubuntu, the attached patch was applied to achieve the following:
* clear TERM variable when running build test suite since python-rich
disables color/style when TERM=unknown (LP: #2004553)
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers kinetic-updates
APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500,
'kinetic'), (100, 'kinetic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-29-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru django-rich-1.4.0/debian/rules django-rich-1.4.0/debian/rules
--- django-rich-1.4.0/debian/rules 2023-01-15 08:19:23.0 +0100
+++ django-rich-1.4.0/debian/rules 2023-02-02 12:05:10.0 +0100
@@ -12,4 +12,4 @@
# Upstream uses a more agressive call, wont work here
# as at least the package we build isn't installed so
# using a modified pytest call.
- dh_auto_test -- --system=custom --test-args="{interpreter} -m coverage
run -m pytest tests"
+ TERM= dh_auto_test -- --system=custom --test-args="{interpreter} -m
coverage run -m pytest tests"
Bug#1030238: kitty: crypto test failure at build time when RTLIM_MEMLOCK is too low
Package: kitty Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu lunar ubuntu-patch Dear Maintainer, When building the package for ppc64el on Ubuntu, the crypto test fails with the following error: OSError: [Errno 12] Cannot allocate memory This happens because the ppc64el builders have their RLIMIT_MEMLOCK value set to the pagesize (64k) ; so only a single call to mlock(2) can succeed. Although the build does not fail in Debian (I believe the RLIMIT_MEMLOCK is set to a more sensible value), I think the patch could still make sense. There is an upstream bug report: https://github.com/kovidgoyal/kitty/issues/5466 In Ubuntu, the attached patch was applied to achieve the following: * disable crypto test if RLIMIT_MEMLOCK is too low (LP: #2004435) Thanks for considering the patch. -- System Information: Debian Release: bookworm/sid APT prefers kinetic-updates APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 'kinetic'), (100, 'kinetic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-29-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru kitty-0.26.5/debian/control kitty-0.26.5/debian/control --- kitty-0.26.5/debian/control 2023-01-30 20:32:11.0 +0100 +++ kitty-0.26.5/debian/control 2023-02-01 12:31:03.0 +0100 @@ -1,7 +1,6 @@ Source: kitty Priority: optional -Maintainer: Ubuntu Developers -XSBC-Original-Maintainer: James McCoy +Maintainer: James McCoy Section: x11 Standards-Version: 4.6.2 Rules-Requires-Root: no diff -Nru kitty-0.26.5/debian/patches/conditionally-skip-crypto-test.patch kitty-0.26.5/debian/patches/conditionally-skip-crypto-test.patch --- kitty-0.26.5/debian/patches/conditionally-skip-crypto-test.patch 1970-01-01 01:00:00.0 +0100 +++ kitty-0.26.5/debian/patches/conditionally-skip-crypto-test.patch 2023-02-01 12:31:03.0 +0100 @@ -0,0 +1,36 @@ +Description: skip crypto test if RLIMIT_MEMLOCK is too low + When building on ppc64el in Ubuntu, RLIMIT_MEMLOCK is set to the same value as + the pagesize. This means only a single call to mlock() can succeed. + Since the crypto test makes multiple calls to mlock(), the test fails in the + described environment. + Make sure we skip the test if the RLIMIT_MEMLOCK is too low. +Author: Olivier Gayot +Bug-Ubuntu: https://bugs.launchpad.net/bugs/2004435 +Forwarded: https://github.com/kovidgoyal/kitty/issues/5466#issuecomment-1412004797 +Last-Update: 2023-02-01 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: kitty-0.26.5/kitty_tests/crypto.py +=== +--- kitty-0.26.5.orig/kitty_tests/crypto.py2023-02-01 13:17:33.662880021 +0100 kitty-0.26.5/kitty_tests/crypto.py 2023-02-01 13:25:53.667978172 +0100 +@@ -3,12 +3,19 @@ + + + import os ++import resource ++import unittest + + from . import BaseTest + + ++memlock_limit, _ = resource.getrlimit(resource.RLIMIT_MEMLOCK) ++pagesize = resource.getpagesize() ++ ++ + class TestCrypto(BaseTest): + ++@unittest.skipIf(memlock_limit <= pagesize, "RLIMIT_MEMLOCK is too low") + def test_elliptic_curve_data_exchange(self): + from kitty.fast_data_types import ( + AES256GCMDecrypt, AES256GCMEncrypt, CryptoError, EllipticCurveKey diff -Nru kitty-0.26.5/debian/patches/series kitty-0.26.5/debian/patches/series --- kitty-0.26.5/debian/patches/series 2023-01-04 12:14:15.0 +0100 +++ kitty-0.26.5/debian/patches/series 2023-02-01 12:31:03.0 +0100 @@ -1,3 +1,4 @@ bash-integration-fix-clone-in-kitty-not-.patch define-singlekey-bitfields-according-to-.patch try-to-fix-tests-failing-on-python-3.11.patch +conditionally-skip-crypto-test.patch
Bug#1025537: nfsd: Kernel Oops while serving NFS
Package: linux-image-5.19.0-10315-g310d9d5a5009 Followup-For: Bug #1025537 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Olivier Mehani To: Debian Bug Tracking System <1025...@bugs.debian.org> Subject: Re: nfsd: Kernel Oops while serving NFS Message-ID: <167361292314.1643173.3991370234085262557.report...@supahwinch.narf.ssji.net> X-Mailer: reportbug 11.6.0 Date: Fri, 13 Jan 2023 23:28:43 +1100 Package: linux-image-5.19.0-10316-gf0f6b614f83d Followup-For: Bug #1025537 OK, I think I have a strong suspect [0]: f0f6b614f83dbae99d283b7b12ab5dd2e04df979 (tags/v6.0-rc1~55^2~2) This is a pretty generic commit, that doesn't seem to touch the nfs stack, but changes something that looks deep enough in the iovec code that it could have an impact. I have solidly re-tested the preceding commit, 310d9d5a5009a93377200b98daa2d84aa2bd8160 (tags/v6.0-rc1~55^2~3), and the Oops doesn't happen there. There is a series of commits that were suggested as part of the `git bisect`, that I wasn't able to build and had to skip. The error was FAILED: load BTF from vmlinux: Invalid argument but no amount of cajoling `pahole` has helped. The merge parent for the series is at 8447d0e75099eb54eea9306c2d43ecfc956d09ed (tags/v6.0-rc1~56^2), which is the preceding merge to the one containing the first bad commit above. I think this is noteworthy as a lot of the commits on this branch are labeled as `remoteproc` which I, as a lay person, think might be related to RPCs. Is there any other tests that I can perform to help diagnose / fix this further? [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f0f6b614f83dbae99d283b7b12ab5dd2e04df97 (but dockerd Oops, 10623384), nah, BAD -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-10315-g310d9d5a5009 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF8), LANGUAGE=en_AU:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1028586: sysvinit: Missing 50-ubuntu-logging file when building on Ubuntu
I opened a pull-request to fix the issue: https://salsa.debian.org/debian/sysvinit/-/merge_requests/8
Bug#1028586: sysvinit: Missing 50-ubuntu-logging file when building on Ubuntu
Source: sysvinit Severity: normal Dear Maintainer, When building on Ubuntu, the sysvinit-utils package is supposed to include the lib/lsb/init-functions.d/50-ubuntu-logging file. The file used to be shipped with lsb-base on Ubuntu and should now be shipped with sysvinit-utils (only on Ubuntu) following the move of init-functions from lsb-base to sysvinit-utils. -- System Information: Debian Release: bookworm/sid APT prefers kinetic-updates APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 'kinetic'), (100, 'kinetic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-28-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1025537: nfsd: Kernel Oops while serving NFS
Package: linux-image-5.19.0-13797-ge091ba5cf827 Version: 5.19.0-13797-ge091ba5cf827-17 Followup-For: Bug #1025537 Nope... I just re-triggered the Oops on the preceding commit, e091ba5cf827. I'll restart the bisection from there... [ 2976.696730] Oops: [#1] PREEMPT SMP NOPTI [ 2976.700471] CPU: 0 PID: 1969 Comm: nfsd Not tainted 5.19.0-13797-ge091ba5cf827 #17 [ 2976.704341] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013 [ 2976.708272] RIP: 0010:kernel_sendpage+0x1d/0x120 [ 2976.712213] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80 [ 2976.720602] RSP: 0018:a7f641733dc0 EFLAGS: 00010282 [ 2976.724805] RAX: b1933e60 RBX: 9897918e7400 RCX: 1000 [ 2976.729097] RDX: RSI: RDI: 9897918e7400 [ 2976.733433] RBP: 9896dab74280 R08: R09: b12492e0 [ 2976.737779] R10: 0003 R11: R12: 9897918e7400 [ 2976.742168] R13: 1000 R14: 9897aa997010 R15: b8fd [ 2976.746524] FS: () GS:9897d7c0() knlGS: [ 2976.750910] CS: 0010 DS: ES: CR0: 80050033 [ 2976.755323] CR2: 0008 CR3: 0001ff94a000 CR4: 06f0 [ 2976.759755] Call Trace: [ 2976.764102] [ 2976.768390] ? sock_sendmsg+0x58/0x70 [ 2976.772648] svc_tcp_sendmsg+0x121/0x180 [sunrpc] [ 2976.776967] ? nfsd_shutdown_threads+0x90/0x90 [nfsd] [ 2976.781283] svc_tcp_sendto+0x90/0x190 [sunrpc] [ 2976.785577] svc_send+0x4d/0x160 [sunrpc] [ 2976.789807] nfsd+0xd5/0x190 [nfsd] [ 2976.794006] kthread+0xe9/0x110 [ 2976.798048] ? kthread_complete_and_exit+0x20/0x20 [ 2976.802159] ret_from_fork+0x22/0x30 [ 2976.806223] [ 2976.810202] Modules linked in: veth nf_conntrack_netlink xfrm_user xfrm_algo br_netfilter bridge stp llc overlay tls cmac algif_hash ecb algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 nft_chain_nat xt_nat xt_MASQUERADE nf_nat xt_addrtype ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc amdgpu gpu_sched drm_buddy xc2028 zl10353 rc_fusionhdtv_mce ir_kbd_i2c cx23885 btusb tveeprom btrtl altera_ci btbcm cx2341x btintel btmtk tda18271 snd_pcm bluetooth snd_timer isofs rfkill amd64_edac snd jitterentropy_rng cdrom soundcore sha512_ssse3 edac_mce_amd sha512_generic altera_stapl kvm_amd radeon videobuf2_dvb ctr drbg videobuf2_dma_sg videobuf2_memops cp210x ansi_cprng m88ds3103 ccp i2c_mux usbserial i2c_algo_bit dvb_core videobuf2_v4l2 drm_ttm_helper rng_core evdev videobuf2_common joydev ttm kvm ecdh_generic drm_display_helper irqbypass ecc videodev xfs drm_kms_helper mc cec pcspkr k10temp rc_core [ 2976.810298] sp5100_tco button watchdog sg acpi_cpufreq w83795 jc42 tun loop msr nfsd parport_pc ppdev auth_rpcgss lp nfs_acl parport lockd grace drm efi_pstore sunrpc fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor uas usb_storage raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dm_mod hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common ahci libahci libata ohci_pci scsi_mod ohci_hcd ehci_pci ehci_hcd scsi_common tg3 i2c_piix4 usbcore ptp pps_core libphy usb_common [ 2976.876303] CR2: 0008 [ 2976.881421] ---[ end trace ]--- [ 2976.886579] RIP: 0010:kernel_sendpage+0x1d/0x120 [ 2976.891691] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80 [ 2976.902360] RSP: 0018:a7f641733dc0 EFLAGS: 00010282 [ 2976.907711] RAX: b1933e60 RBX: 9897918e7400 RCX: 1000 [ 2976.913121] RDX: RSI: RDI: 9897918e7400 [ 2976.918506] RBP: 9896dab74280 R08: R09: b12492e0 [ 2976.923843] R10: 0003 R11: R12: 9897918e7400 [ 2976.929141] R13: 1000 R14: 9897aa997010 R15: b8fd [ 2976.934339] FS: () GS:9897d7c0() knlGS: [ 2976.939481] CS: 0010 DS: ES: CR0: 80050033 [ 2976.944570] CR2: 0008 CR3: 0001ff94a000 CR4: 06f0 -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-13797-ge091ba5cf827 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=UTF-8)
Bug#1025537: nfsd: Kernel Oops while serving NFS
Package: linux-image-5.19.0-13930-g7ebfc85e2cd7 Version: 5.19.0-13930-g7ebfc85e2cd7-23 Followup-For: Bug #1025537 Ah, here we go! It just Oopsed again, on what is presumably the first commit introducing the issue. I'm gonna try to buidthe previous commit and see if it's happy for a while. [ 2047.224083] Oops: [#1] PREEMPT SMP NOPTI [ 2047.228190] CPU: 1 PID: 1987 Comm: nfsd Not tainted 5.19.0-13930-g7ebfc85e2cd7 #23 [ 2047.232427] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013 [ 2047.236740] RIP: 0010:kernel_sendpage+0x1d/0x120 [ 2047.241021] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80 [ 2047.250067] RSP: 0018:b12541e2fdc0 EFLAGS: 00010282 [ 2047.254722] RAX: 86733e60 RBX: 88f681d5b740 RCX: 1000 [ 2047.259428] RDX: RSI: RDI: 88f681d5b740 [ 2047.264219] RBP: 88f7aede4280 R08: R09: 860491b0 [ 2047.268977] R10: R11: 88f785ed0900 R12: 88f681d5b740 [ 2047.273716] R13: 1000 R14: 88f8645ed010 R15: 181e [ 2047.278481] FS: () GS:88f897c8() knlGS: [ 2047.283269] CS: 0010 DS: ES: CR0: 80050033 [ 2047.288017] CR2: 0008 CR3: 000160e42000 CR4: 06e0 [ 2047.292772] Call Trace: [ 2047.297454] [ 2047.302061] ? sock_sendmsg+0x58/0x70 [ 2047.306715] svc_tcp_sendmsg+0x121/0x180 [sunrpc] [ 2047.311515] ? nfsd_shutdown_threads+0x90/0x90 [nfsd] [ 2047.316291] svc_tcp_sendto+0x90/0x190 [sunrpc] [ 2047.321083] svc_send+0x4d/0x160 [sunrpc] [ 2047.325811] nfsd+0xd5/0x190 [nfsd] [ 2047.330486] kthread+0xe9/0x110 [ 2047.334999] ? kthread_complete_and_exit+0x20/0x20 [ 2047.339497] ret_from_fork+0x22/0x30 [ 2047.343930] [ 2047.348280] Modules linked in: veth nf_conntrack_netlink xfrm_user xfrm_algo br_netfilter bridge stp llc overlay cmac algif_hash ecb algif_skcipher af_alg bnep tls ip6t_REJECT nf_reject_ipv6 nft_chain_nat xt_nat xt_MASQUERADE nf_nat xt_addrtype ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc amdgpu gpu_sched drm_buddy xc2028 zl10353 rc_fusionhdtv_mce ir_kbd_i2c cx23885 tveeprom altera_ci cx2341x btusb tda18271 btrtl snd_pcm btbcm snd_timer btintel snd btmtk soundcore bluetooth altera_stapl rfkill videobuf2_dvb jitterentropy_rng sha512_ssse3 isofs videobuf2_dma_sg radeon cdrom sha512_generic videobuf2_memops ctr m88ds3103 amd64_edac edac_mce_amd drbg i2c_algo_bit i2c_mux cp210x ansi_cprng drm_ttm_helper dvb_core joydev kvm_amd videobuf2_v4l2 ttm videobuf2_common drm_display_helper usbserial ccp evdev rng_core drm_kms_helper videodev ecdh_generic cec mc kvm ecc rc_core irqbypass xfs pcspkr sp5100_tco [ 2047.348518] k10temp sg watchdog button acpi_cpufreq w83795 jc42 tun loop msr nfsd parport_pc ppdev auth_rpcgss lp nfs_acl lockd parport grace sunrpc efi_pstore drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_compress uas usb_storage raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dm_mod hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common ahci libahci ohci_pci libata tg3 ohci_hcd ptp ehci_pci ehci_hcd i2c_piix4 usbcore scsi_mod pps_core libphy scsi_common usb_common [ 2047.421645] CR2: 0008 [ 2047.427434] ---[ end trace ]--- [ 2047.433257] RIP: 0010:kernel_sendpage+0x1d/0x120 [ 2047.439046] Code: 01 00 e9 46 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 53 48 89 fb 48 83 ec 18 48 8b 47 20 4c 8b 88 a0 00 00 00 4d 85 c9 74 35 <48> 8b 46 08 a8 01 75 63 66 90 48 89 f0 48 8b 00 f6 c4 02 74 5c 80 [ 2047.451057] RSP: 0018:b12541e2fdc0 EFLAGS: 00010282 [ 2047.457127] RAX: 86733e60 RBX: 88f681d5b740 RCX: 1000 [ 2047.463252] RDX: RSI: RDI: 88f681d5b740 [ 2047.469361] RBP: 88f7aede4280 R08: R09: 860491b0 [ 2047.475419] R10: R11: 88f785ed0900 R12: 88f681d5b740 [ 2047.481451] R13: 1000 R14: 88f8645ed010 R15: 181e [ 2047.487369] FS: () GS:88f897c8() knlGS: [ 2047.493199] CS: 0010 DS: ES: CR0: 80050033 [ 2047.498970] CR2: 0008 CR3: 000160e42000 CR4: 06e0
Bug#1025537: nfsd: Kernel Oops while serving NFS
Package: linux-image-5.19.0-13930-g7ebfc85e2cd7 Version: 5.19.0-13930-g7ebfc85e2cd7-23 Followup-For: Bug #1025537 Ok, so the bisect got me down to commit 7ebfc85e2cd7b08f518b526173e9a33b56b3913b (v6.0-rc1~28). This is unfortunate, as it is quite a large one [0]. A caveat to this report is that I'm not 100% sure my way of triggering the issue always worked. This commit OOPSed the first time round, but when it was found to be the first faulty commit at the end of the bisect pass (logs below), I could no longer trigger the bug on a newly rebuilt kernel off the same commit. I now realise that I didn't clean between builds, but I assume `make bindeb-pkg` would start from a fresh clean state. This commit doesn't seem to directly touch NFS code, but does touch the networking state, so it is still a plausible suspect. As per my previous message, the latest kernel also exhibit the issue. Worse so, it seems to even hang the kernel, which didn't seem to happen on earlier versions. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7ebfc85e2cd7b08f518b526173e9a33b56b3913b -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-13930-g7ebfc85e2cd7 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=UTF-8) (ignored: LC_ALL set to en_AU.UTF8), LANGUAGE=en_AU:en_GB Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information -- Bisect log: git bisect start # good: [3d7cb6b04c3f3115719235cc6866b10326de34cd] Linux 5.19 git bisect good 3d7cb6b04c3f3115719235cc6866b10326de34cd # good: [fcf22aefe87101424563a8dd8adec8a75b8c7576] Linux 5.19.11 git bisect good fcf22aefe87101424563a8dd8adec8a75b8c7576 # bad: [e60276b8c11ab4a8be23807bc67b048cfb937dfa] Linux 6.0.8 git bisect bad e60276b8c11ab4a8be23807bc67b048cfb937dfa # good: [7c5c3a6177fa9646884114fc7f2e970b0bc50dc9] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect good 7c5c3a6177fa9646884114fc7f2e970b0bc50dc9 # bad: [5e2e7383b57fa03ec2b00c82bb7f49a4a707c1f7] Merge tag 'pinctrl-v6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl git bisect bad 5e2e7383b57fa03ec2b00c82bb7f49a4a707c1f7 # bad: [83e4b196838d90799a8879e5054a3beecf9ed256] selftests: forwarding: add shebang for sch_red.sh git bisect bad 83e4b196838d90799a8879e5054a3beecf9ed256 # bad: [d974730c8884cd784810b4f2fe903ac882a5fec9] Merge branch 'net-lantiq_xrx200-fix-errors-under-memory-pressure' git bisect bad d974730c8884cd784810b4f2fe903ac882a5fec9 # skip: [7a53e17accce9d310d2e522dfc701d8da7ccfa65] Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost git bisect skip 7a53e17accce9d310d2e522dfc701d8da7ccfa65 # bad: [96f86ff08332d88defd35c330fc6dae219b9e264] Merge tag 'perf-tools-fixes-for-v6.0-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux git bisect bad 96f86ff08332d88defd35c330fc6dae219b9e264 # bad: [e140f731f9807035e967c401198171f316744696] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi git bisect bad e140f731f9807035e967c401198171f316744696 # bad: [6c833c0581f1c15db2e0344da19360cba75a3351] Merge tag 'devicetree-fixes-for-6.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux git bisect bad 6c833c0581f1c15db2e0344da19360cba75a3351 # skip: [8b30b09317ec6fda5f36a428e9e331253b5c4739] dt-bindings: rtc: nuvoton: add NCT3018Y Real Time Clock git bisect skip 8b30b09317ec6fda5f36a428e9e331253b5c4739 # good: [668c3c237f5ddc2889879b08f26d2374231f3287] Merge tag 'sound-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 668c3c237f5ddc2889879b08f26d2374231f3287 # good: [a9e9c93966afdaae74a6a7533552391646b93f2c] Documentation/mm: add details about kmap_local_page() and preemption git bisect good a9e9c93966afdaae74a6a7533552391646b93f2c # good: [c235698355fa94df7073b51befda7d4be00a0e23] Merge tag 'cxl-for-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl git bisect good c235698355fa94df7073b51befda7d4be00a0e23 # bad: [7ebfc85e2cd7b08f518b526173e9a33b56b3913b] Merge tag 'net-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net git bisect bad 7ebfc85e2cd7b08f518b526173e9a33b56b3913b # good: [786da5da5671c2d4cf812fe1ccc980bdde30c69e] Merge tag 'ceph-for-5.20-rc1' of https://github.com/ceph/ceph-client git bisect good 786da5da5671c2d4cf812fe1ccc980bdde30c69e # good: [996237d9ba4d092469fbfca18995656c32834ac7] Merge branch 'do-not-use-rt_tos-for-ipv6-flowlabel' git bisect good 996237d9ba4d092469fbfca18995656c32834ac7 # good: [fbe8870f72e8e71bb57b883d29c600aaaca6cd20] Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf git bisect good fbe8870f72e8e71bb57b883d29c600aaaca6cd20 # good: [e091ba5cf82714c8691d978781696cd1fc2dec70] Merge tag
Bug#1025537: nfsd: Kernel Oops while serving NFS
Package: src:linux Followup-For: Bug #1025537 Confirming this still happens on the latest version of the kernel. -- Package-specific info: ** Version: Linux version 6.0.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-9.1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-6-amd64 root=UUID=0c917590-acc7-464c-8961-64f79e1d1c69 ro init=/lib/systemd/systemd init=/lib/systemd/systemd ** Tainted: D (128) * kernel died recently, i.e. there was an OOPS or BUG ** Kernel log: ** Model information [ 2046.604163] __pagevec_release+0x1b/0x30 [ 2046.610505] svc_xprt_release+0x1a3/0x1e0 [sunrpc] [ 2046.617070] svc_send+0x59/0x160 [sunrpc] [ 2046.623473] nfsd+0xd5/0x190 [nfsd] [ 2046.629656] kthread+0xe9/0x110 [ 2046.635602] ? kthread_complete_and_exit+0x20/0x20 [ 2046.641456] ret_from_fork+0x22/0x30 [ 2046.647159] [ 2046.652696] Modules linked in: veth nf_conntrack_netlink xfrm_user xfrm_algo br_netfilter bridge stp llc overlay tls cmac algif_hash ecb algif_skcipher af_alg bnep ip6t_REJECT nf_reject_ipv6 nft_chain_nat xt_nat xt_MASQUERADE nf_nat xt_addrtype ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables nfnetlink binfmt_misc amdgpu gpu_sched drm_buddy xc2028 zl10353 rc_fusionhdtv_mce ir_kbd_i2c cx23885 altera_ci tda18271 btusb altera_stapl btrtl btbcm m88ds3103 btintel i2c_mux btmtk cx2341x bluetooth tveeprom videobuf2_dvb dvb_core jitterentropy_rng isofs videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 sha512_ssse3 videobuf2_common sha512_generic amd64_edac videodev cdrom edac_mce_amd radeon ctr kvm_amd mc drbg snd_pcm ccp snd_timer ansi_cprng snd drm_display_helper rng_core cec ecdh_generic cp210x soundcore rc_core usbserial kvm drm_ttm_helper joydev evdev rfkill xfs ttm irqbypass ecc drm_kms_helper i2c_algo_bit pcspkr k10temp [ 2046.652939] sp5100_tco watchdog sg button acpi_cpufreq w83795 jc42 tun loop msr nfsd parport_pc ppdev lp auth_rpcgss nfs_acl parport lockd grace sunrpc drm efi_pstore fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic zstd_compress uas usb_storage raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod dm_mod hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common ohci_pci ahci libahci tg3 libata ohci_hcd ehci_pci ehci_hcd usbcore i2c_piix4 libphy scsi_mod usb_common ptp pps_core scsi_common [ 2046.733846] ---[ end trace ]--- [ 2046.739371] RIP: 0010:release_pages+0xcd/0x500 [ 2046.744879] Code: 84 c0 74 1a 48 8b 04 24 48 8d 54 24 30 49 89 46 08 48 89 44 24 30 4c 89 75 08 48 89 55 10 49 83 c7 08 4c 39 fb 74 75 49 8b 2f <48> 8b 45 08 a8 01 0f 85 58 01 00 00 0f 1f 44 00 00 4d 85 ed 74 0e [ 2046.756004] RSP: 0018:af7a811cfe30 EFLAGS: 00010206 [ 2046.761509] RAX: 0007 RBX: 8faf16948b78 RCX: eaa8c45c8608 [ 2046.767032] RDX: af7a811cfe60 RSI: af7a811cfe60 RDI: eaa8c45c8608 [ 2046.772518] RBP: 0017c000 R08: eaa8c4ba4988 R09: 00018bf0 [ 2046.777973] R10: 0003 R11: R12: [ 2046.783387] R13: R14: eaa8c4ba4988 R15: 8faf16948b28 [ 2046.788737] FS: () GS:8fb017c8() knlGS: [ 2046.794102] CS: 0010 DS: ES: CR0: 80050033 [ 2046.799361] CR2: 7f505ca0db28 CR3: 000108692000 CR4: 06e0 [ 2047.009929] stack segment: [#7] PREEMPT SMP NOPTI [ 2047.015823] CPU: 1 PID: 2244 Comm: nfsd Tainted: G D 6.0.0-6-amd64 #1 Debian 6.0.12-1 [ 2047.021769] Hardware name: HP ProLiant MicroServer, BIOS O41 10/01/2013 [ 2047.027727] RIP: 0010:release_pages+0xcd/0x500 [ 2047.033679] Code: 84 c0 74 1a 48 8b 04 24 48 8d 54 24 30 49 89 46 08 48 89 44 24 30 4c 89 75 08 48 89 55 10 49 83 c7 08 4c 39 fb 74 75 49 8b 2f <48> 8b 45 08 a8 01 0f 85 58 01 00 00 0f 1f 44 00 00 4d 85 ed 74 0e [ 2047.046097] RSP: 0018:af7a81133e30 EFLAGS: 00010206 [ 2047.052343] RAX: 0007 RBX: 8faf1685cb78 RCX: eaa8c45a3e08 [ 2047.058605] RDX: af7a81133e60 RSI: af7a81133e60 RDI: eaa8c45a3e08 [ 2047.064809] RBP: 0017c000 R08: eaa8c45cba48 R09: 0077 [ 2047.071008] R10: 2d40 R11: R12: [ 2047.077241] R13: R14: eaa8c45cba48 R15: 8faf1685cb28 [ 2047.083490] FS: () GS:8fb017c8() knlGS: [ 2047.089783] CS: 0010 DS: ES: CR0: 80050033 [ 2047.096089] CR2: 7f505ca0db28 CR3: 00016dafa000 CR4: 06e0 [ 2047.102466] Call Trace: [ 2047.108808] [ 2047.115136] ? nfsd_shutdown_threads+0x90/0x90
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
On Wed, 2022-12-21 at 19:39 +0530, Nilesh Patra wrote: > On Wed, 21 Dec 2022 12:32:25 +0100 olivier sallou > wrote: > > On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote: > > > looks like a python3 issue (though was already adapter to py3...) > > > > > > will have a look and reproduce > > > > I could reproduce and found an issue with demo_checker.py handling > > with > > python3 > > > > I have a patch. will test it and upload > > I wrote a patch as well, and was going to upload, but you beat me to > it, hah :/ sorry, I did not set me as bug owner but sent comments anyway so that others are aware I was on issue and this package is so long to build. > My patch is quite similar to yours, though. > I fixed py2 / py3 bytes error in 2 places and skipped mason2 tests as described in patch and previous message Just uploaded fixed package Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
upstream, in develop branch has disabled mason2 testing for gcc > 10 , don't know why, but let's do the same as it is the one failing now with indeed superior gcc I am adapting the patch and testing again. gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
I pushed a patch d/patches/fix_python3_tests whic fixes almost all test issues(python3 related) BUT remains a failing test with mason2 which is not related to py3 issue (no bytes-like error) after build, can be reproduced with in a temp dir: python3 /<>/apps/mason2/tests/run_tests.py /opt/debian/build-area/seqan2-2.4.0+dfsg /<>/obj-x86_64- linux-gnu/ it basically compare some generated files with some comparison files and for mason2 they are different, and program itself raise no error but result not as expected. Seems that many sequences output result are shifted by 1 character -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
On Wed, 2022-12-21 at 11:02 +0100, olivier sallou wrote: > looks like a python3 issue (though was already adapter to py3...) > > will have a look and reproduce I could reproduce and found an issue with demo_checker.py handling with python3 I have a patch. will test it and upload > > Olivier > > -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026492: seqan2: FTBFS: TypeError: a bytes-like object is required, not 'str'
looks like a python3 issue (though was already adapter to py3...) will have a look and reproduce Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Bug#1026056: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
after investigation, logol does not find anymore libswipl.so.8, need version providing .so.9 compiled program link to .so.x versions, forcing package recompilation Le mar. 13 déc. 2022 à 22:03, Paul Gevers a écrit : > Source: swi-prolog, logol > Control: found -1 swi-prolog/9.0.2+dfsg-1 > Control: found -1 logol/1.7.9+dfsg-5 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > swi-prolog from testing9.0.2+dfsg-1 > logol from testing1.7.9+dfsg-5 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. The issue > *looks* similar to bug 1022253, but now on all architectures. > > Currently this regression is blocking the migration of swi-prolog to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found > on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=swi-prolog > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/29303003/log.gz > > calling logol with parameters -g 1799.logol -s 1799.fasta -dna > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied) > at java.base/java.io.FileOutputStream.open0(Native Method) > at java.base/java.io > .FileOutputStream.open(FileOutputStream.java:293) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:235) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:155) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > at > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > at > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > at > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > at > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > at org.apache.log4j.LogManager.(LogManager.java:127) > at org.apache.log4j.Logger.getLogger(Logger.java:117) > at org.irisa.genouest.logol.Logol.(Unknown Source) > For help, use option -h > INFO org.irisa.genouest.logol.Logol - Using configuration file: > /usr/share/logol/prolog/logol.properties > INFO org.irisa.genouest.logol.Logol - option g called with 1799.logol > INFO org.irisa.genouest.logol.Logol - option s called with 1799.fasta > INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, > using defaults > INFO org.irisa.genouest.logol.Logol - option dna called > INFO org.irisa.genouest.logol.Logol - Start analyse to create grammar > analyser > Executing prolog for pre-analyse > java.io.FileNotFoundException: > /tmp/1799.logol.38da5a9d-c2ac-4a7d-8eb3-8c05b42f5c04.pre.res (No such > file or directory) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io > .FileInputStream.open(FileInputStream.java:216) > at java.base/java.io > .FileInputStream.(FileInputStream.java:157) > at java.base/java.io.FileReader.(FileReader.java:75) > at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown > Source) > at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown > Source) > at org.irisa.genouest.logol.Logol.analyse(Unknown Source) > at org.irisa.genouest.logol.Logol.execute(Unknown Source) > at org.irisa.genouest.logol.Logol.main(Unknown Source) > INFO org.irisa.genouest.logol.Logol - Analyse in progress.. > WARN org.irisa.genouest.logol.SequenceAnalyser - Path to suffix search > tool is not set in system environment. Will try to execute directly but > may fail if not in PATH of current user > Exception in thread "main"
Bug#1026056: swi-prolog breaks logol autopkgtest: Program exited with wrong status code
Tests need to be run as root, or use a specific config file and use non root writable directories. Will try to change tests to do so. Regarding issue itself, programs compiled by swi prolog usually require recompilation on swi prolog updates. Will try to rebuild and check Le mar. 13 déc. 2022, 22:03, Paul Gevers a écrit : > Source: swi-prolog, logol > Control: found -1 swi-prolog/9.0.2+dfsg-1 > Control: found -1 logol/1.7.9+dfsg-5 > Severity: serious > Tags: sid bookworm > User: debian...@lists.debian.org > Usertags: breaks needs-update > > Dear maintainer(s), > > With a recent upload of swi-prolog the autopkgtest of logol fails in > testing when that autopkgtest is run with the binary packages of > swi-prolog from unstable. It passes when run with only packages from > testing. In tabular form: > > passfail > swi-prolog from testing9.0.2+dfsg-1 > logol from testing1.7.9+dfsg-5 > all others from testingfrom testing > > I copied some of the output at the bottom of this report. The issue > *looks* similar to bug 1022253, but now on all architectures. > > Currently this regression is blocking the migration of swi-prolog to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? > > More information about this bug and the reason for filing it can be found > on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > [1] https://qa.debian.org/excuses.php?package=swi-prolog > > > https://ci.debian.net/data/autopkgtest/testing/amd64/l/logol/29303003/log.gz > > calling logol with parameters -g 1799.logol -s 1799.fasta -dna > log4j:ERROR setFile(null,true) call failed. > java.io.FileNotFoundException: /var/log/logol/logol.log (Permission denied) > at java.base/java.io.FileOutputStream.open0(Native Method) > at java.base/java.io > .FileOutputStream.open(FileOutputStream.java:293) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:235) > at java.base/java.io > .FileOutputStream.(FileOutputStream.java:155) > at org.apache.log4j.FileAppender.setFile(FileAppender.java:294) > at > org.apache.log4j.FileAppender.activateOptions(FileAppender.java:165) > at > org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172) > at > > org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104) > at > > org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842) > at > > org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768) > at > > org.apache.log4j.PropertyConfigurator.parseCatsAndRenderers(PropertyConfigurator.java:672) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:516) > at > > org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580) > at > > org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526) > at org.apache.log4j.LogManager.(LogManager.java:127) > at org.apache.log4j.Logger.getLogger(Logger.java:117) > at org.irisa.genouest.logol.Logol.(Unknown Source) > For help, use option -h > INFO org.irisa.genouest.logol.Logol - Using configuration file: > /usr/share/logol/prolog/logol.properties > INFO org.irisa.genouest.logol.Logol - option g called with 1799.logol > INFO org.irisa.genouest.logol.Logol - option s called with 1799.fasta > INFO org.irisa.genouest.logol.Logol - No maximum solutions defined, > using defaults > INFO org.irisa.genouest.logol.Logol - option dna called > INFO org.irisa.genouest.logol.Logol - Start analyse to create grammar > analyser > Executing prolog for pre-analyse > java.io.FileNotFoundException: > /tmp/1799.logol.38da5a9d-c2ac-4a7d-8eb3-8c05b42f5c04.pre.res (No such > file or directory) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io > .FileInputStream.open(FileInputStream.java:216) > at java.base/java.io > .FileInputStream.(FileInputStream.java:157) > at java.base/java.io.FileReader.(FileReader.java:75) > at org.irisa.genouest.logol.Logol.loadVariables2Postpone(Unknown > Source) > at org.irisa.genouest.logol.Logol.generatePreAnalysis(Unknown > Source) > at org.irisa.genouest.logol.Logol.analyse(Unknown Source) > at org.irisa.genouest.logol.Logol.execute(Unknown Source) > at org.irisa.genouest.logol.Logol.main(Unknown Source) > INFO org.irisa.genouest.logol.Logol - Analyse in progress.. > WARN org.irisa.genouest.logol.SequenceAnalyser - Path to suffix search > tool is not set in system environment. Will try to execute directly
Bug#1025537: nfsd: Kernel Oops while serving NFS
Hi Salvatore, On Fri 09 Dec 2022 at 22:22:49 +0100, Salvatore Bonaccorso wrote: On testing/bookworm, since booting on a 6-versioned linux-image, I have noticed frequent hang ups of the nfs server, rendering it mostly unusable. This is accompanied with Kernel Oops in the dmesg. This sounds similar to previous bugs #1014793 and #1020548, both RESOLVED by later patches. How easy can you trigger and reproduce the issue? If you can easily reach that situation, can you try to bisect the issue? Easiest would be to first pin point between Debian revisions, and later further bisect in upstream stable series. Do you have the possibility to do that? It seems to be fairly reliable. I'll give that a go, starting with * linux-image-5.19.0-2-amd64_5.19.11-1_amd64.deb * linux-image-6.0.0-1-amd64_6.0.2-1_amd64.deb I'm not certain how to bisect further. Which source and which kconfig should I use to build intermediate commits? -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.
Bug#1025537: nfsd: Kernel Oops while serving NFS
On Tue 06 Dec 2022 at 15:16:06 +0100, Diederik de Haas wrote: What's the version of NFS you're using? The clients are recent Linux hosts, and one Kodi 19.x. I don't specify a version in either their fstab or the server's exports. From my reading of the manpages, it seems that the client will start from 4.2 and go down. For the server, it _may_ vary due to the /etc/exports. I include mine below, as I'm not certain how to understand the `fsid` logic, though I think in my case it's a simple tree rooted at /. /home 192.168.103.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999) :::::/64(rw,no_subtree_check,crossmnt,all_squash,anongid=999) 192.168.42.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999) /data 192.168.103.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999) :::::/64(rw,no_subtree_check,crossmnt,all_squash,anongid=999) 192.168.42.0/24(rw,no_subtree_check,crossmnt,all_squash,anongid=999) /srv/debian-live 192.168.103.0/24(ro,async,subtree_check,no_root_squash) :::::/64(ro,async,subtree_check,no_root_squash) 192.168.42.0/24(ro,async,subtree_check,no_root_squash) /run/archiso/bootmnt 192.168.103.0/24(ro,async,subtree_check,no_root_squash) :::::/64(ro,async,subtree_check,no_root_squash) 192.168.42.0/24(ro,async,subtree_check,no_root_squash) Note that additional filesystems are mounted in subdirectories of /data. -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.
Bug#1025537: nfsd: Kernel Oops while serving NFS
Ok, looks like v3, if I read this correctly. [9:09:42] @supahwinch ~$ /usr/sbin/rpcinfo -p 130 ↵ program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 151 udp 4002 mountd 151 tcp 4002 mountd 152 udp 4002 mountd 152 tcp 4002 mountd 153 udp 4002 mountd 153 tcp 4002 mountd 1000241 udp 4000 status 1000241 tcp 4000 status 133 tcp 2049 nfs 134 tcp 2049 nfs 1002273 tcp 2049 nfs_acl 1000211 udp 53497 nlockmgr 1000213 udp 53497 nlockmgr 1000214 udp 53497 nlockmgr 1000211 tcp 38889 nlockmgr 1000213 tcp 38889 nlockmgr 1000214 tcp 38889 nlockmgr [9:09:44] @supahwinch ~$ sudo nfsstat –s 0s Server rpc stats: calls badcalls badfmt badauthbadclnt 447324 0 0 0 0 Server nfs v3: null getattr setattr lookup access 4 0% 15575 3% 0 0% 399007 89% 8 0% readlink read writecreate mkdir 9478 2% 630% 0 0% 0 0% 0 0% symlink mknodremove rmdir rename 0 0% 0 0% 0 0% 0 0% 0 0% link readdir readdirplus fsstat fsinfo 0 0% 0 0% 23185 5% 0 0% 4 0% pathconf commit 0 0% 0 0% -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted.
