Bug#1037142: linux-image-6.1.0-9-amd64: AMD 7900XTX GPU several issues with Linux 6.1 affecting normal usage

[AAF]

Package: src:linux
Version: 6.1.27-1
Severity: important
Tags: upstream
X-Debbugs-Cc: and...@posteo.net

Dear Maintainer,

With Linux 6.1 up to 6.1.31 (problems with framebuffer lag started
around Linux 6.0.2), using an AMD 7900XTX GPU, the following
behaviour is observed:

Multiple Screens, with high refresh rates, ex: HDMI 120Hz and
DisplayPort 144Hz:
- white stripe during Display Manager start
- drm framebuffer console lag, on tty2 for example, when typing the characters 
appear with a
  delay or not at all, clearing the screen with CTRL+L is slow
- mouse cursor appears for SDDM here, but is invisible for the live
  desktop (X11) session then.
- with multiple Monitors idle power usage observed as reported by
  sensors PPT value is ~90W (2 screens, with high refresh rates of 120
  and 144 Hz)
- booting, wait until Display Manager (SDDM) starts, switch to tty2,
  switch back to tty7 then display hangs for a while and kernel log has
  the following, or then recovers and hangs again and a restart of the
  computer is required:

[Sat May 13 12:55:35 2023] [ cut here ]
[Sat May 13 12:55:35 2023] refcount_t: underflow; use-after-free.
[Sat May 13 12:55:35 2023] WARNING: CPU: 15 PID: 1307 at lib/refcount.c:28 
refcount_warn_saturate+0xba/0x110
...
[Sat May 13 12:55:35 2023] CPU: 15 PID: 1307 Comm: InputThread Not tainted 
6.1.0-9-amd64 #1  Debian 6.1.27-1
[Sat May 13 12:55:35 2023] Hardware name: ASUS System Product Name/ROG 
CROSSHAIR VIII DARK HERO, BIOS 4304 12/12/2022
[Sat May 13 12:55:35 2023] RIP: 0010:refcount_warn_saturate+0xba/0x110
[Sat May 13 12:55:35 2023] Code: 01 01 e8 69 ef b6 ff 0f 0b c3 cc cc cc cc 80 
3d 5a 7c 6d 01 00 75 85 48 c7 c7 50 71 b5 8a c6 05 4a 7c 6d 01 01 e8 46 ef b6 
ff <0f> 0b c3 cc cc cc cc 80 3d 35 7c 6d 01 00 0f 85 5e ff ff ff 48 c7
[Sat May 13 12:55:35 2023] RSP: 0018:9a38c596fad8 EFLAGS: 00010286
[Sat May 13 12:55:35 2023] RAX:  RBX: 0001 RCX: 

[Sat May 13 12:55:35 2023] RDX: 0002 RSI: 8ab3fa66 RDI: 

[Sat May 13 12:55:35 2023] RBP: 8c4390e40090 R08:  R09: 
9a38c596f948
[Sat May 13 12:55:35 2023] R10: 0003 R11: 8c4aaf27dc28 R12: 
0002
[Sat May 13 12:55:35 2023] R13: 8c4390e4 R14:  R15: 
0004
[Sat May 13 12:55:35 2023] FS:  7f4e17fff6c0() 
GS:8c4a8edc() knlGS:
[Sat May 13 12:55:35 2023] CS:  0010 DS:  ES:  CR0: 80050033
[Sat May 13 12:55:35 2023] CR2: 560fc0535020 CR3: 00011438 CR4: 
00750ee0
[Sat May 13 12:55:35 2023] PKRU: 5554
[Sat May 13 12:55:35 2023] Call Trace:
[Sat May 13 12:55:35 2023]  
[Sat May 13 12:55:35 2023]  dc_resource_state_destruct+0x34/0x80 [amdgpu]
[Sat May 13 12:55:35 2023]  dc_release_state+0x2a/0x50 [amdgpu]
[Sat May 13 12:55:35 2023]  dm_atomic_destroy_state+0x1c/0x30 [amdgpu]
[Sat May 13 12:55:35 2023]  drm_atomic_state_default_clear+0x236/0x2e0 [drm]
[Sat May 13 12:55:35 2023]  __drm_atomic_state_free+0x66/0xa0 [drm]
[Sat May 13 12:55:35 2023]  drm_atomic_helper_update_plane+0x101/0x150 
[drm_kms_helper]
[Sat May 13 12:55:35 2023]  drm_mode_cursor_universal+0x128/0x240 [drm]
[Sat May 13 12:55:35 2023]  drm_mode_cursor_common+0x102/0x230 [drm]
[Sat May 13 12:55:35 2023]  ? drm_mode_cursor_ioctl+0x70/0x70 [drm]
[Sat May 13 12:55:35 2023]  drm_ioctl_kernel+0xc9/0x170 [drm]
[Sat May 13 12:55:35 2023]  drm_ioctl+0x22f/0x410 [drm]
[Sat May 13 12:55:35 2023]  ? drm_mode_cursor_ioctl+0x70/0x70 [drm]
[Sat May 13 12:55:35 2023]  amdgpu_drm_ioctl+0x4a/0x80 [amdgpu]
[Sat May 13 12:55:35 2023]  __x64_sys_ioctl+0x90/0xd0
[Sat May 13 12:55:35 2023]  do_syscall_64+0x5b/0xc0
[Sat May 13 12:55:35 2023]  ? fpregs_assert_state_consistent+0x22/0x50
[Sat May 13 12:55:35 2023]  ? exit_to_user_mode_prepare+0x139/0x1d0
[Sat May 13 12:55:35 2023]  ? syscall_exit_to_user_mode+0x17/0x40
[Sat May 13 12:55:35 2023]  ? do_syscall_64+0x67/0xc0
[Sat May 13 12:55:35 2023]  ? do_syscall_64+0x67/0xc0
[Sat May 13 12:55:35 2023]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[Sat May 13 12:55:35 2023] RIP: 0033:0x7f4e3cf1cafb
[Sat May 13 12:55:35 2023] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 
24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 
05 <89> c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[Sat May 13 12:55:35 2023] RSP: 002b:7f4e17ffd1e0 EFLAGS: 0246 
ORIG_RAX: 0010
[Sat May 13 12:55:35 2023] RAX: ffda RBX: 7f4e17ffd270 RCX: 
7f4e3cf1cafb
[Sat May 13 12:55:35 2023] RDX: 7f4e17ffd270 RSI: c02464bb RDI: 
000f
[Sat May 13 12:55:35 2023] RBP: 7f4e17ffd270 R08:  R09: 
0001
[Sat May 13 12:55:35 2023] R10: 0f00 R11: 0246 R12: 
c02464bb
[Sat May 13 12:55:35 2023] R13: 000f R14: 0008 R15: 
55adf2afb000
[Sat May 13 

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Luca Boccassi]

On Tue, 6 Jun 2023 at 11:45, Sean Whitton  wrote:
>
> Hello,
>
> On Sun 04 Jun 2023 at 01:35PM +01, Luca Boccassi wrote:
>
> > In the interest of speeding things up a bit, I've done some rewording
> > as suggested - moved to the exiting chapter, and use the systemd files
> > only as an example:
> >
> > https://salsa.debian.org/bluca/policy/-/commit/5058bd2f8c742c3d8695e2c98ee3a597d431ffd7
> >
> > Off-topic - any reasons MRs are disabled on the policy repo? It would
> > be much nicer and quicker to use the Gitlab review process I think,
> > like we do for other packages.
>
> It's actually on-topic -- can you post your proposed patch to this bug
> for inline review, please?  This is documented in README.md.  The main
> reason we have MRs disabled is that we want a complete record of the
> discussion that led up to a Policy change to be recorded in the BTS.
>
> A secondary reason is that I strongly disprefer doing patch review using
> an interface other than my mail client.

Well, the README says:

"Please submit a bug to the BTS, either with patches attached, or a
reference to a git branch that is publically fetchable."

The whole project is moving toward git and Salsa, and it is very
annoying to have to do drive-by contributions via email, it really
sucks as a process for contributors, so please consider re-evaluating
this in the future. Patch attached.

Kind regards,
Luca Boccassi
From 5058bd2f8c742c3d8695e2c98ee3a597d431ffd7 Mon Sep 17 00:00:00 2001
From: Luca Boccassi 
Date: Mon, 8 May 2023 03:21:14 +0100
Subject: [PATCH] Forbid using dpkg-divert/alternatives when there are native
 mechanisms

The supported mechanism for augmenting, changing, overriding and
disabling systemd configuration files is natively supported and fully
integrated in Debian, via drop-ins, hierarchical overrides, and
masking. dpkg-divert is not integrated in systemd tools so its use
is completely hidden in logs and status interfaces, and it is specific
to Debian and thus diverges from what users expect as implemented by
all other distros, going against one of the core goals of the systemd
project which is to provide a uniform interface regardless of distro
vendor or flavour.

Clarify that diversions and alternatives should only be used when
needed, with cooperation, and must not be used when there are native
mechanisms to obtain the same goals, and use systemd files as an
example.
---
 policy/ap-pkg-alternatives.rst |  4 
 policy/ap-pkg-diversions.rst   |  4 
 policy/ch-binary.rst   | 31 +++
 3 files changed, 39 insertions(+)

diff --git a/policy/ap-pkg-alternatives.rst b/policy/ap-pkg-alternatives.rst
index ffa2163..1cfd3e6 100644
--- a/policy/ap-pkg-alternatives.rst
+++ b/policy/ap-pkg-alternatives.rst
@@ -24,3 +24,7 @@ See the :manpage:`update-alternatives(8)` man page for details.
 If ``update-alternatives`` does not seem appropriate you may wish to
 consider using diversions instead.
 
+Do not attempt to use alternatives for files belonging or used by components
+that support native overriding mechanisms, such as ``systemd`` unit files. Read
+:doc:`ch-binary` for more information.
+
diff --git a/policy/ap-pkg-diversions.rst b/policy/ap-pkg-diversions.rst
index fe360d1..09367d7 100644
--- a/policy/ap-pkg-diversions.rst
+++ b/policy/ap-pkg-diversions.rst
@@ -81,3 +81,7 @@ when the file does not exist.
 Do not attempt to divert a conffile, as ``dpkg`` does not handle it
 well.
 
+Do not attempt to divert files belonging or used by components that support
+native overriding mechanisms, such as ``systemd`` unit files. Read
+:doc:`ch-binary` for more information.
+
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index e517f26..e36d028 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -371,6 +371,37 @@ against earlier versions of something that previously did not use
 ``update-alternatives``; this is an exception to the usual rule that
 versioned conflicts should be avoided.)
 
+Diversions and alternatives should be used primarily as a tool for local
+administrators and local packages to override the behaviour of Debian. Its use
+between Debian packages should be rare, should involve coordination between the
+packages and their maintainers, and must only be used to solve problems that
+cannot be handled through other facilities or native mechanisms.
+In other words, packages in Debian must not divert a file from another package
+unless this is arranged cooperatively between the packages to solve some
+specific and unusual problem.
+
+For example, configuration files that are used by ``systemd`` components, such
+as `units,
+`_
+`udev rules,
+`_
+`tmpfiles.d,
+`_
+`modules-load.d,

Bug#1035733: debian -policy: packages must not use dpkg-divert to override default systemd configuraton files

[Sean Whitton]

Hello,

On Sun 04 Jun 2023 at 01:35PM +01, Luca Boccassi wrote:

> In the interest of speeding things up a bit, I've done some rewording
> as suggested - moved to the exiting chapter, and use the systemd files
> only as an example:
>
> https://salsa.debian.org/bluca/policy/-/commit/5058bd2f8c742c3d8695e2c98ee3a597d431ffd7
>
> Off-topic - any reasons MRs are disabled on the policy repo? It would
> be much nicer and quicker to use the Gitlab review process I think,
> like we do for other packages.

It's actually on-topic -- can you post your proposed patch to this bug
for inline review, please?  This is documented in README.md.  The main
reason we have MRs disabled is that we want a complete record of the
discussion that led up to a Policy change to be recorded in the BTS.

A secondary reason is that I strongly disprefer doing patch review using
an interface other than my mail client.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed

[Tim Small]

Hi Stephen,

Sorry for the delay - busy with family, work and other matters...  I've 
restored a backup to a VM, and re-run the upgrade there, taking care to 
follow exactly the upgrade instructions at:


https://www.debian.org/releases/testing/amd64/release-notes.en.pdf

...this lead to a recurrence of the failure.

It looks like the problem is that the call to:

dkms remove -m ddcci -v 0.3.3

...which is made by /var/lib/dpkg/info/ddcci-dkms.prerm isn't working.

On the restored backup, running this command manually doesn't uninstall 
the module, it also doesn't print any output - it just exits with return 
code 0.


When the same ddcci-dkms 0.3.3-1 package is installed and built on a 
brand new Debian 11 VM, the prerm script works as expected and 
uninstalls correctly (and verbosely). This sounds like the same 
(correct) behaviour which you saw in your testing.


I'll try and look into what's causing the dkms script to silently no-op 
on the failing VM in the next day or so, and let you know what I find.


Cheers,

Tim.

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Sean Whitton]

Hello,

On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:

> So I think the only realistic options for packages that hard-require
> this functionality (not all do) are:
>
> 1. Depends: systemd | systemd-tmpfiles
> 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
> 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles
>
> (where the third one is equivalent to one of the first two, depending on
> how default-systemd-tmpfiles was implemented), possibly with some more
> less-preferred options between the first "|" and the virtual-package
> fallback.

As you wrote in another message, it's very cheap future-proofing to use
a virtual package for whichever actual solution we're implementing, so I
think we should do that.

> Another possible mitigation which I haven't previously seen proposed
> is giving *elogind* a Depends or Recommends on systemd-*-standalone.
> I think that would work to mitigate the failure mode with (1.) and (B.),
> and the installed-size argument seems less interesting here because the
> sort of systems that require elogind are already much larger anyway.
> Would the elogind maintainers be willing to consider this? Does anyone
> see a reason why it wouldn't work?

So to confirm, you think that if the elogind maintainers did this, then
default-systemd-tmpfiles could point at systemd rather than
systemd-standalone-tmpfiles, which the systemd maintainers prefer, but
in addition, there aren't any scenarios in which people's systems are
likely to be re-arranged when they don't want them to be?

> As a maintainer of system services, I would not be at all happy with
> expecting the maintainer of every system service that requires tmpfiles
> to have this conversation again and again. Obviously as a technical
> committee member and occasional Policy contributor, I've chosen to take
> on some of the burden of decisions like this one; but when I'm working
> on dbus or polkitd or even openarena-server, I should be able to follow
> a project decision, and be reasonably confident that I won't get angry
> RC bug reports about it (and if I do, I should be able to refer the bug
> reporter to a project decision instead of having to re-litigate it).
> Putting this sort of thing on individual package maintainers seems like
> a recipe for making it no longer fun to maintain a package.

Yes, let's figure out a standard solution and write it in Policy.
The reasoning may well be applicable to similar things in the future.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Sean Whitton]

Hello Emilio,

On Thu 11 May 2023 at 12:30PM +02, Emilio Pozuelo Monfort wrote:

> I think you're conflating two independent things.
>
> If you override the dpkg maintainer to remove that warning that occurs on
> derivatives, then anyone could NMU dpkg and the maintainer wouldn't introduce
> it back, effectively removing the warning from "dpkg upstream".
>
> OTOH if the dpkg maintainer switches to non-native packages, anyone could NMU
> it adding the change as a patch, however the maintainer will just NACK the NMU
> before or after it happens.
>
> So I don't see a problem with dpkg being native, just like e.g. apt is, and
> that won't magically solve the issue at hand.

I don't think the TC has or should have any authority over dpkg
upstream, but with dpkg being a native package, any implementation of
our decision for the Debian archive is also implemented for dpkg
upstream.  And it might be that the dpkg developers would be against the
TC override solely or mostly because of this fact.  So possibly changing
that would resolve things peacefully.

I don't see how this conflates things, but would be grateful for more
explanation if you still think I'm doing so.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1037140: ia32-libs-gtk: uninstallable in wheezy-elts

[Andreas Beckmann]

Package: ia32-libs-gtk
Version: 1:0.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: close -1 1:0.1+rm

Hi,

during a test with piuparts I noticed your package failed to install in
wheezy-elts:

  The following packages have unmet dependencies:
   ia32-libs-gtk : Depends: ia32-libs-i386
   Depends: ia32-libs-gtk-i386

In the end it seems to boil down to an unsatisfiable dependency on
python:i386.


cheers,

Andreas

Bug#1037139: gst-plugins-bad1.0: Please switch gstreamer1.0-wpe to the new 2.0 WPE API

[Alberto Garcia]

Source: gst-plugins-bad1.0
Version: 1.22.3-1
Severity: normal
Tags: patch

Hi,

the new 2.40.x branch of the WPE WebKit engine introduced a new 2.0
API. The GStreamer WPE plugin uses the 1.1 API, which upstream would
like to remove sooner or later.

The wpewebkit-2.0 packages have already been uploaded to experimental.

Since WPE WebKit in Debian only has two reverse dependencies I would
like to make the transition, move wpewebkit-2.0 to unstable and get
rid of wpewebkit-1.1.

One of the reverse dependencies (cog) is ready and also available in
experimental.

The other one is gstreamer1.0-wpe. This has been updated upstream to
support the 2.0 API but it hasn't been released yet (it will likely
happen after summer if I'm not wrong). However the patch can be cherry
picked to the stable branch.

I'm attaching the debdiff in case you want to consider switching the
gst-wpe plugin to the 2.0 API in experimental. Once that is done I'm
ready to move the wpewebkit-2.0 packages to unstable.

Thanks,

Berto
diff -Nru gst-plugins-bad1.0-1.22.3/debian/changelog 
gst-plugins-bad1.0-1.22.3/debian/changelog
--- gst-plugins-bad1.0-1.22.3/debian/changelog  2023-05-21 14:31:50.0 
+0200
+++ gst-plugins-bad1.0-1.22.3/debian/changelog  2023-06-06 11:05:15.0 
+0200
@@ -1,3 +1,13 @@
+gst-plugins-bad1.0 (1.22.3-2) experimental; urgency=medium
+
+  [ Alberto Garcia ]
+  * Build the gst-wpe plugin using the 2.0 WPE API.
+- debian/patches/wpe-2.0-api.patch: Cherry pick the corresponding
+  upstream commit (fe4f034c8a).
+- debian/control: Build depend on libwpewebkit-2.0-dev.
+
+ -- Alberto Garcia   Tue, 06 Jun 2023 11:05:15 +0200
+
 gst-plugins-bad1.0 (1.22.3-1) experimental; urgency=medium
 
   * Team upload
diff -Nru gst-plugins-bad1.0-1.22.3/debian/control 
gst-plugins-bad1.0-1.22.3/debian/control
--- gst-plugins-bad1.0-1.22.3/debian/control2023-05-21 14:31:50.0 
+0200
+++ gst-plugins-bad1.0-1.22.3/debian/control2023-06-06 11:04:47.0 
+0200
@@ -57,7 +57,7 @@
libopencv-dev (>= 3.0.0) [amd64 arm64 armel armhf i386 mips64el 
mipsel ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
opencv-data [amd64 arm64 armel armhf i386 mips64el mipsel 
ppc64el s390x alpha hppa hurd-i386 m68k powerpc ppc64 riscv64],
libwpebackend-fdo-1.0-dev (>= 1.8.0) [linux-any],
-   libwpewebkit-1.1-dev (>= 2.28.0) [linux-any],
+   libwpewebkit-2.0-dev [linux-any],
libopenexr-dev,
libopenh264-dev (>= 1.3.0),
libopenjp2-7-dev (>= 2.2),
diff -Nru gst-plugins-bad1.0-1.22.3/debian/patches/series 
gst-plugins-bad1.0-1.22.3/debian/patches/series
--- gst-plugins-bad1.0-1.22.3/debian/patches/series 2023-05-21 
14:31:50.0 +0200
+++ gst-plugins-bad1.0-1.22.3/debian/patches/series 2023-06-06 
11:03:23.0 +0200
@@ -1,2 +1,3 @@
 02_opencv-data-path.patch
 Skip-failing-tests.patch
+wpe-2.0-api.patch
diff -Nru gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch 
gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch
--- gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch  1970-01-01 
01:00:00.0 +0100
+++ gst-plugins-bad1.0-1.22.3/debian/patches/wpe-2.0-api.patch  2023-06-06 
11:05:15.0 +0200
@@ -0,0 +1,246 @@
+From: Philippe Normand 
+Subject: wpe: Add support for the WPEWebKit 2.0 API version
+Origin: 
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/fe4f034c8a2a569c1530a3e98622b0ea1d96a0cb
+Index: gst-plugins-bad1.0-1.22.3/ext/wpe/WPEThreadedView.cpp
+===
+--- gst-plugins-bad1.0-1.22.3.orig/ext/wpe/WPEThreadedView.cpp
 gst-plugins-bad1.0-1.22.3/ext/wpe/WPEThreadedView.cpp
+@@ -186,7 +186,11 @@ initialize_web_extensions (WebKitWebCont
+ const gchar *local_path = gst_wpe_get_devenv_extension_path ();
+ const gchar *path = g_file_test (local_path, G_FILE_TEST_IS_DIR) ? 
local_path : G_STRINGIFY (WPE_EXTENSION_INSTALL_DIR);
+ GST_INFO ("Loading WebExtension from %s", path);
++#if USE_WPE2
++webkit_web_context_set_web_process_extensions_directory (context, path);
++#else
+ webkit_web_context_set_web_extensions_directory (context, path);
++#endif
+ }
+ 
+ static void
+@@ -348,10 +352,14 @@ WPEView* WPEContextThread::createWPEView
+ WPEView* view = nullptr;
+ dispatch([&]() mutable {
+ if (!glib.web_context) {
++#if USE_WPE2
++glib.web_context = 
WEBKIT_WEB_CONTEXT(g_object_new(WEBKIT_TYPE_WEB_CONTEXT, nullptr));
++#else
+ auto *manager = webkit_website_data_manager_new_ephemeral();
+ glib.web_context =
+ webkit_web_context_new_with_website_data_manager(manager);
+ g_object_unref(manager);
++#endif
+ }
+ view = new WPEView(glib.web_context, src, context, display, width, 
height);
+ });
+@@ -407,7 +415,11 @@ WPEView::WPEView(WebKitWebContext* web_c

Bug#1037138: linux-image-6.0.0-4-amd64: Linux kernel appears to not be respecting sysctl config value "net.ipv6.conf.all.disable_ipv6=1"

[Dylan Morrison]

Package: src:linux
Version: 6.0.8-1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: dizzy@domad.science

Dear Maintainer,

I am attempting to disable ipv6 entirely on this machine as it being enabled is 
causing multiple issues with long connection timeouts etc, and I do not have 
ipv6 support from my ISP nor do I use it locally. However, the generally given 
advice to set net.ipv6.conf.all.disable_ipv6 to 1 is having no effect, neither 
setting it in /etc/sysctl.conf nor using command line sysctl. Setting 
net.conf.ipv6..disable_ipv6 works, and is what I am currently doing 
for my primary network interface, but I would like ipv6 disabled globally.
This appears to be a kernel issue afaict, I'm not 100% up on how the sysctl 
mechanism works, but yeah.


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

** Command line:
root=UUID=9195fe01-470b-4e23-8bec-110cf1aa12cc ro quiet splash 
initrd=boot\initrd.img-6.0.0-4-amd64

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[652201.887641] I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887644] Buffer I/O error on dev sr0, logical block 0, async page read
[652201.887653] sr 2:0:0:0: [sr0] tag#7 unaligned transfer
[652201.887654] I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887656] Buffer I/O error on dev sr0, logical block 1, async page read
[652201.887661] sr 2:0:0:0: [sr0] tag#8 unaligned transfer
[652201.887661] I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887662] Buffer I/O error on dev sr0, logical block 2, async page read
[652201.887666] sr 2:0:0:0: [sr0] tag#9 unaligned transfer
[652201.887667] I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887668] Buffer I/O error on dev sr0, logical block 3, async page read
[652201.887672] sr 2:0:0:0: [sr0] tag#10 unaligned transfer
[652201.887673] I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887674] Buffer I/O error on dev sr0, logical block 4, async page read
[652201.887678] sr 2:0:0:0: [sr0] tag#11 unaligned transfer
[652201.887678] I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887679] Buffer I/O error on dev sr0, logical block 5, async page read
[652201.887683] sr 2:0:0:0: [sr0] tag#12 unaligned transfer
[652201.887684] I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887685] Buffer I/O error on dev sr0, logical block 6, async page read
[652201.887689] sr 2:0:0:0: [sr0] tag#13 unaligned transfer
[652201.887690] I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 1 
prio class 2
[652201.887691] Buffer I/O error on dev sr0, logical block 7, async page read
[660275.943849] input: Microsoft X-Box 360 pad 0 as 
/devices/virtual/input/input68
[661843.954123] usb 1-3: USB disconnect, device number 24
[661844.358016] usb 1-3: new full-speed USB device number 25 using xhci_hcd
[661844.757670] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea, 
bcdDevice= 5.0f
[661844.757676] usb 1-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[661844.757677] usb 1-3: Product: Controller
[661844.757679] usb 1-3: Manufacturer: Microsoft
[661844.757680] usb 1-3: SerialNumber: 303336303030383234323338
[661844.769591] input: Microsoft X-Box One S pad as 
/devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input69
[663457.496690] usb 1-3: USB disconnect, device number 25
[663457.905293] usb 1-3: new full-speed USB device number 26 using xhci_hcd
[663458.237568] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea, 
bcdDevice= 5.0f
[663458.237574] usb 1-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[663458.237576] usb 1-3: Product: Controller
[663458.237577] usb 1-3: Manufacturer: Microsoft
[663458.237578] usb 1-3: SerialNumber: 303336303030383234323338
[663458.247343] input: Microsoft X-Box One S pad as 
/devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input70
[672383.489343] usb 1-3: USB disconnect, device number 26
[672384.599744] usb 1-3: new full-speed USB device number 27 using xhci_hcd
[672384.930355] usb 1-3: New USB device found, idVendor=045e, idProduct=02ea, 
bcdDevice= 5.0f
[672384.930361] usb 1-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[672384.930363] usb 1-3: Product: Controller
[672384.930364] usb 1-3: Manufacturer: Microsoft
[672384.930366] usb 1-3: SerialNumber: 303336303030383234323338
[672384.940759] input: Microsoft X-Box One S pad as 
/devices/pci:00/:00:02.1/:16:00.0/usb1/1-3/1-3:1.0/input/input71
[672631.293810] usb 1-3: USB disconnect, device number 27
[672631.933067] usb 1-3: 

Bug#1037127: exim4-config: Example Dovecot authenticator for Exim allows plaintext non TLS AUTH by default

[Marc Haber]

On Mon, Jun 05, 2023 at 02:08:22PM +, Dominic Preston wrote:
> The Exim config should be changed to only advertise AUTH if the connection
> is encrypted, in line with the other plain text authenticators, by adding
> the final three lines below:

I made that MR #9.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1037137: add fp-units-*-win64_*.deb dependency packages required for Windows cross-compilation

[Patrick Schleizer]

Package: fpc
Severity: wishlist

Dear maintainer,

when compiling fpc from upstream, folder 
/usr/lib/fpc/3.2.2/units/x86_64-win64 would contain dependencies 
required for cross-compilation.


(source: Building on Debian, target: compilation for Windows 64 bit)

However, Debian lacks the pre-compiled dependencies for
windows that would normally reside in that folder when compiling from 
fpc upstream sources.


In Debian this would be 
/usr/lib/fpc/3.2.2/units/x86_64-ms-win64/fpc/3.2.2/units/x86_64-win64 in 
comparison to /usr/lib/x86_64-linux-gnu/fpc/3.2.2/units/x86_64-linux 
that are used for amd64 and other architectures.


Kind regards,
Patrick

Bug#1036824: po4a: Describe how to create/maintain pot file from man page

[Martin Quinson]

Hello Helge,

Every po4a-* scripts are deprecated. The right way to go is to use the main
po4a script, using an adequate config file. I think that this is documented in
po4a(1), isn't it?

Which project are we speaking of? I'm really overwhelmed right now but maybe I
could find some time to propose a config file for that project in the future.

Sorry, 
Mt

Le samedi 27 mai 2023 à 13:56 +0200, Helge Kreutzmann a écrit :
> Package: po4a
> Version: 0.69-1
> Severity: wishlist
> 
> Some time ago several po4a tools started emitting warnings and ceased
> working as before. I read that "po4a" is the way to go, however, we
> seriously lack the man power (and knowledge) to rewrite the entire
> machinery. However, I'm gradully trying to improve the system where
> and when possible.
> 
> For this, I have the follwing question/request:
> Given that I have a man page (in nroff or mdoc format) and I want to
> create a pot file from it (not po file, as this page is not yet
> translated). How is this done best/correctly?
> 
> Quite a few explanations in the po4a man pages assume you already have
> some translated text.
> 
> Currently I use something like:
> 
> po4a-updatepo -f man \
>     --option groff_code=verbatim \
>     --option generated \
>     --option untranslated="a.RE,\|" \
>     --option unknown_macros=untranslated \
>     --master "$upstream_manpage" -M utf-8 \
>     -p $tmp1 | grep -v "po4a-updatepo is deprecated. The unified po4a(1)
> program is more convenient and less error prone."
> 
> (Until very recently this used po4a-gettextize, but this stopped working)
> 
> It would be great if you could document the proper solution in the 
> very well written and extensive documentation.
> 
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored:
> LC_ALL set to de_DE.UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages po4a depends on:
> ii  gettext 0.21-12
> ii  libpod-parser-perl  1.65-1
> ii  libsgmls-perl   1.03ii-38
> ii  libsyntax-keyword-try-perl  0.28-1
> ii  libyaml-tiny-perl   1.73-1
> ii  opensp  1.5.2-13+b2
> ii  perl    5.36.0-7
> 
> Versions of packages po4a recommends:
> ii  liblocale-gettext-perl 1.07-5
> ii  libterm-readkey-perl   2.38-2+b1
> ii  libtext-wrapi18n-perl  0.06-10
> ii  libunicode-linebreak-perl  0.0.20190101-1+b5
> 
> po4a suggests no packages.
> 
> -- no debconf information
> 

-- 
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.



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

Bug#1037051: libfinance-quote-perl: Quotes from Yahoo stopped working again.

[Bill Wohler]

Thanks again, David.

I updated /usr/share/perl5/Finance/Quote/YahooJSON.pm from master [1]
and the quotes worked again for me:

1. 
https://github.com/finance-quote/finance-quote/blob/master/lib/Finance/Quote/YahooJSON.pm

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD