Like all good bits of software, the kernel.spec has grown over time.
Part of this growth has come from building more of the userspace
tools that live under the tools directory of the kernel. I've been
experimenting with moving these to a separate spec file.
- Less stuff in the kernel.spec file (~300 line deletion)
- Fewer build deps for things like perf
- People building the kernel only get the kernel
- Issues with userspace tools don't impact the kernel
- Can likely drop most of the debuginfo regex nightmare for the userspace packages
- Would need to manually keep in sync on some cadence. This is mostly
an issue for rawhide. Could we actually get away with only re-building
on each new kernel version or do we need to resync on each -rc?
- Would probably need to rework how tools are tied to kernel versions at
the package level
- Others added here
I've experimented with something at https://pagure.io/kernel-tools-pkggit
which is mostly a copy/paste of parts of the kernel.spec file. I'm
mostly looking for general feedback about if this a good idea but
I'm also interested in specific feedback if you have it.
I'm working on trying to improve the OOTB power-consumption
of Fedora Workstation on laptops.
One of the easy wins here is setting snd_hda_intel.power_save=1,
which saves about 0.4W which given that modern laptops idle at
around 6-8W is a significant saving.
I've asked the upstream kernel devs if there are any downsides
to setting SND_HDA_POWER_SAVE_DEFAULT=1 and I got a reply that
this should be fine and that OpenSUSE Tumbleweed is already
So unless there are any objections I would like to change this
option to 1 starting with 4.14 kernel. Is that ok ?
As per our conversation, here is my pull request for the config changes:
As part of an effort to foster better cross collaboration with internal Red
Hat kernels, align the configs layout to match that kernel. This will allow
Red Hat engineers to provide easier guidance on how to set various config
In addition, the scripts that process the config options will migrate to the
configs/ directory too. Future config workflows will stage all work in the
A simple diff between the kernels will easily expose which config options
are different. Reading the comments in the file provides guidance to Fedora
to determine if that kernel should make a similar change or not. While the
RH kernel stays internal, requested changes will be posted publicly for
review with said reason.
Rename debugconfig -> configs/base-debug
Rename baseconfig -> configs/base-generic
Rename configs/base-generic/arm/arm64 -> configs/base-generic/arm/aarch64
You can browse the changes here:
Note: Laura asked me not post the patches as the diffstat for the 'git mv'
is obnoxiously large. Instead I am providing the changes on pagure.
While experimenting with some refactoring, I noticed that /usr/include/cpuidle.h
was being picked up by the glob for kernel-headers. This is kind of unusual
because /usr/include/cpufreq.h exists in kernel-tools-libs-devel yet both
come out of install from cpupower tools. This header really belongs in
kernel-tools-libs-devel for consistency and I'd like to move it. I don't
anticipate there being any problems but if anyone can think of an issue for
moving this header from kernel-headers to kernel-tools-libs-devel please
let me know. I don't plan on doing anything about this until next week at the
earliest (Thanksgiving here in the US).
This is a problem I haven't previously seen on this laptop. So far it
won't reproduce with drm.debug, but I've seen it twice without. It
can't be reported due to kernel taint resulting from
i915.enable_guc_loading=1 i915.enable_guc_submission=1 which I can
disable if it's helpful.
[20016.975715] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun
[24380.311647] [drm:intel_dp_aux_ch [i915]] *ERROR* dp aux hw did not
signal timeout (has irq: 1)!
[24383.411501] ------------[ cut here ]------------
[24383.411504] DC6 already programmed to be enabled.
[24383.411694] WARNING: CPU: 2 PID: 5306 at
00:02.0 VGA compatible controller : Intel Corporation Skylake
GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA
4.15.0-0.rc1.git0.1.fc28.x86_64 is in koji and it will not boot with
Secure Boot enabled. I get an error from GRUB after choosing the boot
entry, that it has an invalid signature and the kernel needs to be
For some time now, Fedora has operated without a database of hardware
users have. Smolt, the old hardware database, was retired in 2012 and
its intended successor was never deployed by Fedora Infrastructure.
It would be nice to have a hardware database, so I (and hopefully some
others) would like to get Census up and running for Fedora. Before we
look at deploying Census, however, it would be good to make sure it has
everything we need.
Census has client plugins to collect information. At the moment, it
has plugins for:
* The vendor, device, subsystem_vendor, subsystem_device, and class from
each PCI device
* The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices
as well as the bInterfaceClass, bInterfaceSubClass, and
bInterfaceProtocol for each interface
* The contents of /etc/os-release
* All the RPMs installed on a system
Other than the drivers bound to the PCI and USB devices (which is an
open PR), what else would be good to collect?
I started playing around with having RPM automatically generate the
debuginfo subpackages per
Because the kernel is a continual source of exceptions, the existing
code doesn't handle the case where the debuginfo and file may have
The kernel modules are compressed at the install stage so foo.ko
becomes foo.ko.xz. The debuginfo is generated as foo.ko.debug.
The existing code to split debugfiles.list can't detect this so
those files end up as unpackaged. A similar problem happens with
the vmlinux for the main kernel.
Is this an issue that can reasonably be fixed or worked around to
support the debuginfo subpackages for the kernel? I want to make
sure I'm not digging myself into a hole before I spend more time
The 4.14 kernels brought up the virtual consoles in some weird
coloration scheme for the whole series. They would reset to the
default white on black when X was started. With the 4.15 kernel they
have returned to the behavior of all previous kernels, and now start
with white on black.
On Wed, Nov 15, 2017 at 6:09 PM, R P Herrold <herrold(a)owlriver.com> wrote:
> On Tue, 14 Nov 2017, Steven Whitehouse wrote:
>> I think it is probably overdue in the DECnet case, however I
>> did get a very happy with it for the most part. Anyway it is
>> clear that nobody is maintaining it and it seems sensible
>> that it should get removed unless someone with sufficient
>> time wants to step forward. That has not happened so far,
> I still have customers with Decnet in production (certain
> medical lab equipment 'just works' and uses the transport);
> until those units die, there will not be sufficient motivation
> on the customers' parts to spend the money to replace it (and
> at that time, a technology refresh will happen as well
> eyeglass labs, and colonoscopy testing, primarily
> The 'network' for units are physically isolated, and indeed,
> occasionally accessed only via a graphical terminal emulator
> such as VNC, facing into a TCP/IP network on a second
> interface. No need for updates here
Are those units or anything that needs to talk to them over DECNet