[PATCH 0/9] Clean up some old patches post F31
by Laura Abbott
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
3 years, 7 months
Kernel 5.3 rebase plans
by Laura Abbott
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
3 years, 8 months
Support buildid in kernel-headers
by Paul Moore
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 years, 8 months
packet writing support
by Mischa Baars
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.
3 years, 8 months
kernel testing important questions
by Mgr. Janusz Chmiel
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.
3 years, 8 months
kernel 5.3.0-0.rc7.git1.1 src.rpm fails at the patching stage, on
the first patch.
by stan
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
< }
<
"""
3 years, 8 months
Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy
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
3 years, 8 months