Bug#1028538: linux-source: linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc fails at docs for deprecated sphinx module

2023-01-12 Thread vmxevilstar

Re: [sphinx-doc/sphinx] ModuleNotFoundError: No module named
'sphinx.util.pycompat' (Issue #11125)

The module was deprecated at 4.0 and removed at 6.0,
see https://github.com/sphinx-doc/sphinx/pull/7316/files for
deprecation. See
also https://www.sphinx-doc.org/en/master/search.html?q=pycompat. The
import attempt does not come from Sphinx code.


Bug#996839: [PATCH v1] perf script flamegraph: Avoid d3-flame-graph package dependency

2023-01-12 Thread Ian Rogers
On Wed, Jan 11, 2023 at 10:08 AM Andreas Gerstmayr
 wrote:
>
> On 11.01.23 18:13, Ian Rogers wrote:
> > On Wed, Jan 11, 2023 at 5:18 AM Andreas Gerstmayr  
> > wrote:
> >>
> >> On 10.01.23 20:51, Ian Rogers wrote:
> >>> On Tue, Jan 10, 2023 at 10:02 AM Andreas Gerstmayr
> >>>  wrote:
> 
>  On 05.01.23 10:24, Ian Rogers wrote:
> > On Wed, Jan 4, 2023 at 7:04 PM Ian Rogers  wrote:
> >>
> >> Currently flame graph generation requires a d3-flame-graph template to
> >> be installed. Unfortunately this is hard to come by for things like
> >> Debian [1]. If the template isn't installed warn and download it from
> >> jsdelivr CDN. If downloading fails generate a minimal flame graph
> >> again with the javascript coming from jsdelivr CDN.
> >>
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839
> >>
> >> Signed-off-by: Ian Rogers 
> 
>  I'm not entirely convinced that this perf script should make a network
>  request. In my opinion
> 
>  * best would be if this template gets packaged in Debian
>  * alternatively print instructions how to install the template:
> 
> sudo mkdir /usr/share/d3-flame-graph
> sudo wget -O /usr/share/d3-flame-graph/d3-flamegraph-base.html
>  https://cdn.jsdelivr.net/npm/d3-flame-graph@4/dist/templates/d3-flamegraph-base.html
> 
>  * or eventually just embed the entire template (66 KB) in the Python
>  file (not sure if this is permissible though, it's basically a minified
>  HTML/JS blob)?
>  * if the above options don't work, I'd recommend asking the user before
>  making the network request, and eventually persist the template
>  somewhere so it doesn't need to be downloaded every time
> 
>  What do you think?
> >>>
> >>> So the script following this patch is going to try 3 things:
> >>> 1) look for a local template HTML,
> >>> 2) if a local template isn't found warn and switch to downloading the
> >>> CDN version,
> >>> 3) if the CDN version fails to download then use a minimal (embedded
> >>> in the script) HTML file with JS dependencies coming from the CDN.
> >>>
> >>> For (1) there are references in the generated HTML to www.w3.org,
> >>> meaning the HTML isn't fully hermetic - although these references may
> >>> not matter.
> >>
> >> The references to w3.org are XML namespace names. As far as I'm aware
> >> they do not matter, as they are merely identifiers and are never
> >> accessed [1,2]. Therefore the generated HTML file in its current form is
> >> hermetic.
> >>
> >> This was a design decision from the start - the flame graph generation
> >> and the resulting HTML file should not use any external resources loaded
> >> over the network (the external host could be inaccessible or compromised
> >> at any time). I understand that this requirement may not apply to every
> >> user or company.
> >>
> >>> For (2) there will be a download from the CDN of the template during
> >>> the execution of flamegraph. The template is better than (3) as it
> >>> features additional buttons letting you zoom out, etc. The HTML will
> >>> contain CDN references.
> >>> For (3) the generated HTML isn't hermetic and will use the CDN.
> >>>
> >>> For (2) we could give a prompt before trying to download the template,
> >>> or we could change it so that we give the wget command. I wouldn't
> >>> have the wget command require root privileges, I'd say that the
> >>> template could be downloaded and then the path of the download given
> >>> as an option to the flamegraph program. Downloading the file and then
> >>> adding an option to flamegraph seems inconvenient to the user,
> >>> something that the use of urllib in the patch avoids - it is
> >>> essentially just doing this for the user without storing the file on
> >>> disk. I think I prefer to be less inconvenient, and so the state of
> >>> the code at the moment looks best to me. Given that no choice results
> >>> in a fully hermetic HTML file, they seem similar in this regard. Is it
> >>> okay to try a download with urllib? Should there be a prompt? I think
> >>> the warning is enough and allows scripts, etc. using flamegraph to
> >>> more easily function across differing distributions.
> >>
> >> I fully agree, your changes make the flame graph generation more
> >> convenient in case the template is not installed. Also, downloading the
> >> template to a local directory and having to specify the path to the
> >> template every time is an inconvenience.
> >>
> >> I think it is a tradeoff between convenience and security/privacy.
> >> jsdelivr can get compromised, serving malicious JS (well, in that case,
> >> printing instructions to jsdelivr is also flawed :|).
> >> In the end it's up to the maintainers to decide.
> >
> > Agreed. It is something of an issue with the perf tool, I think noted
> > by Arnaldo and Linus, that it has too many dependencies. We also have
> > a problem that a number of 

Bug#996839: [PATCH v2] perf script flamegraph: Avoid d3-flame-graph package dependency

2023-01-12 Thread Ian Rogers
Currently flame graph generation requires a d3-flame-graph template to
be installed. Unfortunately this is hard to come by for things like
Debian [1]. If the template isn't installed then ask if it should be
downloaded from jsdelivr CDN. The downloaded HTML file is validated
against an md5sum. If the download fails, generate a minimal flame
graph with the javascript coming from links to jsdelivr CDN.

v2. Change the warning to a prompt about downloading and add the
--allow-download command line flag. Add an md5sum check for the
downloaded HTML.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996839

Signed-off-by: Ian Rogers 
---
 tools/perf/scripts/python/flamegraph.py | 96 +++--
 1 file changed, 74 insertions(+), 22 deletions(-)

diff --git a/tools/perf/scripts/python/flamegraph.py 
b/tools/perf/scripts/python/flamegraph.py
index b6af1dd5f816..086619053e4e 100755
--- a/tools/perf/scripts/python/flamegraph.py
+++ b/tools/perf/scripts/python/flamegraph.py
@@ -19,12 +19,34 @@
 # pylint: disable=missing-function-docstring
 
 from __future__ import print_function
-import sys
-import os
-import io
 import argparse
+import hashlib
+import io
 import json
+import os
 import subprocess
+import sys
+import urllib.request
+
+minimal_html = """
+  https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.css;>
+
+
+  
+  https://d3js.org/d3.v7.js";>
+  https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/d3-flamegraph.min.js";>
+  
+  const stacks = [/** @flamegraph_json **/];
+  // Note, options is unused.
+  const options = [/** @options_json **/];
+
+  var chart = flamegraph();
+  d3.select("#chart")
+.datum(stacks[0])
+.call(chart);
+  
+
+"""
 
 # pylint: disable=too-few-public-methods
 class Node:
@@ -50,16 +72,6 @@ class FlameGraphCLI:
 self.args = args
 self.stack = Node("all", "root")
 
-if self.args.format == "html" and \
-not os.path.isfile(self.args.template):
-print("Flame Graph template {} does not exist. Please install "
-  "the js-d3-flame-graph (RPM) or libjs-d3-flame-graph (deb) "
-  "package, specify an existing flame graph template "
-  "(--template PATH) or another output format "
-  "(--format FORMAT).".format(self.args.template),
-  file=sys.stderr)
-sys.exit(1)
-
 @staticmethod
 def get_libtype_from_dso(dso):
 """
@@ -128,16 +140,52 @@ class FlameGraphCLI:
 }
 options_json = json.dumps(options)
 
+template_md5sum = None
+if self.args.format == "html":
+if os.path.isfile(self.args.template):
+template = f"file://{self.args.template}"
+else:
+if not self.args.allow_download:
+print(f"""Warning: Flame Graph template 
'{self.args.template}'
+does not exist. To avoid this please install a package such as the
+js-d3-flame-graph or libjs-d3-flame-graph, specify an existing flame
+graph template (--template PATH) or use another output format (--format
+FORMAT).""",
+  file=sys.stderr)
+s = None
+while s != "y" and s != "n":
+s = input("Do you wish to download a template from 
cdn.jsdelivr.net? (this warning can be suppressed with --allow-download) [yn] 
").lower()
+if s == "n":
+quit()
+template = 
"https://cdn.jsdelivr.net/npm/d3-flame-graph@4.1.3/dist/templates/d3-flamegraph-base.html;
+template_md5sum = "143e0d06ba69b8370b9848dcd6ae3f36"
+
 try:
-with io.open(self.args.template, encoding="utf-8") as template:
-output_str = (
-template.read()
-.replace("/** @options_json **/", options_json)
-.replace("/** @flamegraph_json **/", stacks_json)
-)
-except IOError as err:
-print("Error reading template file: {}".format(err), 
file=sys.stderr)
-sys.exit(1)
+with urllib.request.urlopen(template) as template:
+output_str = "".join([
+l.decode("utf-8") for l in template.readlines()
+])
+except Exception as err:
+print(f"Error reading template {template}: {err}\n"
+  "a minimal flame graph will be generated", 
file=sys.stderr)
+output_str = minimal_html
+template_md5sum = None
+
+if template_md5sum:
+download_md5sum = 
hashlib.md5(output_str.encode("utf-8")).hexdigest()
+if download_md5sum != template_md5sum:
+s = None
+   

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

2023-01-12 Thread Julian Groß
My computer just froze on Kernel version 5.19.11-1. Though nothing got 
logged.
Now I don't know if this is the same issue and newer kernels just behave 
better in terms of logging, or if this is a different issue..


I guess I will add a second screen to my computer, open journalctl on 
there, and point a camera at it to capture the issue.


I am pretty sure that I have had it not log on a 6.0 Kernel as well, but 
since I have been troubleshooting this for weeks now I am not completely 
sure.


OpenPGP_0xAF605C87F9E5AE94.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1028538: linux-source: linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc fails at docs

2023-01-12 Thread vmxevilstar
pip install -U Sphinx
Requirement already satisfied: Sphinx in
/usr/local/lib/python3.11/dist-packages (6.1.3)
Requirement already satisfied: Pygments>=2.13 in /usr/lib/python3/dist-
packages (from Sphinx) (2.14.0)
Requirement already satisfied: packaging>=21.0 in
/usr/lib/python3/dist-packages (from Sphinx) (22.0)
Requirement already satisfied: sphinxcontrib-applehelp in
/usr/lib/python3/dist-packages (from Sphinx) (1.0.2.dev0)
Requirement already satisfied: requests>=2.25.0 in
/usr/lib/python3/dist-packages (from Sphinx) (2.28.1)
Requirement already satisfied: docutils<0.20,>=0.18 in
/usr/lib/python3/dist-packages (from Sphinx) (0.19)
Requirement already satisfied: snowballstemmer>=2.0 in
/usr/lib/python3/dist-packages (from Sphinx) (2.2.0)
Requirement already satisfied: alabaster<0.8,>=0.7 in
/usr/lib/python3/dist-packages (from Sphinx) (0.7.12)
Requirement already satisfied: babel>=2.9 in /usr/lib/python3/dist-
packages (from Sphinx) (2.10.3)
Requirement already satisfied: sphinxcontrib-htmlhelp>=2.0.0 in
/usr/local/lib/python3.11/dist-packages (from Sphinx) (2.0.0)
Requirement already satisfied: imagesize>=1.3 in /usr/lib/python3/dist-
packages (from Sphinx) (1.4.1)
Requirement already satisfied: sphinxcontrib-serializinghtml>=1.1.5 in
/usr/lib/python3/dist-packages (from Sphinx) (1.1.5)
Requirement already satisfied: sphinxcontrib-devhelp in
/usr/lib/python3/dist-packages (from Sphinx) (1.0.2)
Requirement already satisfied: sphinxcontrib-qthelp in
/usr/lib/python3/dist-packages (from Sphinx) (1.0.3)
Requirement already satisfied: Jinja2>=3.0 in /usr/lib/python3/dist-
packages (from Sphinx) (3.0.3)
Requirement already satisfied: sphinxcontrib-jsmath in
/usr/lib/python3/dist-packages (from Sphinx) (1.0.1.dev0)



Bug#1028538: linux-source: linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc fails at docs

2023-01-12 Thread vmxevilstar
tried  pip3 install -U sphinx
Requirement already satisfied: sphinx in
/usr/local/lib/python3.11/dist-packages (1.4.1)
Collecting sphinx
Downloading sphinx-6.1.3-py3-none-any.whl (3.0 MB)
 3.0/3.0 MB 9.6 MB/s eta
0:00:00
Requirement already satisfied: Jinja2>=3.0 in /usr/lib/python3/dist-
packages (from sphinx) (3.0.3)
Requirement already satisfied: alabaster<0.8,>=0.7 in
/usr/lib/python3/dist-packages (from sphinx) (0.7.12)
Requirement already satisfied: packaging>=21.0 in
/usr/lib/python3/dist-packages (from sphinx) (22.0)
Requirement already satisfied: sphinxcontrib-jsmath in
/usr/lib/python3/dist-packages (from sphinx) (1.0.1.dev0)
Requirement already satisfied: requests>=2.25.0 in
/usr/lib/python3/dist-packages (from sphinx) (2.28.1)
Requirement already satisfied: sphinxcontrib-serializinghtml>=1.1.5 in
/usr/lib/python3/dist-packages (from sphinx) (1.1.5)
Requirement already satisfied: imagesize>=1.3 in /usr/lib/python3/dist-
packages (from sphinx) (1.4.1)
Requirement already satisfied: sphinxcontrib-qthelp in
/usr/lib/python3/dist-packages (from sphinx) (1.0.3)
Requirement already satisfied: sphinxcontrib-devhelp in
/usr/lib/python3/dist-packages (from sphinx) (1.0.2)
Requirement already satisfied: snowballstemmer>=2.0 in
/usr/lib/python3/dist-packages (from sphinx) (2.2.0)
Collecting sphinxcontrib-htmlhelp>=2.0.0
Downloading sphinxcontrib_htmlhelp-2.0.0-py2.py3-none-any.whl (100 kB)
 100.5/100.5 kB 9.4 MB/s eta
0:00:00
Requirement already satisfied: Pygments>=2.13 in /usr/lib/python3/dist-
packages (from sphinx) (2.14.0)
Requirement already satisfied: docutils<0.20,>=0.18 in
/usr/lib/python3/dist-packages (from sphinx) (0.19)
Requirement already satisfied: babel>=2.9 in /usr/lib/python3/dist-
packages (from sphinx) (2.10.3)
Requirement already satisfied: sphinxcontrib-applehelp in
/usr/lib/python3/dist-packages (from sphinx) (1.0.2.dev0)
Installing collected packages: sphinxcontrib-htmlhelp, sphinx
Attempting uninstall: sphinxcontrib-htmlhelp
Found existing installation: sphinxcontrib-htmlhelp 1.0.4.dev0
Not uninstalling sphinxcontrib-htmlhelp at /usr/lib/python3/dist-
packages, outside environment /usr
Can't uninstall 'sphinxcontrib-htmlhelp'. No files were found to
uninstall.
Attempting uninstall: sphinx
Found existing installation: Sphinx 1.4.1
Uninstalling Sphinx-1.4.1:
Successfully uninstalled Sphinx-1.4.1
Successfully installed sphinx-6.1.3 sphinxcontrib-htmlhelp-2.0.0
WARNING: Running pip as the 'root' user can result in broken
permissions and conflicting behaviour with the system package manager.
It is recommended to use a virtual environment instead:
https://pip.pypa.io/warnings/venv


now I get

root@ghost:/usr/src/kernel/linux-6.1.5/debian/build/build-doc# sphinx-
build --version
sphinx-build 6.1.3



but still 

linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc
dpkg-buildpackage: info: source package linux
dpkg-buildpackage: info: source version 6.1.5-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Renato Gallo

dpkg-buildpackage: info: host architecture amd64
dpkg-source --before-build .
dpkg-source: info: using options from linux-6.1.5/debian/source/local-
options: --abort-on-upstream-changes
debian/rules clean
md5sum --check debian/control.md5sum --status || \
/usr/bin/make -f debian/rules debian/control-real
dh_testdir
rm -rf debian/build debian/stamps debian/lib/python/debian_linux/*.pyc
debian/lib/python/debian_linux/__pycache__ $(find debian -maxdepth 1 -
type d -name 'linux-*') debian/*-modules-*-di* debian/kernel-image-*-
di* debian/*-tmp debian/*.substvars
dh_clean
dpkg-source -b .
dpkg-source: info: using options from linux-6.1.5/debian/source/local-
options: --abort-on-upstream-changes
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: warning: upstream signing key but no upstream tarball
signature
dpkg-source: info: building linux using existing
./linux_6.1.5.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building linux in linux_6.1.5-1.debian.tar.xz
dpkg-source: info: building linux in linux_6.1.5-1.dsc
debian/rules binary
mkdir -p debian/build
printf >debian/build/version-info 'Source: %s\nVersion: %s\n' linux
6.1.5-1
md5sum --check debian/control.md5sum --status || \
/usr/bin/make -f debian/rules debian/control-real
dh_testdir
/usr/bin/make -f debian/rules.gen build-indep
make[1]: Entering directory '/usr/src/kernel/linux-6.1.5'
/usr/bin/make -f debian/rules.real build_headers-common ABINAME='6.1.0-
0' ALL_KERNEL_ARCHES='alpha arm arm64 ia64 m68k mips parisc powerpc
riscv s390 sh sparc x86' DESTDIR='/usr/src/kernel/linux-
6.1.5/debian/linux-headers-6.1.0-0-common' DH_OPTIONS='-plinux-headers-
6.1.0-0-common' FEATURESET='none' LOCALVERSION='' PACKAGE_NAME='linux-
headers-6.1.0-0-common' SOURCEVERSION='6.1.5-1' SOURCE_BASENAME='linux'
SOURCE_SUFFIX='' UPSTREAMVERSION='6.1' 

Bug#1028538: linux-source: linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc fails at docs

2023-01-12 Thread vmxevilstar
sphinx-build --version
Traceback (most recent call last):
File "/usr/local/bin/sphinx-build", line 8, in 
sys.exit(main())
^^
File "/usr/local/lib/python3.11/dist-packages/sphinx/__init__.py", line
51, in main
sys.exit(build_main(argv))

File "/usr/local/lib/python3.11/dist-packages/sphinx/__init__.py", line
61, in build_main
from sphinx import cmdline
File "/usr/local/lib/python3.11/dist-packages/sphinx/cmdline.py", line
23, in 
from sphinx.application import Sphinx
File "/usr/local/lib/python3.11/dist-packages/sphinx/application.py",
line 35, in 
from sphinx.domains import ObjType, BUILTIN_DOMAINS
File "/usr/local/lib/python3.11/dist-
packages/sphinx/domains/__init__.py", line 279, in 
from sphinx.domains.cpp import CPPDomain # noqa

File "/usr/local/lib/python3.11/dist-packages/sphinx/domains/cpp.py",
line 263, in 
_whitespace_re = re.compile(r'\s+(?u)')
^^
File "/usr/lib/python3.11/re/__init__.py", line 227, in compile
return _compile(pattern, flags)

File "/usr/lib/python3.11/re/__init__.py", line 294, in _compile
p = _compiler.compile(pattern, flags)
^
File "/usr/lib/python3.11/re/_compiler.py", line 743, in compile
p = _parser.parse(p, flags)
^^^
File "/usr/lib/python3.11/re/_parser.py", line 980, in parse
p = _parse_sub(source, state, flags & SRE_FLAG_VERBOSE, 0)
^^
File "/usr/lib/python3.11/re/_parser.py", line 455, in _parse_sub
itemsappend(_parse(source, state, verbose, nested + 1,
^^
File "/usr/lib/python3.11/re/_parser.py", line 841, in _parse
raise source.error('global flags not at the start '
re.error: global flags not at the start of the expression at position 3



Bug#1028538: linux-source: linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc fails at docs

2023-01-12 Thread vmxevilstar
scripts/sphinx-pre-install  seems to fail here

sub get_sphinx_version($)
{
my $cmd = shift;
my $ver;

open IN, "$cmd --version 2>&1 |";
while () {
if (m/^\s*sphinx-build\s+([\d\.]+)((\+\/[\da-f]+)|(b\d+))?$/) {
$ver=$1;
last;
}
# Sphinx 1.2.x uses a different format
if (m/^\s*Sphinx.*\s+([\d\.]+)$/) {
$ver=$1;
last;
}
}
close IN;
return $ver;
}

sub check_sphinx()
{
my $default_version;

open IN, $conf or die "Can't open $conf";
while () {
if (m/^\s*needs_sphinx\s*=\s*[\'\"]([\d\.]+)[\'\"]/) {
$min_version=$1;
last;
}
}
close IN;

die "Can't get needs_sphinx version from $conf" if (!$min_version);

open IN, $requirement_file or die "Can't open $requirement_file";
while () {
if (m/^\s*Sphinx\s*==\s*([\d\.]+)$/) {
$default_version=$1;
last;
}
}
close IN;

die "Can't get default sphinx version from $requirement_file" if
(!$default_version);

$virtenv_dir = $virtenv_prefix . $default_version;

my $sphinx = get_sphinx_fname();
if ($sphinx eq "") {
$need_sphinx = 1;
return;
}

$cur_version = get_sphinx_version($sphinx);
die ("$sphinx returned an error") if (!$cur_version);




On Thu, 2023-01-12 at 15:06 +0100, xevilstar wrote:
> Package: linux-source
> Version: 6.1.5-1
> Severity: important
> X-Debbugs-Cc: vmxevils...@gmail.com
> 
> Dear Maintainer,
> 
> kernel version 6.1.5
> I have downloaded the new stable kernel version and I wanted to
> contribute trying at my best 
> to upload it to mentors
> I have cloned the git version of the debian/ files and put it inside
> the kernel source directory
> from inside the kernel source directory
> I have added the new version in debian/changelog then 
> I have run the debian/bin/genorig.py
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>  then
> I have run debian/rules orig
> no errors, but then 
> 
> dpkg-buildpackage -j`nproc` -us -uc
> dpkg-buildpackage: info: source package linux
> dpkg-buildpackage: info: source version 6.1.5-1
> dpkg-buildpackage: info: source distribution UNRELEASED
> dpkg-buildpackage: info: source changed by Renato Gallo
> 
> dpkg-buildpackage: info: host architecture amd64
>  dpkg-source --before-build .
> dpkg-source: info: using options from linux-
> 6.1.5/debian/source/local-options: --abort-on-upstream-changes
>  debian/rules clean
> md5sum --check debian/control.md5sum --status || \
> /usr/bin/make -f debian/rules debian/control-real
> dh_testdir
> rm -rf debian/build debian/stamps
> debian/lib/python/debian_linux/*.pyc
> debian/lib/python/debian_linux/__pycache__ $(find debian -maxdepth 1
> -type d -name 'linux-*') debian/*-modules-*-di* debian/kernel-image-
> *-di* debian/*-tmp debian/*.substvars
> dh_clean
>  dpkg-source -b .
> dpkg-source: info: using options from linux-
> 6.1.5/debian/source/local-options: --abort-on-upstream-changes
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: warning: upstream signing key but no upstream tarball
> signature
> dpkg-source: info: building linux using existing
> ./linux_6.1.5.orig.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: building linux in linux_6.1.5-1.debian.tar.xz
> dpkg-source: info: building linux in linux_6.1.5-1.dsc
>  debian/rules binary
> mkdir -p debian/build
> printf >debian/build/version-info 'Source: %s\nVersion: %s\n' linux
> 6.1.5-1
> md5sum --check debian/control.md5sum --status || \
> /usr/bin/make -f debian/rules debian/control-real
> dh_testdir
> /usr/bin/make -f debian/rules.gen build-indep
> make[1]: Entering directory '/usr/src/kernel/linux-6.1.5'
> /usr/bin/make -f debian/rules.real build_headers-common
> ABINAME='6.1.0-0' ALL_KERNEL_ARCHES='alpha arm arm64 ia64 m68k mips
> parisc powerpc riscv s390 sh sparc x86'
> DESTDIR='/usr/src/kernel/linux-6.1.5/debian/linux-headers-6.1.0-0-
> common' DH_OPTIONS='-plinux-headers-6.1.0-0-common' FEATURESET='none'
> LOCALVERSION='' PACKAGE_NAME='linux-headers-6.1.0-0-common'
> SOURCEVERSION='6.1.5-1' SOURCE_BASENAME='linux' SOURCE_SUFFIX=''
> UPSTREAMVERSION='6.1' VERSION='6.1'
> make[2]: Entering directory '/usr/src/kernel/linux-6.1.5'
> make[2]: Nothing to be done for 'build_headers-common'.
> make[2]: Leaving directory '/usr/src/kernel/linux-6.1.5'
> /usr/bin/make -f debian/rules.real build_doc ABINAME='6.1.0-0'
> DESTDIR='/usr/src/kernel/linux-6.1.5/debian/linux-doc-6.1'
> DH_OPTIONS='-plinux-doc-6.1' PACKAGE_NAME='linux-doc-6.1'
> SOURCEVERSION='6.1.5-1' SOURCE_BASENAME='linux' SOURCE_SUFFIX=''
> UPSTREAMVERSION='6.1' VERSION='6.1'
> make[2]: Entering directory '/usr/src/kernel/linux-6.1.5'
> test -d .pc
> set +e; QUILT_PC=.pc quilt unapplied --quiltrc - >/dev/null && echo
> 'Patch series not fully applied'; test $? -eq 1
> File series fully applied, ends at patch 6.1.5.patch
> mkdir -p 'debian/build'
> rm -rf 'debian/build/build-doc'
> mkdir -p 'debian/build/build-doc'
> cp -al COPYING CREDITS Documentation Kbuild Kconfig LICENSES
> MAINTAINERS Makefile README arch block certs crypto drivers fs
> include init 

Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

2023-01-12 Thread Julian
On Thu, 12 Jan 2023 15:41:03 +0100 Diederik de Haas  
wrote:
> "Currently, I am using git bisect to narrow down the window of possible
> commits, but since the issue appears seemingly random, it will take many
> months to identify the offending commit this way."
>
> Why? It *could* be that the maintainers will wait for the result of the
> `git bisect` before responding/acting upon it.

My intention has been to continue with the git bisect.
However, I have already encountered two revisions that do not build, so I doubt 
I can get very far there.

I will wait till next week and then report whatever additional information I 
was able to get through git bisect to the Kernel maintainers. Then I will most 
likely also tell them that I will not continue with git bisect unless they have 
a smaller window of revisions for me to try.


Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

2023-01-12 Thread Diederik de Haas
Hi Julian,

On Thursday, 12 January 2023 12:11:57 CET Julian wrote:
> The message to linux-nvme finally came through and the thread is here:
> http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

The following paragraph may not be ideally formulated:

"Currently, I am using git bisect to narrow down the window of possible 
commits, but since the issue appears seemingly random, it will take many 
months to identify the offending commit this way."

Why? It *could* be that the maintainers will wait for the result of the
`git bisect` before responding/acting upon it.

Hopefully I'm wrong, but if they don't respond in a 'reasonable' time frame, 
you may want to clarify that you actually don't want to do the `git bisect` 
exactly because it could take many months.

Cheers,
  Diederik

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


Bug#1028538: linux-source: linux-6.1.5# dpkg-buildpackage -j`nproc` -us -uc fails at docs

2023-01-12 Thread xevilstar
Package: linux-source
Version: 6.1.5-1
Severity: important
X-Debbugs-Cc: vmxevils...@gmail.com

Dear Maintainer,

kernel version 6.1.5
I have downloaded the new stable kernel version and I wanted to contribute 
trying at my best 
to upload it to mentors
I have cloned the git version of the debian/ files and put it inside the kernel 
source directory
from inside the kernel source directory
I have added the new version in debian/changelog then 
I have run the debian/bin/genorig.py 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git then
I have run debian/rules orig
no errors, but then 

dpkg-buildpackage -j`nproc` -us -uc
dpkg-buildpackage: info: source package linux
dpkg-buildpackage: info: source version 6.1.5-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Renato Gallo 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-source: info: using options from linux-6.1.5/debian/source/local-options: 
--abort-on-upstream-changes
 debian/rules clean
md5sum --check debian/control.md5sum --status || \
/usr/bin/make -f debian/rules debian/control-real
dh_testdir
rm -rf debian/build debian/stamps debian/lib/python/debian_linux/*.pyc 
debian/lib/python/debian_linux/__pycache__ $(find debian -maxdepth 1 -type d 
-name 'linux-*') debian/*-modules-*-di* debian/kernel-image-*-di* debian/*-tmp 
debian/*.substvars
dh_clean
 dpkg-source -b .
dpkg-source: info: using options from linux-6.1.5/debian/source/local-options: 
--abort-on-upstream-changes
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: warning: upstream signing key but no upstream tarball signature
dpkg-source: info: building linux using existing ./linux_6.1.5.orig.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building linux in linux_6.1.5-1.debian.tar.xz
dpkg-source: info: building linux in linux_6.1.5-1.dsc
 debian/rules binary
mkdir -p debian/build
printf >debian/build/version-info 'Source: %s\nVersion: %s\n' linux 6.1.5-1
md5sum --check debian/control.md5sum --status || \
/usr/bin/make -f debian/rules debian/control-real
dh_testdir
/usr/bin/make -f debian/rules.gen build-indep
make[1]: Entering directory '/usr/src/kernel/linux-6.1.5'
/usr/bin/make -f debian/rules.real build_headers-common ABINAME='6.1.0-0' 
ALL_KERNEL_ARCHES='alpha arm arm64 ia64 m68k mips parisc powerpc riscv s390 sh 
sparc x86' 
DESTDIR='/usr/src/kernel/linux-6.1.5/debian/linux-headers-6.1.0-0-common' 
DH_OPTIONS='-plinux-headers-6.1.0-0-common' FEATURESET='none' LOCALVERSION='' 
PACKAGE_NAME='linux-headers-6.1.0-0-common' SOURCEVERSION='6.1.5-1' 
SOURCE_BASENAME='linux' SOURCE_SUFFIX='' UPSTREAMVERSION='6.1' VERSION='6.1'
make[2]: Entering directory '/usr/src/kernel/linux-6.1.5'
make[2]: Nothing to be done for 'build_headers-common'.
make[2]: Leaving directory '/usr/src/kernel/linux-6.1.5'
/usr/bin/make -f debian/rules.real build_doc ABINAME='6.1.0-0' 
DESTDIR='/usr/src/kernel/linux-6.1.5/debian/linux-doc-6.1' 
DH_OPTIONS='-plinux-doc-6.1' PACKAGE_NAME='linux-doc-6.1' 
SOURCEVERSION='6.1.5-1' SOURCE_BASENAME='linux' SOURCE_SUFFIX='' 
UPSTREAMVERSION='6.1' VERSION='6.1'
make[2]: Entering directory '/usr/src/kernel/linux-6.1.5'
test -d .pc
set +e; QUILT_PC=.pc quilt unapplied --quiltrc - >/dev/null && echo 'Patch 
series not fully applied'; test $? -eq 1
File series fully applied, ends at patch 6.1.5.patch
mkdir -p 'debian/build'
rm -rf 'debian/build/build-doc'
mkdir -p 'debian/build/build-doc'
cp -al COPYING CREDITS Documentation Kbuild Kconfig LICENSES MAINTAINERS 
Makefile README arch block certs crypto drivers fs include init io_uring ipc 
kernel lib mm net rust samples scripts security sound tools usr virt 
.clang-format .cocciconfig .get_maintainer.ignore .gitattributes .gitignore 
.mailmap .rustfmt.toml 'debian/build/build-doc'
env -u ABINAME -u ARCH -u FEATURESET -u FLAVOUR -u VERSION -u LOCALVERSION 
DISTRIBUTION_OFFICIAL_BUILD=1 DISTRIBUTOR="Debian" 
DISTRIBUTION_VERSION="6.1.5-1" KBUILD_BUILD_TIMESTAMP="Thu, 12 Jan 2023 
14:15:31 +0100" KBUILD_BUILD_VERSION_TIMESTAMP="Debian 6.1.5-1 (2023-01-12)" 
KBUILD_BUILD_USER="debian-kernel" KBUILD_BUILD_HOST="lists.debian.org" 
KBUILD_VERBOSE=1 /usr/bin/make 
KCFLAGS=-fdebug-prefix-map=/usr/src/kernel/linux-6.1.5/= KBUILD_HOSTCFLAGS='-g 
-O2 -ffile-prefix-map=/usr/src/kernel/linux-6.1.5=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
HOSTCFLAGS='-g -O2 -ffile-prefix-map=/usr/src/kernel/linux-6.1.5=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' KBUILD_HOSTLDFLAGS='-Wl,-z,relro' -C 
'debian/build/build-doc' PYTHON=python3 xmldocs
make[3]: Entering directory '/usr/src/kernel/linux-6.1.5/debian/build/build-doc'
/usr/bin/make -f ./scripts/Makefile.build obj=Documentation xmldocs
sphinx-build returned an error at ./scripts/sphinx-pre-install line 317.
make[4]: *** 

Bug#1028451: 2nd DisplayPort doesn't get video

2023-01-12 Thread Diederik de Haas
On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote:
> Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked
> upstream here:
>   https://gitlab.freedesktop.org/drm/amd/-/issues/2171

Thanks! About an hour ago the suggested fix was to revert commit
4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
describes a procedure to build a kernel with the proposed patch (attached).

OdyX: Can you try to see whether that resolves the issue?diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 77277d90b6e2..674f5dc1102b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 	const struct drm_display_mode *adjusted_mode = _state->adjusted_mode;
 	struct drm_dp_mst_topology_mgr *mst_mgr;
 	struct drm_dp_mst_port *mst_port;
-	struct drm_dp_mst_topology_state *mst_state;
 	enum dc_color_depth color_depth;
 	int clock, bpp = 0;
 	bool is_y420 = false;
@@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 	if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
 		return 0;
 
-	mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
-	if (IS_ERR(mst_state))
-		return PTR_ERR(mst_state);
-
-	if (!mst_state->pbn_div)
-		mst_state->pbn_div = dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
-
 	if (!state->duplicated) {
 		int max_bpc = conn_state->max_requested_bpc;
 		is_y420 = drm_mode_is_420_also(>display_info, adjusted_mode) &&
@@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
 		clock = adjusted_mode->clock;
 		dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, false);
 	}
-
-	dm_new_connector_state->vcpi_slots =
-		drm_dp_atomic_find_time_slots(state, mst_mgr, mst_port,
-	  dm_new_connector_state->pbn);
+	dm_new_connector_state->vcpi_slots = drm_dp_atomic_find_time_slots(state,
+	   mst_mgr,
+	   mst_port,
+	   dm_new_connector_state->pbn,
+	   dm_mst_get_pbn_divider(aconnector->dc_link));
 	if (dm_new_connector_state->vcpi_slots < 0) {
 		DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n", (int)dm_new_connector_state->vcpi_slots);
 		return dm_new_connector_state->vcpi_slots;
@@ -6654,14 +6647,17 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct drm_atomic_state *state,
 			dm_conn_state->vcpi_slots = slot_num;
 
 			ret = drm_dp_mst_atomic_enable_dsc(state, aconnector->port,
-			   dm_conn_state->pbn, false);
+			   dm_conn_state->pbn, 0, false);
 			if (ret < 0)
 return ret;
 
 			continue;
 		}
 
-		vcpi = drm_dp_mst_atomic_enable_dsc(state, aconnector->port, pbn, true);
+		vcpi = drm_dp_mst_atomic_enable_dsc(state,
+		aconnector->port,
+		pbn, pbn_div,
+		true);
 		if (vcpi < 0)
 			return vcpi;
 
@@ -9497,6 +9493,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 	struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state;
 #if defined(CONFIG_DRM_AMD_DC_DCN)
 	struct dsc_mst_fairness_vars vars[MAX_PIPES];
+	struct drm_dp_mst_topology_state *mst_state;
+	struct drm_dp_mst_topology_mgr *mgr;
 #endif
 
 	trace_amdgpu_dm_atomic_check_begin(state);
@@ -9744,6 +9742,33 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
 		lock_and_validation_needed = true;
 	}
 
+#if defined(CONFIG_DRM_AMD_DC_DCN)
+	/* set the slot info for each mst_state based on the link encoding format */
+	for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
+		struct amdgpu_dm_connector *aconnector;
+		struct drm_connector *connector;
+		struct drm_connector_list_iter iter;
+		u8 link_coding_cap;
+
+		if (!mgr->mst_state )
+			continue;
+
+		drm_connector_list_iter_begin(dev, );
+		drm_for_each_connector_iter(connector, ) {
+			int id = connector->index;
+
+			if (id == mst_state->mgr->conn_base_id) {
+aconnector = to_amdgpu_dm_connector(connector);
+link_coding_cap = dc_link_dp_mst_decide_link_encoding_format(aconnector->dc_link);
+drm_dp_mst_update_slots(mst_state, link_coding_cap);
+
+break;
+			}
+		}
+		drm_connector_list_iter_end();
+
+	}
+#endif
 	/**
 	 * Streams and planes are reset when there are changes that affect
 	 * bandwidth. Anything that affects bandwidth needs to go through
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 6994c9a1ed85..ac5a8cad0695 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
@@ -120,27 +119,40 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
 }
 
 static void

Processed: Re: Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

2023-01-12 Thread Debian Bug Tracking System
Processing control commands:

> forwarded -1 
> http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html
Bug #1028309 [src:linux] linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: 
System partially freezes with "nvme controller is down"
Set Bug forwarded-to-address to 
'http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html'.

-- 
1028309: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028309
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

2023-01-12 Thread Diederik de Haas
Control: forwarded -1 
http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

On Thursday, 12 January 2023 12:11:57 CET Julian wrote:
> The message to linux-nvme finally came through and the thread is here:
> http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

Thanks!

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


Bug#1024149: linux-image-amd64: 32-bit mmap() puts large files at non-random address

2023-01-12 Thread Jakub Wilk

* Salvatore Bonaccorso , 2022-11-19 11:11:
Given you were able to tackle the issue further, can you report the 
issue to upstream


Don't count on me. Sorry!

--
Jakub Wilk



Bug#1028451: 2nd DisplayPort doesn't get video

2023-01-12 Thread Sjoerd Simons
Source: linux
Followup-For: Bug #1028451

Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked 
upstream
here:
  https://gitlab.freedesktop.org/drm/amd/-/issues/2171

As the original report was about a second displayport on a docking station I
would guess it's the same issue. For reference i'm hit by the same issue due to
using MST for daisy-chaining monitors.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, arm64

Kernel: Linux 6.0.0-6-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#1028309: linux-image-6.0.0-6-amd64: Regression in Kernel 6.0: System partially freezes with "nvme controller is down"

2023-01-12 Thread Julian
On Wed, 11 Jan 2023 21:49:45 +0100 Diederik de Haas  
wrote:
> So the next thing to do, is present the issue to the relevant upstream
> maintainers. Searching for "nvme controller is down" brought up another bug
> (but that happened pretty instantly) and in there the request was made to
> report the issue (via email) to the linux-...@vger.kernel.org and
> linux-n...@lists.infradead.org lists.
> And that seems like the next best step for you too.

The message to linux-nvme finally came through and the thread is here: 
http://lists.infradead.org/pipermail/linux-nvme/2023-January/037384.html

For linux-pci, I am not sure if it worked.
I got a "Delivery status OK" and a "BOUNCE linux-...@vger.kernel.org: 
Message too long (>10 chars)".
Obviously my message isn't >10, so I assume they have a problem with one of 
the attachments.
But the message doesn't contain any information about if the mail got refused 
or not.
And more importantly, the "Delivery status OK" message, specifically says that 
the mail got delivered to the mailing lists address.