Hi,
I started playing around with having RPM automatically generate the
debuginfo subpackages per
https://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
Because the kernel is a continual source of exceptions, the existing
code doesn't handle the case where the debuginfo and file may have
different names.
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
on this.
Thanks,
Laura

I have compiled the 4.14.0-0.rc2.git0.1 kernel here with a custom
configuration. I've had two issues.
First, when I boot into multiuser, instead of white text on black
background, the virtual terms come up with gray text on white
background, a killer for the eyes. If I then start X, the virtual
terminals revert to white on black text. This was not an issue in the
13, or before, series of kernels.
Second, I had a system lockup. It has been multiple kernel series
since I have had one. The only configuration option that I changed
between 13 and 14 was to use the hardened slab freelist. I'll see if a
lockup happens again, or was a fluke.
Just a heads up that there might be some rough edges in the 14 series.

(Apologies - resending because I wasn't subscribed earlier)
Hi list,
I'm contacting you on behalf of the x86 SIG. Today FESCo approved our request to continue to support Fedora on x86 hardware, provided that we do our part to keep things running.
I encourage you to reach out to us when things do come up. You can find us at x86(a)lists.fedoraproject.org or on #fedora-x86. We will likewise try to be proactive in tracking down and triaging x86-related issues as well as helping test and debug things.
One caveat that FESCo attached to our request is that if you, the kernel team are cleared to treat i686 as any other secondary arch when you run into build issues. That is, you are allowed to ExcludeArch i686 until these issues are resolved. We ask that you block FE-ExcludeArch-x86 so that we can track these issues.
Additionally, FESCo would like us to establish a minimum level of hardware supported. We are working on this list and will follow up with you once we have it completed. In the interim, we did want to address a couple of concerns that were passed along by Stephen Smoogen:
* We have decided to drop support for PAE, so please feel free to disable it on the next build
* We have decided to continue to support pre-SSE2 hardware for the time being
Please don't hesitate to contact us with any questions/comments/concerns.
Thanks!
jeff
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackushttp://gitlab.com/jsbackus

Hi,
This patch fixes pcie on tegra20. This affects trimslice ethernet
usage (there is no network) on kernel 4.13+
https://marc.info/?l=linux-pci&m=150614748008380&w=2
While speaking about trimslice. I would like to consider dropping
ARM-tegra-usb-no-reset.patch because this patch is unneeded anymore
with any kernel/bootloader. It also prevent other tegra-ehci devices
to enter suspend.
I can submit patches if needed for both... (However I don't know if
it's won't be better for the patches to be submitted on the kernel
tree with source+fedora-patches (1) or the distgit version ?).
(1) https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/
Thx
--
-
Nicolas (kwizart)

Can we have a kernel package for the next- series on Rawhide?
I tried hacking it into the existing specfile but that just didn't work.
I'm thinking it needs to be its own package, providing
kernel=999-next-<date> or something like that. Obviously, anyone
installing this gets to deal with version conflicts and updates etc.

Hi,
Kernel 4.13 was released this past weekend. This kernel has been
built for rawhide and is building for F27 as well. We will be
following the same upgrade procedure as in the past. F25 and F26
will get rebased to 4.13 after a few stable releases, typically
4.13.2 or 4.11.3 depending on how stable the kernel is. Upstream
does not give release dates for stable release but given past
timings, this will probably happen towards the end of September.
As always, if you have any questions please let me know.
Thanks,
Laura

On Tue, Sep 5, 2017 at 6:25 PM, James Hogarth <james.hogarth(a)gmail.com> wrote:
>
>
> On 5 September 2017 at 22:40, Chris Murphy <lists(a)colorremedies.com> wrote:
>>
>> On Tue, Sep 5, 2017 at 3:38 PM, Chris Murphy <lists(a)colorremedies.com>
>> wrote:
>>
>> > FWIW, you can just download the F27 kernel, kernel-core,
>> > kernel-modules (optionally extras), and 'sudo dnf install *rpm' in
>> > that same download directory and it will install it without complaint.
>> > I routinely run Fedora built n+1 (typically rawhide) kernels on
>> > current release OS.
>>
>> Small gotcha is that you can't upgrade perf, dnf will complain. But
>> usually rudimentary use of current perf will work with a newer kernel.
>>
>>
>>
>
> Right ... with kernel-tools and perf I'd rather have something built against
> the F26 userspace ... but I have run the rawhidenodebug kernels in the past
> for testing ... it's just nicer and more representative for testing what
> will end up in the F26 repos to have the kernel built against F26 in the
> stabilization COPR
I've suggested in the past that we ship the userspace tools in a
completely separate package, leaving ONLY kernel bits in the kernel
SRPM and subpackages. Partly for this reason, and also because there
is no NEED to build e.g. perf daily. I'm willing to put my money
where my mouth is and do the maintenance on the userspace side if
people want to pursue this.
josh