Re: Sphinx builds always write to the source directory
On Tue, 31 Jan 2017, Ben Hutchings wrote: > I'm having trouble with the Debian packaging of kernel documentation. > We try to build everything in a separate output directory (underneath > debian/build), but the new Sphinx-based build system writes to the > source directory. > > Firstly, Python creates bytecode files alongside the module sources. > This could be avoided by setting environment variable > PYTHONDONTWRITEBYTECODE=1, at the expense of requiring recompilation > more often. I've sent the patch a few times. http://lkml.kernel.org/r/1479916579-17151-1-git-send-email-jani.nik...@intel.com > Secondly, starting with 4.10, Documentation/media/Makefile converts > from dot to SVG and from SVG to PDF in the source directory. It seems > like it should be possible to put the converted files in the output > directory, but I don't know how to tell Sphinx to find them there. > > Are these issues likely to be fixed? > > Ben. -- Jani Nikula, Intel Open Source Technology Center
[PATCH RESEND] Documentation/sphinx: prevent generation of .pyc files in the source tree
Use PYTHONDONTWRITEBYTECODE=1 to prevent python from creating .pyc files in the source tree. Python 3.2 has a __pycache__ scheme [1], but before that the only alternative seems to be to copy the source files to the build tree to ensure the .pyc files are created there too. Just prevent .pyc file generation for simplicity. Considering the small amount of python code to compile (assuming sphinx itself has .pyc around), the impact on build is neglible. [1] http://stackoverflow.com/questions/3522079/changing-the-directory-where-pyc-files-are-created References: http://lkml.kernel.org/r/camuhmdvxqph7-9xj+ye_pgoa+-fe0969cskoehyh3uubycr...@mail.gmail.com Reported-by: Geert Uytterhoeven References: http://lkml.kernel.org/r/1485816692.2900.17.ca...@decadent.org.uk Reported-by: Ben Hutchings Cc: Jonathan Corbet Signed-off-by: Jani Nikula --- Documentation/Makefile.sphinx | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx index 707c65337ebf..91f541a52884 100644 --- a/Documentation/Makefile.sphinx +++ b/Documentation/Makefile.sphinx @@ -55,6 +55,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1)) quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media $2;\ + PYTHONDONTWRITEBYTECODE=1 \ BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \ $(SPHINXBUILD) \ -b $2 \ -- 2.1.4
Re: [PATCH RESEND] Documentation/sphinx: prevent generation of .pyc files in the source tree
On Wed, 01 Feb 2017, Jonathan Corbet wrote: > On Tue, 31 Jan 2017 20:18:05 +0200 > Jani Nikula wrote: > >> Considering the small amount of python code to compile (assuming sphinx >> itself has .pyc around), the impact on build is neglible. > > Hey...don't you know that performance-impacting patches need benchmarks? Heh, I was briefly worried at this point! :) > > Sphinx-only htmldocs build before: > > real2m26.063s > user2m19.184s > sys 0m5.429s > > After: > > real2m26.342s > user2m20.445s > sys 0m5.611s > > You owe me 0.279 seconds :) > > (Applied, thanks). > > jon -- Jani Nikula, Intel Open Source Technology Center
Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
On Mon, 15 Jul 2024, Francesco Poli wrote: > Hi all, > on a laptop where I installed Debian testing some 6 months ago, > I noticed that the logs are continuously flooded with call traces > like the attached snippet (taken from /var/log/kern.log ). > > It seems to me that it also used to happen with previous versions > of the Linux kernel, but I am under the impression that, with Linux > kernel 6.9.7, it got worse. I have recently upgraded to Linux kernel > version 6.9.8 (provided by the distro, Debian testing, as I said), but > the bug is still reproducible: > > $ uname -srvmo > Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 > GNU/Linux > > I see at least 12 of these call traces just after boot, before even > starting X (with 'startx'). > More of these call traces are sent to the logs after starting X, or > after invoking 'xrandr', or after locking the X session (with > XScreenSaver), ... > I always see these call traces (I mean the bug is always reproducible: > each time I boot, each time I call xrandr, ...). > > They seem to correspond to no actual issue, as far as I can tell, > but they are flooding the logs with a significant flow of text... > which is worrying by itself. > > > What's wrong? > How can I stop this log-filling flood? > Should I black-list some module, for instance? > > > The outputs of > > # lspci -vnn -d :*:0300 > > and of > > # dmidecode > > are attached. > Also, I booted with kernel parameters > 'drm.debug=0xe log_buf_len=4M ignore_loglevel' and > logged in as root right after the boot. > The output of > > # dmesg > > is attached. > > Some additional information may be found on the [Debian bug] report I had > previously filed. > > [Debian bug]: <https://bugs.debian.org/1075770> > > > N.B.: > Please Cc me and the Debian bug address <1075...@bugs.debian.org> > on replies, so that the interested parties (including me!) are kept > in the loop. > Thanks a lot for your time and for any help you may provide! Please file i915 bugs at fdo gitlab as described at [1]. BR, Jani. [1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html -- Jani Nikula, Intel
Bug#1075770: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces
On Thu, 25 Jul 2024, Francesco Poli wrote: > I had reported the bug to the Debian BTS (Bug Tracking System), where > I was told to report the bug upstream, by contacting developers/mailing > lists. > Now on this mailing list, I am being told to report the issue on > gitlab.freedesktop.org (which requires to register an account, in order > to report issues)... Having to jump through all these hoops is beginning > to be a little time consuming... :-( There are a number of reasons why email and mailing lists are really bad for reporting bugs, from our perspective, which is why we've asked people to report bugs to freedesktop.org bug trackers for about a decade now. If the right person doesn't have time to resolve the issue right away, it'll likely be forgotten on the mailing list. Attachments aren't welcome on mailing lists, let alone big logs. It's easier to label and reference issues on a bug tracker. It's easier (yes, for us) to manage the issues, and the people working on them, on a bug tracker. And so on. BR, Jani. -- Jani Nikula, Intel
Bug#971068: Assertion failure in i915 intel_display.c#assert_plane() after resume from hibernation
On Tue, 24 Jan 2023, наб wrote: > Booted with both, hibernated, resumed; full dmesg below. Unfortunately, this is probably hitting a regression with drm debug logging, and we don't get proper debug logging for i915. :( Please use DRM_USE_DYNAMIC_DEBUG=n with v6.1. I don't know if the proper fixes have been backported to v6.1 stable kernels. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
