kernel September 2019

kernel@lists.fedoraproject.org

14 participants
14 discussions

[PATCH 0/9] Clean up some old patches post F31
by Laura Abbott 04 Nov '19

04 Nov '19

I'd like to drop a bunch of patches Fedora has been carrying since forever. Most of these are fairly minor tweaks most people forgot we had and nobody cares about. My motivation is both in the spirit of cleaning up and also to better align Fedora + RHEL (I had a talk about this at Flock, video should be up soon). If someone wants to make an effort at upstreaming any of these, feel free to do so but I really think most of these are cruft. Thanks, Laura Laura Abbott (9): Drop namespaces config tweak Drop cpumask auto select patch Drop scsi warning patch Remove ancient ath9k workaround Drop old lis3 patch Remove some old modalias adjustments Remove old keyboard logging patch Remove patch for GCC VTA Remove crash driver Kbuild-Add-an-option-to-enable-GCC-VTA.patch | 94 --- ath9k-rx-dma-stop-check.patch | 38 - .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- crash-driver.patch | 722 ------------------ die-floppy-die.patch | 29 - input-kill-stupid-messages.patch | 30 - kernel.spec | 20 - ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 - lis3-improve-handling-of-null-rate.patch | 75 -- namespaces-no-expert.patch | 27 - no-pcspkr-modalias.patch | 22 - ...validate_disk-prevent-NULL-ptr-deref.patch | 39 - 12 files changed, 1 insertion(+), 1131 deletions(-) delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch delete mode 100644 ath9k-rx-dma-stop-check.patch delete mode 100644 crash-driver.patch delete mode 100644 die-floppy-die.patch delete mode 100644 input-kill-stupid-messages.patch delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch delete mode 100644 lis3-improve-handling-of-null-rate.patch delete mode 100644 namespaces-no-expert.patch delete mode 100644 no-pcspkr-modalias.patch delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch -- 2.21.0

8 26

Kernel 5.3 rebase plans
by Laura Abbott 08 Oct '19

08 Oct '19

Hi, Kernel 5.3 was released upstream yesterday Sept 16. Fedora will be following the same rebase schedule as with past kernels. This means F30 will be rebased to 5.3 first followed by F29 shortly thereafter. We typically wait until the 2nd or 3rd stable release to push a rebase. Based on past timings, I'd expect this to happen around mid-October. You can find test builds in the kernel-stabilization COPR. Note that F31 will be shipping with 5.3 so you can always test those kernels too. Please also keep an eye out for the 5.3 test day which will happen before the rebase as well. Thanks, Laura

5 7

Support buildid in kernel-headers
by Paul Moore 06 Oct '19

06 Oct '19

Hello, Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel-header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed. I'm attaching a small patch which fixes this for my use case, and while I think it is a generic solution, I can't say I've spent enough time looking at it to say for certain. I'm putting it out here as a way to help describe the problem as well as one possible solution. If you have a different/better approach that's fine with me, I just want to see the buildid reflected in the kernel-header package build so I can drop this patch from my build process :) -- paul moore www.paul-moore.com

3 6

Fedora 31 Kernel 5.3 Test Week 2019-09-30 to 2019-10-07
by Sumantro Mukherjee 30 Sep '19

30 Sep '19

Hey All, I would like to invite all of you to participate in the Kernel 5.3 Test week which is happening from 2019-09-30 to 2019-10-07. It's fairly simple, head over to the wiki [0] and read in details about the test week and simply run the test case mentioned in[1] and enter your results. Do let me know if you have any questions [0] https://fedoraproject.org/wiki/Test_Day:2019-09-30_Kernel_5.3_Test_Week [1] http://testdays.fedorainfracloud.org/events/72 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>

1 0

packet writing support
by Mischa Baars 24 Sep '19

24 Sep '19

Hi, The email addresses taken from ./Documentation/cdrom/packet-writing.txt aren't responding and the kernel mailing list daemon at vger.kernel.org isn't accepting subscription. That is why I write to this mailing list. If I'm correct, packet writing support is going to be removed from the Linux kernel in the near future. Is there any particular reason for this, as far as you people know? Both DVD-writers and Blueray-writers are still being sold to date. I'm currently working on quite a large project. I would be dependent solely on USB to store my backup files, when the packet writing support is removed. Actually I'm quite uncomfortable with that idea, because USB is rewritable. Any serious attempt to do damage to my project will result a permanent loss of code. Personally I would do anything to keep packet writing support in the kernel. I'd hoped you could remove normal floppy disc support instead. That seems the more logical course of action. Floppy disc drives aren't being sold anymore for quite some years now. Anybody there? Have a pleasant day, Mischa Baars.

1 0

kernel testing important questions
by Mgr. Janusz Chmiel 21 Sep '19

21 Sep '19

Dear specialists, I have decided to test kernel by using instructions here: https://fedoraproject.org/wiki/QA:Testcase_kernel_regression Becauser I do not see at all. Should I prevent Orca screen reader from running during this test to prevent bad results? Sure. I do not move with focus, speech is disabled, but sure, ORCA monitor events at The background when it is active. I Am very glad, that kernel developers allow users to test The kernel. I Am very glad, that I can use The test and that I can even read its results. Thank you, that you did not decided to kill XORG, PUlseaudio sound server. Thanks to yours approach, I can participate. You can find test results in yours databases when you will try to locate januszchmiel name. I hope, that data have been sent to you. And do not be afraid. I will not intrude you. I know, that you are working very hard and that you have to deeply concentrate. If there is some web page which could I followe to participate even on more complicated kernel tests, I Am ready to colaborate.

1 0

[Test Day] Kernel 5.2 Test Week Report
by Sumantro Mukherjee 21 Sep '19

21 Sep '19

Hey All, In the last Kernel 5.2 Test Day we had about 65 Testers. The new Kernel was tested across mutiple arches and an old regression[0] was noted , the bug was reopened and now has been fixed. The wiki page holds the results https://fedoraproject.org/wiki/Test_Day:2019-07-22_Kernel_5.2_Test_Week Thanks to all who participated and a huge shout out to jforbes and the Kernel team for helping us out. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1724357 Thanks -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>

1 0

Btrfs: fix unwritten extent buffers and hangs
by Chris Murphy 16 Sep '19

16 Sep '19

I filed this to hopefully avoid anyone else getting hit by it. I haven't hit it in months running 5.2, so in that sense it's rare. But upstream has maybe 1/2 dozen reports of it, and that's unusually high. https://bugzilla.redhat.com/show_bug.cgi?id=1751901 Is that enough information to carry that patch before it ends up in a stable version from upstream? I checked https://src.fedoraproject.org/rpms/kernel/pull-requests but it doesn't look like you really want PR's there. -- Chris Murphy

2 2

kernel 5.3.0-0.rc7.git1.1 src.rpm fails at the patching stage, on the first patch.
by stan 10 Sep '19

10 Sep '19

Hi, I build a custom kernel with rpmbuild. The latest kernel, 5.3.0-0.rc7.git1.1, fails when it patches. I noticed that the last successful spec file had the lines shown below, while the latest doesn't. However, adding them back does not enable patches, the build still fails immediately when it tries to patch, on the first patch. """ Applying: lib/cpumask: Make CPUMASK_OFFSTACK usable without debug dependency Patch failed at 0001 lib/cpumask: Make CPUMASK_OFFSTACK usable without debug dependency When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". error: lib/Kconfig: does not exist in index hint: Use 'git am --show-current-patch' to see the failed patch """ If I comment out the first patch, the second patch fails with the same messages, except the directory missing from the index is the directory where the second patch applies. What has changed in the kernel build process, and how do I fix the spec file so it works? Gone from latest spec: """ < patch_command='patch -p1 -F1 -s' < ApplyPatch() < { < local patch=$1 < shift < if [ ! -f $RPM_SOURCE_DIR/$patch ]; then < exit 1 < fi < if ! grep -E "^Patch[0-9]+: $patch\$" %{_specdir}/${RPM_PACKAGE_NAME%%%%%{?variant}}.spec ; then < if [ "${patch:0:8}" != "patch-5." ] ; then < echo "ERROR: Patch $patch not listed as a source patch in specfile" < exit 1 < fi < fi 2>/dev/null < case "$patch" in < *.bz2) bunzip2 < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; < *.gz) gunzip < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; < *.xz) unxz < "$RPM_SOURCE_DIR/$patch" | $patch_command ${1+"$@"} ;; < *) $patch_command ${1+"$@"} < "$RPM_SOURCE_DIR/$patch" ;; < esac < } < < # don't apply patch if it's empty < ApplyOptionalPatch() < { < local patch=$1 < shift < if [ ! -f $RPM_SOURCE_DIR/$patch ]; then < exit 1 < fi < local C=$(wc -l $RPM_SOURCE_DIR/$patch | awk '{print $1}') < if [ "$C" -gt 9 ]; then < ApplyPatch $patch ${1+"$@"} < fi < } < """

2 4

Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy 10 Sep '19

10 Sep '19

The language being used by Anaconda team suggests the "Btrfs is not a priority" and should be unsupported, is a decision that has already happened. This discussion, in this thread, is about how to handle that decision in UI/Ux. When and where did this decision get made? How do outside contributors get the information they need to know their efforts are worthwhile? I have hundreds of hours invested in Anaconda testing, perhaps 1/2 not related to Btrfs, over ~8 years. I would like answers to these questions. -- Chris Murphy

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel September 2019