Re: leds_pca9532 removed - why?
On Fri, Oct 18, 2024 at 8:57 AM Ian Pilcher wrote: > > On 10/17/24 1:36 PM, Ian Pilcher wrote: > > Ran 'dnf update' on my NAS, and discovered that the leds_pca9532 module > > has been removed. (CONFIG_LEDS_PCA9532 was changed from 'm' to not > > set.) > > > > Is there some reason for this removal? > > Justin - > > This was changed in this commit[1] without any real explanation. (Oddly > that same commit *enables* the driver in several non-x86_64 kernel > configs.) > > What was the reason for this? Those commits are useless from an informational standpoint and give no real information at all. We have to build out of dist-git, but the kernel is not maintained in dist-git, a script prepared dist-git based on what is in the source tree. That is why the commit you point to there is all over the place. https://gitlab.com/cki-project/kernel-ark is the source of truth for the Fedora kernel. In this case an MR came in and this seems to be unintentional fallout from it. Reviews on leds, dacs, thermal, regulators, etc are fairly hard because we really do not know what hardware is in the wild. I have reverted the offending commit in the fedora-6.11 branch, and put in a revert MR for os-build. In the meantime, I tagged the revert as include in release, so rawhide should be built correctly again starting tomorrow. Justin > [1] > https://src.fedoraproject.org/rpms/kernel/c/943f7ca039856de1015114a84ac35031b635d390 > > -- > > If your user interface is intuitive in retrospect ... it isn't intuitive > > -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.12 releases, and again with 6.13... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Differences between Fedora-built kernel and self-built kernel on Fedora?
On Thu, Sep 5, 2024 at 5:16 AM Richard W.M. Jones wrote: > > This is a bit of a weird one ... > > Attempting to reproduce and fix this bug: > > https://bugzilla.kernel.org/show_bug.cgi?id=219166 > > which involves booting a qemu VM with the kernel and observing a > fairly rare, but reproducible hang, I'm able to reproduce this > reasonably often if I boot the Fedora-built (ie. Koji) kernel. > > However when I copy /boot/config-6.11. to .config in the kernel > git tree, 'make olddefconfig', build and install it locally, then run > the test, it never seems to reproduce. Same config, and I'm even > using the same upstream git tag. > > I'm building it on Fedora Rawhide (same as Koji), so GCC and the rest > of the toolchain should be very close. > > My question is, what are other differences between the Fedora-built > kernel and a locally built kernel apart from config (the same), > version (the same), and toolchain (nearly the same)? Outside of the patches, there shouldn't really be many. Secure boot signatures should be the only difference assuming you are still building an rpm. If you are just doing native builds out of the git tree for local builds, stripping and such is also a bit different. > Fedora has a downstream patch set called 'patch-6.11-redhat.patch'. > It's not clear where this comes from, but I don't think it touches any > code that should affect my test. That patch comes from kernel-ark and if you look in the srpm or dist-git, it will actually have a file called Patchlist.changelog which includes commit hashes, the oneline, and a gitlab link to each individual patch contained in there. Of note, The rawhide kernel contains more patches than stable Fedora kernels as I strip out all of the RHEL specific patches when I branch for stable Fedora. > Other ideas welcome here as I'm out of ideas right now ... Do local mock builds show the same rate of failure? Wondering if this is a difference in what we are doing with rpm magic, something from a patch, or something else. Justin > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > nbdkit - Flexible, fast NBD server with plugins > https://gitlab.com/nbdkit/nbdkit > > -- > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.11 releases, and again with 6.12... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Building upstream kernel with Fedora config
On Thu, Jun 6, 2024 at 9:19 AM Thorsten Leemhuis wrote: > > [CCing Justin] > > On 04.06.24 18:12, Mikhail Gavrilov wrote: > > > Instruction [1] about building upstream kernel should be updated, > > I'd tend to disagree. I think the root of the problem should be fixed, > which you... > > > because since commit 5e6abd7f4dce [2] the Fedora kernel config contain > > CONFIG_SYSTEM_TRUSTED_KEYS="certs/rhel.pem" > > ...describe here. That's because other people will run into the problem > elsewhere then using localmodconfig and such -- like it is the case for > Debian already: > https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html#configmods-distros > > Did anyone report this to kernel-ark already? Or checked with kernel-ark > commit caused this? https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3160 is the commit which introduced it and it is a good change overall. The docs are what should be updated. Of note, the generated configs in dist-git and the srpm do not have this line, it is only there after we prep, so they do offer a fine place to start. I will be on limited availability the next week, but will take a look at updating the docs afterwards. Frankly, there is plenty in the doc which needs updating. Justin > Ciao, Thorsten -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: kernel package not build in mock environment anymore
On Sat, Jun 1, 2024 at 3:08 AM Mikhail Gavrilov wrote: > > Something broke in the build environment > I can't build the kernel package in the mock environment for two days. > I attached an archived build log here. I saw no build log attached. What kernel version were you trying to build, and which fedora version were you trying to build it against in mock? Thanks, Justin > -- > Best Regards, > Mike Gavrilov. > -- > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.10 releases, and again with 6.11... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Where is jforbes (kernel maintainer) for the next 4-8 weeks?
On Wed, Mar 6, 2024 at 3:20 PM Dan Horák wrote: > > Hi Justin, > > On Wed, 6 Mar 2024 14:50:57 -0600 > Justin Forbes wrote: > > > Unfortunately I will be out on medical leave for the next 4-8 weeks. > > Augusto Caringi (acaringi) has been doing a great job with the fedora > > stable kernel releases recently and will be the point of contact for > > fedora kernel issues in my absence. Other good points of contact > > include Peter Robinson (pbrobinson) and Scott Weaver (scweaver). I > > expect when I do come back it will be part time at first, and then > > ramp back up to full time over a few weeks. > > let me wish you fast and successful recovery. Can I expect the > rawhide-nodebug repo to be updated as well during your leave? If some > help is needed to keep it updated, please let me know. I am guessing not unfortunately. At least for a couple of weeks. That is tied to my login on the repository server. It is likely one of the first things that I will pick up when I start poking back in. In the meantime, you can manually download and install the kernels from rawhide. I expect we will only have 1-2 releases that would be impacted as the merge window will open soon. Justin > Thanks, > > Dan > -- > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Where is jforbes (kernel maintainer) for the next 4-8 weeks?
Unfortunately I will be out on medical leave for the next 4-8 weeks. Augusto Caringi (acaringi) has been doing a great job with the fedora stable kernel releases recently and will be the point of contact for fedora kernel issues in my absence. Other good points of contact include Peter Robinson (pbrobinson) and Scott Weaver (scweaver). I expect when I do come back it will be part time at first, and then ramp back up to full time over a few weeks. Justin -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: asking for help on i686 kernel problem v2
On Tue, Mar 5, 2024 at 7:10 AM Sérgio Basto wrote: > > On Tue, 2024-03-05 at 07:59 -0500, Prarit Bhargava wrote: > > On 3/4/24 11:49, Sérgio Basto wrote: > > > Hi, > > > > > > We can't build webkitgtk on i686 lately. > > > > > > webkitgtk is in critical path and break rawhide composes, if fail > > > to > > > install [1] , so we can't soname bump jpegXL > > > > > > As reported in https://pagure.io/fedora-infrastructure/issue/11775 > > > seems that downgrade kernel from 6.7.4-200 to 6.6.14-200 fixes the > > > builds on i686 . > > > > > > > sergio, can you reproduce this locally or only in rawhide composes? > > > > We can't build webkitgtk on i686 lately on koji . > https://koji.fedoraproject.org/koji/taskinfo?taskID=113473482 > > The news, reported in > https://pagure.io/fedora-infrastructure/issue/11775 , > > kernels 6.8.x already appears to have a fix ( to build webkitgtk on > koji, i686 arch ) It might be valid to bisect and see which introduces the fix, but we are in an infra freeze, and I know that the infra team is looking at upgrading the large builders to work around this bug. I said I was comfortable enough with rc7 as a builder kernel. Justin > > > P. > > -- > > ___ > > kernel mailing list -- kernel@lists.fedoraproject.org > > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > -- > Sérgio M. B. > -- > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.8 releases, and again with 6.9... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.7 releases, and again with 6.8... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.6 releases, and again with 6.7... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.5 releases, and again with 6.6... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What is the current procedure to patch the kernel in the spec file?
On Wed, May 31, 2023 at 1:10 PM stan via kernel
wrote:
>
> It has been ages since I wanted to patch the kernel when I built a
> custom kernel. I tried putting the patch in the spec file where the
> other patches were, but it doesn't apply. There is no error, or even
> indication that it saw the patch, so I am obviously doing it
> incorrectly.
>
> I'm building the kernel from the srpm using rpmbuild. It builds fine
> when unpatched. I can, of course, just untar the kernel tar file,
> apply the patch, and tar it. But, it should be simple to do from the
> spec file directly. Can anyone point me to the current procedure?
>
> Here is what is in the spec file:
> ```
> ## Patches needed for building this package
>
> %if !%{nopatches}
>
> Patch1: patch-%{patchversion}-redhat.patch
> Patch2: 0001-my_custom_change.patch
> %endif
> # empty final patch to facilitate testing of kernel patches
> Patch99: linux-kernel-test.patch
> ```
>
> I tried it outside the if, still didn't work:
> ```
> ## Patches needed for building this package
>
> %if !%{nopatches}
>
> Patch1: patch-%{patchversion}-redhat.patch
> %endif
> Patch2: 0001-my_custom_change.patch
> # empty final patch to facilitate testing of kernel patches
> Patch99: linux-kernel-test.patch
> ```
>
> Here is the output with this version in the spec file.
>
> + ApplyOptionalPatch patch-6.4-redhat.patch
> + local patch=patch-6.4-redhat.patch
> + shift
> + '[' '!' -f /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch ']'
> ++ wc -l /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch
> ++ awk '{print $1}'
> + local C=2978
> + '[' 2978 -gt 9 ']'
> + ApplyPatch patch-6.4-redhat.patch
> + local patch=patch-6.4-redhat.patch
> + shift
> + '[' '!' -f /home/stan/rpmbuild/SOURCES/patch-6.4-redhat.patch ']'
> + case "$patch" in
> + git --work-tree=. apply
> + ApplyOptionalPatch linux-kernel-test.patch
> + local patch=linux-kernel-test.patch
> + shift
> + '[' '!' -f /home/stan/rpmbuild/SOURCES/linux-kernel-test.patch ']'
> ++ wc -l /home/stan/rpmbuild/SOURCES/linux-kernel-test.patch
>
> It finds the Patch99 patch which is empty, and in
> ~/rpmbuild/SOURCE like my patch, so why isn't it finding my patch?
Patch2: just adds it to the file manifest for the srpm. You have to
apply it in some manner. While we used to have a weird git routine
that set everything up as a git tree and did git am using the
manifest, that was a lot of unnecessary overhead, and of little value
when most development is done in the source tree now.
You need another line in the spec:
ApplyOptionalPatch 0001-my_custom_change.patch
Of note, the linux-kernel-test.patch is also meant to facilitate
people doing quick builds with a patch in dist-git. You could 'cat
0001-my_custom_change.patch > linux-kernel-test.patch' and not have to
touch the spec at all.
Justin
> Thanks for any help.
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: CONFIG_NFT_CONNLIMIT is not set
On Wed, May 17, 2023 at 9:37 AM Steve Bennett wrote: > > Hi, > > Is there a reason why CONFIG_NFT_CONNLIMIT is not set in default Fedora > kernels? > I think there was a problem with it in early kernel 4.19, but that was quite > a while ago, and as it stands it seems that documented functionality is > unavailable with no easy workaround. That's it, it was problematic when it came in upstream, and no one has asked us to flip it back on since. I have just flipped it on for the fedora-6.3 branch and rawhide. Unfortunately the 6.3.3 rebase builds are already almost done, so it will show up in 6.3.4 for stable Fedora releases. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RHEL9 & ark commit 4419eb4efd6d ("kernel.spec.template: Add global compression variables")
On Wed, May 3, 2023 at 7:12 AM Prarit Bhargava wrote:
>
> ark commit 4419eb4efd6d ("kernel.spec.template: Add global compression
> variables") looks like it broke the weak-modules script. The
> weak-modules script expects a gzip'd symvers file, not an xz'd one.
>
> Working on a fix for the weak-modules script.
This actually breaks the post scripts, leaving us without a proper
kernel installed on ELN. The compose will not work until this is
fixed.
Justin
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.4 releases, and again with 6.3... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: soname bump: libtraceevent and libtracefs
On Mon, Apr 17, 2023 at 2:45 PM John Kacur wrote: > > There is a new tool that is dependent on these libs too. Also from Daniel > Bristot (rtla) > tools/verification/rv > > I was wondering if we could get this into rawhide? Yes, I will get it in before the 6.3 release next Monday, that way it will automatically follow into stable Fedora as they get the 6.3 rebase. Justin > John Kacur > > On Sun, Apr 9, 2023 at 12:12 AM Zamir SUN wrote: >> >> >> On 4/5/23 23:49, Justin Forbes wrote: >> > On Wed, Apr 5, 2023 at 5:05 AM Zamir SUN wrote: >> >> >> >> Hi, >> >> >> >> I'm working on libtraceevent and libtracefs update. There will be soname >> >> bump happening to them. Namely, >> >> >> >> libtraceevent.so 1.6.3 -> 1.7.2 >> >> libtracefs.so 1.5.0 -> 1.6.4 >> >> >> >> IIRC only kernel-tools (for perf and rtla) and trace-cmd depends on >> >> them. So I'm also copying their corresponding contacts. >> >> >> >> As for libtraceevent, I've tried running trace-cmd/perf/rtla with the >> >> new version and they still works. So I've updated it in Rawhide, Fedora >> >> 38 and Fedora 37. They are now in Bodhi. >> >> >> >> As for libtracefs I've built it in side tag f39-build-side-65890. I plan >> >> to update it in both Rawhide and Fedora 38 this week. >> > >> > Given that we are in a freeze for F38, it might be better to wait >> > until GA, but I have rebuilt kernel-tools in the sidetag. Please let >> > me know when this is merged back as we rebuild kernel-tools weekly in >> > rawhide. >> > >> >> Hi Justin, >> >> I think this is a good point. I will coordinate with you when I do it >> for Fedora 38. >> >> -- >> Zamir SUN >> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E >> Want to know more about Fedora? >> Visit https://fedoraproject.org/wiki/ >> Ready to contribute? See https://whatcanidoforfedora.org/ >> 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/ >> ___ >> devel mailing list -- de...@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: soname bump: libtraceevent and libtracefs
On Wed, Apr 5, 2023 at 5:05 AM Zamir SUN wrote: > > Hi, > > I'm working on libtraceevent and libtracefs update. There will be soname > bump happening to them. Namely, > > libtraceevent.so 1.6.3 -> 1.7.2 > libtracefs.so 1.5.0 -> 1.6.4 > > IIRC only kernel-tools (for perf and rtla) and trace-cmd depends on > them. So I'm also copying their corresponding contacts. > > As for libtraceevent, I've tried running trace-cmd/perf/rtla with the > new version and they still works. So I've updated it in Rawhide, Fedora > 38 and Fedora 37. They are now in Bodhi. > > As for libtracefs I've built it in side tag f39-build-side-65890. I plan > to update it in both Rawhide and Fedora 38 this week. Given that we are in a freeze for F38, it might be better to wait until GA, but I have rebuilt kernel-tools in the sidetag. Please let me know when this is merged back as we rebuild kernel-tools weekly in rawhide. Justin > HTH. > > -- > Zamir SUN > GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E > Want to know more about Fedora? > Visit https://fedoraproject.org/wiki/ > Ready to contribute? See https://whatcanidoforfedora.org/ > 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/ > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Building custom kernel using rpmbuild with spec file gives error on cpufreq.h Is it meaningful?
On Sun, Mar 5, 2023 at 12:48 PM stan via kernel
wrote:
>
> Hi,
> I just built a kernel from the 6.2.2 fc37 src.rpm. It built fine, but
> at the end there was a missing file warning for cpufreq.h. I build the
> header files when building the kernel, so I would think that would be
> included in them.
>
> The error:
> + exit 0
> File not found:
> /home/stan/rpmbuild/BUILDROOT/kernel-6.2.2-300.20230305.fc37.x86_64/usr/include/cpufreq.h
> absolute symlink: /lib/modules/6.2.2-300.20230305.fc37.x86_64/build ->
> /usr/src/kernels/6.2.2-300.20230305.fc37.x86_64
>
> The second one is always there, a warning about a workaround as I
> understand it.
>
> I find this in the SPEC file:
> %if %{with_headers}
> %files headers
> /usr/include/*
> %exclude %{_includedir}/cpufreq.h
> %endif
>
> When I search the BUILD tree I find:
> ./linux-6.2.2-300.20230305.fc37.x86_64/include/linux/cpufreq.h
> ./linux-6.2.2-300.20230305.fc37.x86_64/include/linux/sched/cpufreq.h
>
> It seems that these are there but the above stanza in the SPEC file is
> excluding them. Is there a reason? Is it harmless?
>
> There is another cpufreq.h present,
> ./linux-6.2.2-300.20230305.fc37.x86_64/tools/power/cpupower/lib/cpufreq.h
> but I am not building tools, so it is probably being ignored. Do I
> have to build tools to pick this up?
More detail on this is in
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1903 but
for Fedora, we ship cpufreq.h in kernel-tools, not kernel-headers.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.3 releases, and again with 6.4... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rawhide Kconfig changes late in the -rc cycle
On Sat, Feb 11, 2023 at 1:37 AM Ondrej Mosnáček wrote: > > On Fri, Feb 10, 2023 at 9:10 PM Justin Forbes wrote: > > > > On Fri, Feb 10, 2023 at 11:28 AM Paul Moore wrote: > > > > > > On Fri, Feb 10, 2023 at 12:15 PM Paul Moore wrote: > > > > > > > > Hi Fedora Kernel People, > > > > > > > > The SELinux folks recently stumbled across some test failures due to a > > > > change in the Rawhide kernel config that happened this week while we > > > > are at -rc7 (see lore archive link below). Now, to be clear, I think > > > > the Kconfig change is good, TIOCSTI is generally pretty scary, but in > > > > my opinion changing the kernel config at the -rc7 stage is also a bit > > > > scary :) I don't know all the background on the Rawhide change, or if > > > > there is a policy for Rawhide Kconfig changes, but if it is possible I > > > > would suggest the in the future it might be advisable to restrict > > > > Kconfig changes past -rc5 (give or take) to only those which are > > > > critical changes. > > > > > > > > Test/CI failures this late in the kernel -rc cycle are always a little > > > > worrisome and it would be nice to know that we're not intentionally > > > > making it worse ;) > > > > > > > > https://lore.kernel.org/selinux/cahc9vhrt0d-xwkw8ulgomxsaqfpa4mmp6+sl5kfonbf-mz8...@mail.gmail.com > > > > > > ... and of course as soon as I hit send on the previous email I see a > > > new test/CI run has completed with CONFIG_LEGACY_TIOCSTI back to being > > > set/y :) Regardless, I'd still like to encourage restraint on Kconfig > > > changes late in the -rc cycle if possible. > > > > > Not sure why there would be another with it set to =y, it is set to =y > > for ELN/RHEL, but is turned off for Fedora. I do apologize for the > > late addition. I do try to set them earlier, but due to some existing > > MRs and other priorities I waited and did not set any of the 6.2 > > configs for Fedora until this week. > > There's something weird going on, because it has been flipped several > times in dist-git (kernel-x86_64-fedora.config file): > 4376058937ad4fea84039d3f771ff7353add9840: > kernel-6.2.0-0.rc7.20230210git38c1e0c65865.54 > changed y->n > 64f643ed7fd2868bfaa8e230acfe3d547a58e626: > kernel-6.2.0-0.rc7.20230210git38c1e0c65865.54 > changed n->y > 9c6fc5421516884b09e8f7ce36dffbf8c4ca66aa: > kernel-6.2.0-0.rc7.20230209git0983f6bf2bfc.52 > changed y->n > 137e8e95cc84597967b6d994ea3d088d53f7ce6e: > kernel-6.2.0-0.rc0.20221219gitf9ff5644bcc0.7 > initially set to y > > Some maintainer script gremlins acting up? :) Sadly this wasn't automated, it was a forgotten git push one day, and a dist-git push before my coffee the next (it wasn't built before it was fixed). Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rawhide Kconfig changes late in the -rc cycle
On Fri, Feb 10, 2023 at 11:28 AM Paul Moore wrote: > > On Fri, Feb 10, 2023 at 12:15 PM Paul Moore wrote: > > > > Hi Fedora Kernel People, > > > > The SELinux folks recently stumbled across some test failures due to a > > change in the Rawhide kernel config that happened this week while we > > are at -rc7 (see lore archive link below). Now, to be clear, I think > > the Kconfig change is good, TIOCSTI is generally pretty scary, but in > > my opinion changing the kernel config at the -rc7 stage is also a bit > > scary :) I don't know all the background on the Rawhide change, or if > > there is a policy for Rawhide Kconfig changes, but if it is possible I > > would suggest the in the future it might be advisable to restrict > > Kconfig changes past -rc5 (give or take) to only those which are > > critical changes. > > > > Test/CI failures this late in the kernel -rc cycle are always a little > > worrisome and it would be nice to know that we're not intentionally > > making it worse ;) > > > > https://lore.kernel.org/selinux/cahc9vhrt0d-xwkw8ulgomxsaqfpa4mmp6+sl5kfonbf-mz8...@mail.gmail.com > > ... and of course as soon as I hit send on the previous email I see a > new test/CI run has completed with CONFIG_LEGACY_TIOCSTI back to being > set/y :) Regardless, I'd still like to encourage restraint on Kconfig > changes late in the -rc cycle if possible. > Not sure why there would be another with it set to =y, it is set to =y for ELN/RHEL, but is turned off for Fedora. I do apologize for the late addition. I do try to set them earlier, but due to some existing MRs and other priorities I waited and did not set any of the 6.2 configs for Fedora until this week. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rawhide and debug kernel changes
On Fri, Feb 3, 2023 at 6:52 AM Dan Horák wrote: > > On Thu, 2 Feb 2023 14:17:36 -0600 > Justin Forbes wrote: > > > As the MR is now merged, it is a good time to make sure that everyone > > is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build > > with any kernels. All rawhide kernels are now built just like stable > > Fedora kernels, with both non-debug and debug variations. This > > change was necessary because performance has degraded with debug > > kernels to the point that there were very few people using them, > > meaning fewer people testing daily upstream development builds. > > Changing the config to make the performance acceptable to more would > > take away much of the usefulness of the debug builds to begin with. > > We do still appreciate those who have the patience and ability to run > > rawhide debug kernels when possible just because they do still find > > the occasional lockdep issue, or other problems that would be hidden > > by a non-debug kernel. > > > > In addition to this change, I have added debug builds for aarch64 > > kernels. Previously, debug kernels were only available on x86. > > do you plan to still populate the RawhideKernelNodebug repo with the > current kernel rcs for use on the stable releases? I had planned to discontinue this, but I suppose I can continue if there is value in it. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Rawhide and debug kernel changes
As the MR is now merged, it is a good time to make sure that everyone is aware. As of 6.2-rc5, Rawhide is no longer forcing a debug build with any kernels. All rawhide kernels are now built just like stable Fedora kernels, with both non-debug and debug variations. This change was necessary because performance has degraded with debug kernels to the point that there were very few people using them, meaning fewer people testing daily upstream development builds. Changing the config to make the performance acceptable to more would take away much of the usefulness of the debug builds to begin with. We do still appreciate those who have the patience and ability to run rawhide debug kernels when possible just because they do still find the occasional lockdep issue, or other problems that would be hidden by a non-debug kernel. In addition to this change, I have added debug builds for aarch64 kernels. Previously, debug kernels were only available on x86. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rawhide and debug kernels
On Thu, Jan 26, 2023 at 4:39 PM Bruno Wolff III wrote: > > I'm not too great at figuring how you tell which is which from the build > process, but there was a comment in a kernel build today that suggests > that things have changed so that now rawhide kernels are nodebug by default. > Is that correct? Yes, that was the result of this discussion tied with some bugzilla discussion and other various places. As the MR that did it is "include in release" it has been the case for all RC5 and newer builds, but I was waiting to make an official announcement until the MR is approved and merged. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Rawhide and debug kernels
For a *very* long time, Rawhide has built rcX kernels as "release" kernels and daily git snapshots as debug kernels only. This has brought attention to some issues that might otherwise be missed. Specifically around things like lockdep. Unfortunately, even without changing our selected debug options, performance has gotten considerably worse for these debug kernels due to upstream code changes. At the same time, we do have some additional automated testing happening now that was not happening before, which we can explicitly point at debug kernels. I am wondering if it is time to switch rawhide to work the way that everything else does, building both debug and nodebug builds every day, instead of forcing debug builds 80% of the time. It would mean a reduction in coverage, but I am not sure by how much, as I get the impression that most rawhide users are sticking to the nodebug kernels anyway. It would also allow us to turn on some more debug features for our debug kernels that are a bit more performance limiting, but extremely useful. We have left them off in Fedora specifically because they were too heavy weight for expecting users to run them. So, what does the community think? Should we continue as is, or should we move to a more typical model where both debug and non-debug kernels are build with every build? Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.2 releases, and again with 6.3... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Sat, Nov 26, 2022 at 9:54 AM Hans de Goede wrote:
>
> Hi,
>
> On 11/25/22 11:40, Thorsten Leemhuis wrote:
> > Hi! The following is all nitpicking. I hope it won't cause a
> > bikeshedding discussion, I'm not going to fight for any of this, I just
> > want to get it of my chest.
>
> Sorry, I do have somewhat of a bikeshed suggestion:
>
> > On 25.11.22 11:09, Gerd Hoffmann wrote:
> So how about splitting 'kernel-core' into a modules and a kernel binary
> package? Like this:
>
> kernel-modules-core - the modules from current 'kernel-core'
> kernel-modules-standard - current 'kernel-modules' renamed (maybe
> skip rename, but I think it'll be less
> confusing that way).
> kernel-modules-{extra,internal} - no changes
> >
> > I always found "internal" confusing, because it makes my head go
> > "internal to what? The Kernel?". Hence while we're reshuffling this, why
> > not make it more obvious what this package contains and call it
> > something like "kernel-modules-testing" or something like that?
>
> I agree that internal is confusing. But testing reminds me of
> updates-testing, so I find -testing this somewhat confusing too.
>
> Usually packaged test programs are called just tests, so maybe we can
> go with: "kernel-modules-tests" or "kernel-modules-selftests" ?
The "internal" bit is a leftover RHELism, and it is internal as in not
shipped. Obviously this does not translate well to Fedora as we do
ship them. While I am fine with a rename, I am not sure what amount of
effort is actually required there because tooling is in place to
ensure that the package doesn't get included or shipped for RHEL
customers.
Justin
> Regards,
>
> Hans
>
>
>
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: pending CONFIGs and MRs to review
On Mon, Oct 17, 2022 at 6:08 PM Prarit Bhargava wrote: > > > > While this does sound useful, it means we must create the commits, > > push to create an MR, then immediately go back and edit the commits > > because we have an MR number now. This link would be short lived as > > it would go away once out of pending (or a number of other scripts get > > unhappy). At the height of the upstream cycle, we tend to have less > > than 50 config MRs open for things in pending. It seems just as easy > > to search it. > > > > Is there an easier way other than searching every MR? Well, search is a pretty strong term when you can likely glance at the list of open MRs and choose the right one, but no. Not really anything easier, but again, how often are we pushing things into CS9 that are barely upstream. It is a race condition, and the window is generally small. The SOC bit was a bug, or it wouldn't have been left in pending most likely. Justin > > P. > > > >> P. > >> ___ > >> kernel mailing list -- kernel@lists.fedoraproject.org > >> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > >> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > >> Do not reply to spam, report it: > >> https://pagure.io/fedora-infrastructure/new_issue > > > ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: pending CONFIGs and MRs to review
On Sun, Oct 16, 2022 at 9:43 AM Prarit Bhargava wrote:
>
> Hey ptalbert and jforbes,
>
> I'm writing a script that will automate some of the CS9/RHEL CONFIG reviews.
>
> One thing I'm doing in the script is comparing the CS9/RHEL CONFIG value
> to the ARK value. If they match then the scripts passes. If they don't
> match then the script finds all "similar" ARK CONFIG values and displays
> their value.
>
> For example (sorry for the crappy formatting in email),
>
> A CONFIG change in RHEL commit 1df606e96b65 ("rehdat/configs: set
> missing options relevant to CXL update") does not match ARK.
> An ARK MR should be opened to make this change in the ARK repository.
> Take care to confirm arch-specific and fedora/ark/common changes.
> RHEL: ./redhat/configs/ark/generic/CONFIG_PROVE_CXL_LOCKING:#
> CONFIG_PROVE_CXL_LOCKING is not set
> ARK : ./redhat/configs/ark/generic/CONFIG_PROVE_CXL_LOCKING does
> not exist.
> Here are some CONFIG files in ARK that might match:
> ./redhat/configs/common/generic/CONFIG_PROVE_CXL_LOCKING:#
> CONFIG_PROVE_CXL_LOCKING is not set
>
> ./redhat/configs/fedora/generic/arm/armv7/CONFIG_PROVE_CXL_LOCKING:CONFIG_PROVE_CXL_LOCKING=y
>
> ./redhat/configs/fedora/generic/s390x/CONFIG_PROVE_CXL_LOCKING:CONFIG_PROVE_CXL_LOCKING=y
>
> Note I'm still working on the wording of "An ARK MR should be opened to
> make this change in the ARK repository." as the issue really may be the
> RHEL/CS9 MR.
>
> In any case, an interesting warning is when the ARK CONFIG is in one of
> the pending directories, for example,
>
> A CONFIG change in RHEL commit 33b6bfac97e1 ("RHEL: ALSA: update
> configuration") does not match ARK.
> An ARK MR should be opened to make this change in the ARK repository.
> Take care to confirm arch-specific and fedora/ark/common changes.
> RHEL: ./redhat/configs/common/generic/CONFIG_SND_SOC_TAS2780:#
> CONFIG_SND_SOC_TAS2780 is not set
> ARK : ./redhat/configs/common/generic/CONFIG_SND_SOC_TAS2780 does
> not exist.
> Here are some CONFIG files in ARK that might match:
>
> ./redhat/configs/fedora/generic/CONFIG_SND_SOC_TAS2780:CONFIG_SND_SOC_TAS2780=m
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Symbol: SND_SOC_TAS2780 [=n]
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:# Type
> : tristate
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Defined at sound/soc/codecs/Kconfig:1539
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Prompt: Texas Instruments TAS2780 Mono Audio amplifier
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Depends on: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && I2C [=y]
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Location:
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Main menu
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> Device Drivers
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> Sound card support (SOUND [=m])
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> Advanced Linux Sound Architecture (SND [=m])
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> ALSA for SoC audio support (SND_SOC [=m])
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> -> CODEC drivers
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> Implied by [n]:
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:# -
> SND_SOC_ALL_CODECS [=n] && SOUND [=m] && !UML && SND [=m] && SND_SOC
> [=m] && COMPILE_TEST [=n]
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> ./redhat/configs/pending-ark/generic/CONFIG_SND_SOC_TAS2780:#
> CONFIG_SND_SOC_TAS2780 is not set
>
> I was hoping to code the script to say something like "A similar CONFIG
> has been found in pending-ark. You can review this change by viewing
> ARK MR xxx".
>
> The problem I'm having is determining xxx :)
What you are describing is such a rare event, that I am not sure it is
worth scripting. The SND_SOC in pending stood there for too long
because of a script failure to create the MR itself during the 6.0
merge window. We did not notice it until the 6.0 cycle was over. We
have seen such script failures on average, less than once per year.
By rules, provided no similar script failures, no config item should
be in pending by the time it is in a released kernel. In practice, a
large number of those MRs are acked and merged long before the
released kernel phase, and we are simply chasing down a few stragglers
by rc5 or so. And now that we are more aware of the possibility of a
script failure in that particular place, I will be on the lookout for
them as well to
Re: Plans for MGLRU?
On Thu, Oct 13, 2022 at 6:11 AM Bruno Wolff III wrote: > > Are you guys thinking of enabling MGLRU soon? Yes, config options for Fedora typically get set somewhere between rc3 and rc7, with bigger changes earlier in the cycle and more of the small drivers set later. I do intend to flip MGLRU on though. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
Please rebase any pending MRs and repush. As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.1 releases, and again with 6.2... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Wed, Sep 21, 2022 at 4:48 AM Gerd Hoffmann wrote: > > Hi, > > > > Should we have a Fedora feature page for unified kernel support? > > > > I'm not sure we especially want to publicise unified kernel images as > > a standalone thing to users, as it is more of just a building block. > > > > If we're going to show any "feature", I think it probably ought to be > > oriented around a higher level user solution, of which unified kernel > > images are just one piece of the puzzle. > > Yes. Just the kernel package updates are not enough. The bare minimum > which I think makes sense as feature is: > > (1) adding the unified kernel sub-rpm discussed here, and > (2) bootloader support (be that sd-boot or grub or both), and > (3) kernel install script support (so 'dnf update' kernel updates work). > > With that in place it should be possible to install VMs using the > unified kernel sub-rpm and everything works as it did before, even when > it requires some hacks here and there, such as tagging partitions > manually or in kickstart %post for > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > The above will already plug the initrd hole. From a kernel standpoint, I am interested in this. We do need to ensure that we are doing it in a way that is easily extensible to not just cloud images in the future. > > eg I would see "Trusted boot for cloud images" as a feature, by which > > I mean publishing cloud images capable of using SecureBoot and vTPM, > > to do attestable boot on UEFI, without the unsigned initrd hole present > > as today. > > > > So, this would mean uing unified kernel images, either directly launched > > from shim, or with sd-boot in there to provide a UI selection. Either > > way not grub, since it is impractical to do attestation with grub's use > > of PCRs. Also likely mean use of discoverable partitions. > > Yep, that all makes sense, but I'd tend to not add that as 'required' > to the feature page. My list of nice-to-have optional stuff: > > (4) attestable boot (i.e. no grub b/c PCR mess). > (5) provide pre-calculated PCRs (could be published as kernel-pcrs > sub-rpm). > (6) add discoverable partitions to anaconda (so we don't need %post > hacks). > (7) add discoverable partitions to image builder (and whatever else > generates cloud images). > (8) switch cloud images to unified kernels. > > I think I've seen fedora feature pages with optional sub-goals before, > even though I can't find one right now, so I think it should be possible > to handle things that way. > > > I know there's been some desire to move Fedora cloud images to be UEFI > > only, so it might dovetail with that to some degree. > > Hack grub so it can pull out kernel + initrd out of a unified kernel > image and boot unified kernel images in bios mode that way should be > possible. Would allow to migrate cloud images to unified kernels without > requiring UEFI. > > > It would likely > > touch kernel, anaconda, systemd and cloud images, so there's some > > coordination & discussion needed to agree on the big picture. > > Sure. Having a feature page drawing that big picture would be helpful > for these discussions I think ... Definitely a system wide change. While there are some logistics to work out on the kernel side, most of the work is packaging. I would guess timelines will need to be defined by the teams where code is needed. Justin > take care, > Gerd > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Thu, Sep 1, 2022 at 9:58 AM Daniel P. Berrangé wrote: > > On Thu, Sep 01, 2022 at 10:37:03AM -0400, Prarit Bhargava wrote: > > Hey Gerd, > > > > Thanks for this changeset. > > > > On 8/31/22 08:46, Gerd Hoffmann wrote: > > >Hi, > > > > > > Here is a little patch series to kick off a discussion on pre-generated > > > initrd images and unified kernels. Lets start with a description of the > > > patches: > > > > > >Patch #1 adds a dracut config file, targeting virtual machines. Given > > >that most physical machines have either sata or nvme disks these days > > >it probably boots most physical systems too. > > > > No critical objections from me, however, just a few long-term questions > > about this approach. > > > > How are you going to prevent feature-creep in the initrd? What happens when > > someone asks us to include "driver X" in this general initrd? How do we > > determine whether or "driver X" is or is not appropriate for inclusion? > > If we limit the targetted usage to only be VMs, then we limit the > scope of drivers significantly, since there's a small finite set of > hypervisor we care about providing disk images for (VMware, HyperV, > Xen, KVM), and thus we know what drivers are needed in order to > be able to get out of the initrd into the root fs. > > If we extend to usage in bare metal scope of drivers becomes a little > more open ended potentially, and I don't have a definite answer for > what the criteria would be in that case. > > Worth noting though that systemd has a extension mechanism > > https://www.freedesktop.org/software/systemd/man/systemd-sysext.html > > that can be used to augment the pre-built initrd with further content. > Fedora could ship certain drivers are separate extension images, or > users could build their own extension images (though they would need > to deal with their own SecureBoot keys in the latter case). There are some other options here for longer term, ways to hopefully make this easier to deal with. I like the concept of this, and it is rather surprising just how many "kernel bugs" end up being badly generated initramfs on a local machine, which this can also help alleviate. I need to think it through a bit, but my initial reaction is that the advantages outweigh the disadvantages. > > > >Patch #2 adds a sub-package with an initrd image. > > > > > >Patch #3 adds a sub-package with an unified kernel. > > > > These will be built all the time. I'm worried about storage, etc., when > > adding new sub-packages. Having said that, I do really like the idea ;) and > > would definitely argue that it is worth it. > > For reference, in the kernel-virt-unified sub-RPM that my patches build, > I'm created two EFI images, each of which is 40 MB in size, so total > of 80 MB size for that new sub-RPM. When -debug builds are enabled, > you get the same again for kernel-debug-virt-unified, so 160 MB total. > > THe overall kernel build output for x86_64 is 2.1 GB though, largely > thanks to the enourmous -debuginfo packages, which dwarfs the extra > 160 MB for these EFI images. The debuginfo rpms are not passed around nearly as much in many contexts, so it is a significant change. I am not saying it is not worthwhile, just saying the size difference does need to be kept in context (how many people mirror repos, but not debuginfo?) Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora and 5.19
On Thu, Aug 4, 2022 at 9:04 AM Justin Forbes wrote: > > On Thu, Aug 4, 2022 at 5:44 AM Peter Robinson wrote: > > > > On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede wrote: > > > > > > Hi, > > > > > > On 8/2/22 22:15, Justin Forbes wrote: > > > > The initial fedora-5.19 branch has been created in kernel-ark. As I > > > > mentioned earlier, F37 will branch a 6.0 merge window kernel, but that > > > > will be replaced with 5.19 as soon as possible. > > > > > > I'm not sure when F37 branches of, but it would it not be better > > > to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its > > > own branch ? > > > > > > My main worry here is how you are going to get F37/rawhide consumers > > > to move back from 5.20 to 5.19. The only way I see to do this is > > > bump the epoch, which we generally try to avoid ? > > > > dnf distro-sync will also downgrade but I two have concerns. > > > > I suppose I was rather counting on people to just do it by hand if > they were concerned. F37 branches next Tuesday, so it will still be in > the merge window. I somewhat figured users that are willing to run > merge window kernels are probably a bit more capable of managing an > rpm downgrade if necessary. > > > I wonder if not doing something similar to what we do when stabilising > > kernels would work, push 5.19 to that and build there while keeping > > rawhide branch as 5.20 rc and doing builds for it but not tagging it > > into the rawhide release until branching. There might need to be a > > special branch process there too. Messy for dev side but probably less > > messy for uses. > > I suppose I could have them untagged with each build (yesterday's > failed as I need filter updates). That does get a bit problematic > though, as it would likely subject those kernels to deletion after > some time, and make it harder for people using them for a "koji > bisect". Not really sure the right answer there. Turns out there are some build issues due to kunit. Multiple ways to work around them, but trying to figure out the best path going forward. so at this point I have done source commits, but won't do a proper 6.0 build until after the branch. > Justin > > > Peter > > ___ > > kernel mailing list -- kernel@lists.fedoraproject.org > > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora and 5.19
On Thu, Aug 4, 2022 at 5:44 AM Peter Robinson wrote: > > On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede wrote: > > > > Hi, > > > > On 8/2/22 22:15, Justin Forbes wrote: > > > The initial fedora-5.19 branch has been created in kernel-ark. As I > > > mentioned earlier, F37 will branch a 6.0 merge window kernel, but that > > > will be replaced with 5.19 as soon as possible. > > > > I'm not sure when F37 branches of, but it would it not be better > > to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its > > own branch ? > > > > My main worry here is how you are going to get F37/rawhide consumers > > to move back from 5.20 to 5.19. The only way I see to do this is > > bump the epoch, which we generally try to avoid ? > > dnf distro-sync will also downgrade but I two have concerns. > I suppose I was rather counting on people to just do it by hand if they were concerned. F37 branches next Tuesday, so it will still be in the merge window. I somewhat figured users that are willing to run merge window kernels are probably a bit more capable of managing an rpm downgrade if necessary. > I wonder if not doing something similar to what we do when stabilising > kernels would work, push 5.19 to that and build there while keeping > rawhide branch as 5.20 rc and doing builds for it but not tagging it > into the rawhide release until branching. There might need to be a > special branch process there too. Messy for dev side but probably less > messy for uses. I suppose I could have them untagged with each build (yesterday's failed as I need filter updates). That does get a bit problematic though, as it would likely subject those kernels to deletion after some time, and make it harder for people using them for a "koji bisect". Not really sure the right answer there. Justin > Peter > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora and 5.19
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible. We will also do stabilization for the 5.19 branch and hope to rebase Fedora 35 and 36 to 5.19 in a timely manner. Test week will be August 14-20 and the rebase will hopefully be shortly after that. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The kernel-ark os-build branch has been rebased
As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 6.0 releases, and again with 6.1... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: What purpose does the redhat/Makefile "MARKER is" line serve?
On Thu, Jul 28, 2022 at 9:53 AM Prarit Bhargava wrote: > > $subject essentially. Does it actually serve any purpose. I know its > been there a long time but I'm not sure if it serves any actual purpose > anymore other than creating noise in the output. > > The line itself is output from redhat/genspec.py:176 and IMO can be > deleted but before I submit an MR I just want to make sure that there > isn't some obvious use of the data. > It is most useful at telling me when things have not worked out in the way I expected them to, either due to my error (forgetting to 'make dist-release') or other issues. I am not exactly sure what purpose the line was supposed to serve, but it has made me realize that what I was trying to build was incorrect on more than one occasion. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unable build kernel locally because command fedpkg mockbuild failed with error "Empty %files file /builddir/build/BUILD/kernel-5.19-rc8-17-g39c3c396f813/debugfiles.list"
On Wed, Jul 27, 2022 at 6:53 PM Mikhail Gavrilov wrote: > > Unable build kernel locally because command fedpkg mockbuild failed with > error "Empty %files file > /builddir/build/BUILD/kernel-5.19-rc8-17-g39c3c396f813/debugfiles.list" > > Full build log: https://pastebin.com/48ZYg3XQ > > I also tried build kernels which early build successfully, but now all build > ends with same error. > > For example "kernel-5.19.0-0.rc7.20220722git68e77ffbfd06.56": > https://pastebin.com/zgdEYuxR > > Looks like something broken in the "fedpkg mockbuild" :( This should be fixed now, it was an issue with "file" after the rebuild I think. It impacted most packages in rawhide. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
5.18.14 and fedora
I am not building 5,18.14 for Fedora, This is the upstream retbleed fix for stable. We have been carrying most of those patches since 5.18.11, and the last of them were picked up with the 5.18.13 build. The only thing in the upstream 5.18.14 build that is not in our 5.18.13 build is the version bump itself. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F37 and unfortunate timing (a heads up)
Fedora 37 does not branch from Rawhide until August 9th, and the 5.20 merge window will open up on August 1, that puts us in a bit of an odd situation. Fedora 37 will release on a 5.19 kernel because 5.20 is not expected to release before the final freeze begins. I don't think it would be wise to skip the daily builds through most of the merge window, so I plan to keep moving rawhide forward as usual. After the branch, I will move F37 back to a 5.19 kernel. Given this is a fairly unusual situation, it seemed worth sending out a heads up. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Tue, Jul 19, 2022 at 3:43 PM stan via kernel wrote: > > On Mon, 18 Jul 2022 11:57:08 -0700 > stan via kernel wrote: > > > Found the problem. There is a mismatch in the file name. > > The kernel should be looking for > > /usr/lib/systemd/libsystemd-core-251.3-1.fc37.so > > not > > /usr/lib/systemd/libsystemd-core-251-3-1.fc37.so > > Note the dash instead of a period in front of the 3 in the library > > name the kernel is searching for. Typo! > > Both the fedora stock 5.19 rc7 kernel and the locally built version > still fail in the same way. The error message from the stock kernel is > the same, except the text of the message is corrected to have a period > instead of a dash. The problem could be in something the > libsystemd-core library is calling, but I don't know how to get to > that. Or maybe the original error is completely unrelated, and the > error message is for a subsequent problem caused by the original error. > > What would be the way to get more information? > > > Resolving this will probably resolve all my issues. > > It seems I was foolishly optimistic. It sounds like you are not so far off. This doesn't seem to be a kernel issue at all though. To verify, take a known good kernel, save a copy of the initramfs for that one somewhere, and then regenerate the initramfs and try to boot it. I am guessing it will fail in the same way with a new initramfs. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Latest rawhide kernel, kernel-5.19.0-0.rc6.20220714git4a57a8400075.49.fc37.src.rpm, builds but won't boot
On Sun, Jul 17, 2022 at 4:17 PM stan via kernel wrote: > > On Sun, 17 Jul 2022 11:40:14 -0700 > stan wrote: > > > I'll be building the rc6 kernel with the new option enabled to see if > > that fixes things, but the kernel should still run even if the > > automatic mitigation is turned off. Should I open a bugzilla for > > this? > > I built a kernel with the automatic mitigation turned on, same behavior. > > I then commented out all the rtla related code in the spec file, and > turned off the mitigation, and still the same behavior. rtla is a binary for kernel-tools, it is a subpackage, and has no bearing at all on the running kernel, it is a userspace binary built separately. For Fedora, this part is built in the kernel-tools package. > The only other change I see is removing cpufreq.h from the headers, but > I don't think that would cause an error. Also a bit that would have no bearing on building a kernel, it is only used to build userspace utilities. > So, stumped. There were unfortunately some corner cases with retbleed mitigation that simply did not work. Most of those should have been worked out over the past week, but due to the way the embargo was done, there was a whole lot of testing that just couldn't happen before the code was merged. As this is your rebuild, the first thing I would do is see if the proper fedora build boots on this system, and I would not work with anything pre rc7 at this point. Doing so ensures that you are missing valid fixes. If the fedora build boots and your build does not, that is an interesting case to investigate. If the fedora build does not, that should be filed as a bug and figured out as 5.19 will be the F37 kernel. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any chance that the Intel ipu6-driver comes into the kernel?
On Tue, Jun 28, 2022 at 8:47 AM Dennis Pries wrote: > > Hi all, > currently the intel IPU6 based cameras are unsupported. This cameras are used > in the tiger lake and alder lake platforms. > > Ubuntu made changes to support them: > https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1921345 > > Are there any chance we can get support in Fedora too? Fedora doesn't build out of tree drivers. You might chime in on https://github.com/intel/ipu6-drivers/issues/22 to request a push. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Getting 'modpost: "cc_mkenc" [...] undefined!' when compiling out of tree kernel module
On Thu, Jun 9, 2022 at 3:39 AM Mauro Moltrasio wrote: > > Hi everyone, > > I'm new here so I'm sorry if this is not the right place to ask about this. > > I'm trying to build a kernel module based on this repo > https://github.com/stackrox/falcosecurity-libs/tree/master/driver using the > kernel header files for: > - 5.18.2-201.fc36.x86_64 > - 5.18.2-200.fc36.x86_64 > - 5.18.1-200.fc36.x86_64 > - 5.18.0-60.fc37.x86_64 Kernel-headers is somewhat misleading, The kernel-headers package is specifically for userspace, kernel-devel is the package required for building modules, but I assume that is what you are referring to since I never build kernel-headers for 5.18.1 or newer. > In all of them I'm getting an error like this: > ERROR: modpost: "cc_mkenc" [/scratch/module-src/1.1.0/collector.ko] undefined! > make[2]: *** [scripts/Makefile.modpost:134: > /scratch/module-src/1.1.0/Module.symvers] Error 1 > make[2]: *** Deleting file '/scratch/module-src/1.1.0/Module.symvers' > make[1]: *** [Makefile:1753: modules] Error 2 > make: *** [Makefile:16: all] Error 2 > > I think I've narrowed it down to the cc_mkenc function being defined in the > kernel files but not exported: > https://github.com/torvalds/linux/blob/6bfb56e93bcef41859c2d5ab234ffd80b691be35/arch/x86/coco/core.c#L99-L116 > > Does anyone know if this is something I'm only getting? Is there a work > around to get these builds working again? This was introduced in 5.18, and it would appear the cc_mkdec was exported as part of the API, but the cc_mkenc was not as there was no need with in tree code: https://github.com/torvalds/linux/commit/b577f542f93cbba57f8d6185ef1fb13a41ddf162 The path forward would require either a change in the out of tree module, or a patch to upstream to export the cc_mkenc. This might take some convincing. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora and the 5.18 kernel
The fedora-5.18 branch has not been created in the kernel-ark repository. The kernel test week for 5.18 will be June 5th - June 11th, and the rebase for Fedora 35 and 36 will be shortly after that, pending the results of test week. As Fedora 34 will already be EOL, it will not get a 5.18 rebase. For those wishing to track 5.18 via dist-git instead of kernel-ark, it will be maintained in the stabilization branch until the rebases happen. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The kernel-ark os-build branch has been rebased
As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 5.19 releases, and again with 5.20... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gcc: error: unrecognized command-line option '-mharden-sls=all'
On Thu, Apr 21, 2022 at 12:02 PM Sérgio Basto wrote: > > On Thu, 2022-04-21 at 11:50 -0500, Justin Forbes wrote: > > On Thu, Apr 21, 2022 at 8:58 AM Sérgio Basto wrote: > > > > > > Hi, > > > > > > to test Virtualbox host kmods on new kernel (x86_64 only), I install > > > fedora-rawhide-kernel-nodebug [1] > > > > > > but last two update I see with ack SLS [2] but SLS is strict arm > > > thing > > > , this is a bug ? or I'm missing something ? > > > > SLS is not a strict arm thing, and upstream commit e463a09af2f06 > > brought in the Straight Line Speculation mitigations for x86. Those > > are also enabled in 5.17 kernels as well. > > > > I assume you are running the rawhide-nodebug kernel on rawhide? If so, > > it should work, but it is entirely possible that the virtualbox > > drivers just do not build against the 5.18 development kernels yet. > > It would be best to ask them for support. If you are trying to build > > against the rawhide-nodebug kernel on a stable Fedora release, that > > will not work. You would need to rebuild the kernel first.. > > I'm using Fedora 34 , so you are saying that we need a higher gcc > version isn't it ? Actually, a newer compiler is not necessary. It would get you past this particular error, but you would just hit another error. The real issue is the compilter used to build the kernel must also be the compiler used to build the module. If you really need to run 5.18 kernels on Fedora 34, and need to build external modules for them, you will have to recompile the kernel yourself on an F34 host. Justin > after install kernel-devel , I need do some magic like: > > cd /usr/src/kernels/5.18.0-0.rc3.27.fc37.x86_64 > vi tools/objtool/Makefile > remove @$(CONFIG_SHELL) ./sync-check.sh from line 55 of > tools/objtool/Makefile > > rm scripts/basic/fixdep > rm scripts/mod/mk_elfconfig > rm tools/bpf/resolve_btfids//fixdep > rm tools/objtool/fixdep > make clean > make tools/objtool > make scripts > rm scripts/mod/modpost > make > > > > Justin > > > > > Thank you > > > > > > [2] > > > .config > > > 347:CONFIG_CC_HAS_SLS=y > > > 348:CONFIG_SLS=y > > > > > > [1] > > > dnf --disablerepo='*' --enablerepo=fedora-rawhide-kernel-nodebug > > > update > > > > > > > > > -- > > > Sérgio M. B. > > > ___ > > > kernel mailing list -- kernel@lists.fedoraproject.org > > > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > > > Do not reply to spam on the list, report it: > > > https://pagure.io/fedora-infrastructure > > > > -- > Sérgio M. B. > ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gcc: error: unrecognized command-line option '-mharden-sls=all'
On Thu, Apr 21, 2022 at 8:58 AM Sérgio Basto wrote: > > Hi, > > to test Virtualbox host kmods on new kernel (x86_64 only), I install > fedora-rawhide-kernel-nodebug [1] > > but last two update I see with ack SLS [2] but SLS is strict arm thing > , this is a bug ? or I'm missing something ? SLS is not a strict arm thing, and upstream commit e463a09af2f06 brought in the Straight Line Speculation mitigations for x86. Those are also enabled in 5.17 kernels as well. I assume you are running the rawhide-nodebug kernel on rawhide? If so, it should work, but it is entirely possible that the virtualbox drivers just do not build against the 5.18 development kernels yet. It would be best to ask them for support. If you are trying to build against the rawhide-nodebug kernel on a stable Fedora release, that will not work. You would need to rebuild the kernel first.. Justin > Thank you > > [2] > .config > 347:CONFIG_CC_HAS_SLS=y > 348:CONFIG_SLS=y > > [1] > dnf --disablerepo='*' --enablerepo=fedora-rawhide-kernel-nodebug update > > > -- > Sérgio M. B. > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] Redhat: enable Kfence on production servers
On Tue, Apr 19, 2022 at 7:48 AM Bruno Goncalves (via Email Bridge) wrote: > > From: Bruno Goncalves on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1748#note_916697510 > > @npache I used to bot to test this MR, but it failed to build for x86_64: > https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki- > trusted-contributors/-/jobs/2349465582 the failure doesn't seem related to the > MR though... It is indeed unrelated. You are attempting to build with a broken GCC. Ths bug was fixed with gcc-12.0.1-0.16 builds Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Wed, Apr 13, 2022 at 12:29 PM stan wrote: > > On Tue, 12 Apr 2022 15:23:47 -0500 > Justin Forbes wrote: > > > And now you see why kernel-headers is a separate package for Fedora, > > you can't build the tools without installed kernel headers from the > > same kernel. For a quick work around, install > > kernel-headers-5.18.0-0.rc2.git0.1.fc37 > > I'm also building the header package for the kernel at the same time as > the tools, and this has worked without issue before 5.18. That is, when > a new kernel version came out, I just built kernel, tools, and headers > as usual, and never had a problem. There must have been some change in > the build process with the introduction of 5.18. > > Thanks for the workaround. There is no change in the build process, this is just a thing that pops up from time to time during the merge window, not incredibly often. Basically the problem is a merge comes in for kernel tools which both adds something to a uapi header, and adds code in kernel-tools which uses that new thing. Because tools are using the userspace headers installed on the system, you are trying to build the 5.18 kernel tools using 5.17 kernel headers. In this case, it was upstream commit a1a5cfe70cd29 but this is not the first time it has happened. When building kernel-headers as a separate package, it becomes easy to build the new headers, which can then be installed to build kernel-tools. If you are building everything all together, you need to edit the spec to skip that failing tool, or turn off kernel-tools all together. Then you will get a kernel-headers package that you can install and build. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Tue, Apr 12, 2022 at 12:19 PM stan wrote:
>
> On Mon, 11 Apr 2022 10:53:54 -0500
> Justin Forbes wrote:
> > Coming soon to the kernel-ark repo, but the fix is easy in the spec:
> >
> > diff --git a/kernel.spec b/kernel.spec
> > index fb67ab956..515942496 100755
> > --- a/kernel.spec
> > +++ b/kernel.spec
> > @@ -2249,7 +2249,7 @@ chmod +x
> > tools/power/cpupower/utils/version-gen.sh %{make}
> > CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3" popd
> > pushd tools/arch/x86/intel_sdsi
> > - %{make}
> > + %{tools_make}
> > popd
> > %endif
> > %endif
>
> Thanks. That got me further, but I then hit another error.
>
> + popd
> + pushd tools/iio/
> + /usr/bin/make V=1 'HOSTCFLAGS=-O2 -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed
> -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
>
> -Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
> 'CFLAGS=-O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1
>
> -Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld'
> V=1
> iio_utils.c: In function 'iioutils_break_up_name':
> iio_utils.c:65:15: warning: implicit declaration of function 'asprintf'; did
> you mean 'vsprintf'? [-Wimplicit-function-declaration]
>65 | ret = asprintf(generic_name, "%s_%s", prefix, working);
> | ^~~~
> | vsprintf
> iio_event_monitor.c:71:10: error: 'IIO_EV_TYPE_MAG_REFERENCED' undeclared
> here (not in a function); did you mean 'IIO_EV_TYPE_MAG_ADAPTIVE'?
>71 | [IIO_EV_TYPE_MAG_REFERENCED] = "mag_referenced",
> | ^~
> | IIO_EV_TYPE_MAG_ADAPTIVE
> iio_event_monitor.c:71:10: error: array index in initializer not of integer
> type
> iio_event_monitor.c:71:10: note: (near initialization for 'iio_ev_type_text')
> iio_event_monitor.c: In function 'main':
> iio_event_monitor.c:353:23: warning: implicit declaration of function
> 'asprintf'; did you mean 'vsprintf'? [-Wimplicit-function-declaration]
> 353 | ret = asprintf(&chrdev_name, "/dev/iio:device%d",
> dev_num);
> | ^~~~
> | vsprintf
> make[1]: ***
> [/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/linux-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64/tools/build/Makefile.build:97:
> iio_event_monitor.o] Error 1
> make: *** [Makefile:48: iio_event_monitor-in.o] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.X2X12m (%build)
> Bad exit status from /var/tmp/rpm-tmp.X2X12m (%build)
And now you see why kernel-headers is a separate package for Fedora,
you can't build the tools without installed kernel headers from the
same kernel. For a quick work around, install
kernel-headers-5.18.0-0.rc2.git0.1.fc37
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Mon, Apr 11, 2022 at 8:58 AM stan via kernel
wrote:
>
> On Mon, 11 Apr 2022 07:23:39 -0500
> Justin Forbes wrote:
>
> > I am guessing this is because you turned on a build of kernel-tools
> > with it? libnl3 is only needed for kernel tools (the intel_sdsi build
> > is also kernel-tools only).
>
> Yeah, I build kernel-tools so that everything is aligned. But I have
> been building with kernel-tools all along without issue. Must be
> something new in 5.18 (this is my first build of a 5.18 kernel).
>
> > As to the issues with intel_sdsi, Today
> > would be the first fedora build, so I have not looked at what the
> > issues might be. It looks like it failed Friday for the same reason
> > in the ELN build though. I had not even checked, as the 5.17.2 builds
> > and the 5.16.19 builds and resulting activities kept me busy. Perhaps
> > Prarit might have some insight?
>
> I look forward to the analysis, and a fix. :-)
Coming soon to the kernel-ark repo, but the fix is easy in the spec:
diff --git a/kernel.spec b/kernel.spec
index fb67ab956..515942496 100755
--- a/kernel.spec
+++ b/kernel.spec
@@ -2249,7 +2249,7 @@ chmod +x tools/power/cpupower/utils/version-gen.sh
%{make} CFLAGS+="-D_GNU_SOURCE -Iinclude -I/usr/include/libnl3"
popd
pushd tools/arch/x86/intel_sdsi
- %{make}
+ %{tools_make}
popd
%endif
%endif
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.fc37.src.rpm fails to build locally
On Sun, Apr 10, 2022 at 3:35 PM stan via kernel wrote: > > Information. > > I'm building a custom kernel from the src.rpm tuned to my system. The > last 5.17 kernel built just fine. However, this 5.18 kernel fails with > the following error. > > + popd > + pushd tools/arch/x86/intel_sdsi > + /usr/bin/make V=1 'HOSTCFLAGS=-O2 -fexceptions -g -grecord-gcc-switches > -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 > -Wl,-dT,/home/stan/rpmbuild/BUILD/kernel-5.18-rc1-184-g1831fed559732b1/.package_note-kernel-5.18.0-0.rc1.20220408git1831fed559732b1.20.20220410.fc37.x86_64.ld' > /usr/bin/ld: /tmp/cc6wxoxI.o: relocation R_X86_64_32 against `.rodata.str1.1' > can not be used when making a PIE object; recompile with -fPIE > /usr/bin/ld: failed to set dynamic section sizes: bad value > collect2: error: ld returned 1 exit status > make: *** [Makefile:13: intel_sdsi] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.cIdvtt (%build) > Bad exit status from /var/tmp/rpm-tmp.cIdvtt (%build) > > I have the new option CONFIG_X64_X32_ABI disabled, and I am wondering > if it is related to that. I'm not sure why intel_sdsi is even being > processed, since I don't have an intel CPU, and have intel related > CONFIG options disabled in the kernel-local file. Is this an error in > the SPEC file? > > And a note. The rpmbuild -bp kernel.spec command ran without error, > but after I had configured the kernel-local file, and ran > rpmbuild -bb kernel.spec > it complained about a missing package, libnl3-devel. I would have > thought that would be picked up by the -bp command when it expanded the > source. Am I wrong, and this is normal behavior? I am guessing this is because you turned on a build of kernel-tools with it? libnl3 is only needed for kernel tools (the intel_sdsi build is also kernel-tools only). As to the issues with intel_sdsi, Today would be the first fedora build, so I have not looked at what the issues might be. It looks like it failed Friday for the same reason in the ELN build though. I had not even checked, as the 5.17.2 builds and the 5.16.19 builds and resulting activities kept me busy. Perhaps Prarit might have some insight? Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora kernel emails: too much or just right?
On Tue, Mar 22, 2022 at 1:24 PM Thorsten Leemhuis wrote: > > Hi Don! > > On 08.02.22 20:24, Donald Zickus wrote: > > > > It has been awhile since we changed how this mailing list is used. As > > folks have noticed, we have increased traffic significantly over the > > past couple of years to reflect the activity Red Hat developers are > > performing on the Fedora kernel. > > > > My question to this list is around the thoughts of this activity: > > * Is there too much noise? Should we throttle back? > > * is the volume ok? Folks have good filters? > > * Other suggestions on how we use this list? > > > > Trying to continue to make this mailing list useful. > > A mail Prarit Bhargava sent today ( > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/message/2FCAZG3H3Z65KPEDFXTGPVPIOYRVE322/ > ) to this list made me get back to this thread: > > I'm pretty sure Prarit didn't mean to, but both links in above mail are > not accessible to outsiders. :-/ And that made me realize something: I get that. I mean on the one hand, the original error did occur on things that not everyone has access to, but for people that did, it might be more help in figuring out the issue, but the pastebin should have been on https://pastebin.centos.org/. Even the original issue can be reproduced outside of the CKI environment, but honestly, I do understand that the time to reproduce the full output is considerably longer than a quick reproducer on pastebin. > kernel-ark and its mails here often make me feel like I'm back in the > days of Fedora Core and Extras, where Red Hat does one thing, while the > community is doing a different thing and having a hard time influencing > the thing done by Red Hat employees (back then that was because either > community members had no access or because it required a great deal of > effort to learn everything and stay on top of things). > > I known that this is unfair and inaccurate, as that's not how it is with > kernel-ark. But nevertheless it often just feels like that to me. I was there in those days, not a Red Hat insider, and I can assure you that kernel-ark is not there. There is some additional Red Hat ism due to the nature of how RHEL is developed, but I have worked pretty hard to make sure that it doesn't get in the way of actual Fedora kernels. I am 100% dedicated to Fedora, and while I am a Red Hat employee, it is very much Fedora first, I don't work on RHEL at all directly, once it leaves kernel-ark, or in the older days when RHEL branched from Fedora, I don't have anything to do with it. More importantly I feel like I have the support of management and others when I do push back because something goes against Fedora's interests. > Sorry. Maybe that's just me. Anyway: > > One thing that IMHO could help a lot to avoid that feeling on my side: > get rid of all the redhatisms. E.g. rename the redhat/ directory in > kernel-ark to fcrh/ (short for Fedora, CentOS, Red Hat), rpmification/, > a combination of those, or something like that -- just not "redhat" (and > maybe rename kernel-ark at the same time as well). Same for makes > targets. And make everything feel like kernel-ark is primary a > Fedora/community thing where CentOS/Red Hat are downstream consumers > that are closely involved because everyone benefits from it. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [PATCH v9 05/14] mm: multi-gen LRU: groundwork
On Mon, Mar 14, 2022 at 4:30 AM Yu Zhao wrote:
>
> On Mon, Mar 14, 2022 at 2:09 AM Huang, Ying wrote:
> >
> > Hi, Yu,
> >
> > Yu Zhao writes:
> > > diff --git a/mm/Kconfig b/mm/Kconfig
> > > index 3326ee3903f3..747ab1690bcf 100644
> > > --- a/mm/Kconfig
> > > +++ b/mm/Kconfig
> > > @@ -892,6 +892,16 @@ config ANON_VMA_NAME
> > > area from being merged with adjacent virtual memory areas due to
> > > the
> > > difference in their name.
> > >
> > > +# the multi-gen LRU {
> > > +config LRU_GEN
> > > + bool "Multi-Gen LRU"
> > > + depends on MMU
> > > + # the following options can use up the spare bits in page flags
> > > + depends on !MAXSMP && (64BIT || !SPARSEMEM || SPARSEMEM_VMEMMAP)
> >
> > LRU_GEN depends on !MAXSMP. So, What is the maximum NR_CPUS supported
> > by LRU_GEN?
>
> LRU_GEN doesn't really care about NR_CPUS. IOW, it doesn't impose a
> max number. The dependency is with NODES_SHIFT selected by MAXSMP:
> default "10" if MAXSMP
> This combined with LAST_CPUPID_SHIFT can exhaust the spare bits in page flags.
>
> MAXSMP is meant for kernel developers to test their code, and it
> should not be used in production [1]. But some distros unfortunately
> ship kernels built with this option, e.g., Fedora and Ubuntu. And
> their users reported build errors to me after they applied MGLRU on
> those kernels ("Not enough bits in page flags"). Let me add Fedora and
> Ubuntu to this thread.
>
> Fedora and Ubuntu,
>
> Could you please clarify if there is a reason to ship kernels built
> with MAXSMP? Otherwise, please consider disabling this option. Thanks.
>
> As per above, MAXSMP enables ridiculously large numbers of CPUs and
> NUMA nodes for testing purposes. It is detrimental to performance,
> e.g., CPUMASK_OFFSTACK.
It was enabled for Fedora, and RHEL because we did need more than 512
CPUs, originally only in RHEL until SGI (years ago) complained that
they were testing very large machines with Fedora. The testing done
on RHEL showed that the performance impact was minimal. For a very
long time we had MAXSMP off and carried a patch which allowed us to
turn on CPUMASK_OFFSTACK without debugging because there was supposed
to be "something else" coming. In 2019 we gave up, dropped that patch
and just turned on MAXSMP.
I do not have any metrics for how often someone runs Fedora on a
ridiculously large machine these days, but I would guess that number
is not 0.
Justin
> [1] https://lore.kernel.org/lkml/20131106055634.ga24...@gmail.com/
>
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
The kernel-ark os-build branch has been rebased.
As we have done since 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 5.18 releases, and again with 5.19... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora tarball names
On Mon, Mar 21, 2022 at 9:47 AM Prarit Bhargava wrote: > > While working on the Makefiles I've noticed that the tarball names are > different for Fedora vs CentOS/RHEL. > > Fedora uses an upstream based tarball version whereas CENTOS/RHEL use a > tarball version that is based off the RPM NVR. > > Simple question: Does Fedora *require* an upstream based tarball > version? It doesn't seem like one is necessary from the kernel.spec but > there might be other considerations to take into account. Indeed it does. For fedora, the tarball is only upstream content, and the patches are broken out into a separate patch file. This is a part of the Fedora packaging guidelines, and the clear delineation is important. We also do not want the additional information in the tarball as we use the same one for multiple Fedora releases, which do not use the same pkgrelease, but do share the same tarball in lookaside. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: generate config diffs when submitting config changes?
On Wed, Mar 2, 2022 at 7:11 AM Prarit Bhargava wrote: > > On 3/2/22 07:03, Dan Horák wrote: > > Hi, > > > > would it be possible for the gitlab automation to generate diffs for the > > "full" config files (kernel-$arch-*.config) when a MR is proposing > > config changes (updates in redhat/config/*)? I think it would help > > reviewing them, to see what are the effects of the proposed change(s) to > > the generated config files. > > > > Adding ptalbert & jarod. > > Y'know, I had this exact same thought a while ago. It would be nice if > we got a diff of the actual configs but I couldn't think of an easy way > to do it. > > It would require the webhooks to know about the "base" kernel build. > > The webhooks would have to 'make dist-configs' in the base tree or rip > the .configs from those rpms, and then compare them to the output of > 'make dist-configs' from the MR tree. > > That seemed really complicated so I didn't bother suggesting it. > Perhaps jarod or ptalbert may know of a better solution? This can be problematic as oftentimes MRs with config changes show up after other MRs with config changes have merged. The only meaningful way to see exactly what the diff would be for a given MR would be to check out the last commit before the new commits in the source branch, generate configs and copy them off somewhere, and then checkout HEAD again to generate the configs and diff them. It all has to be done on the source branch though, because the destination branch may have moved on considerably between the branching to create the MR and the time that the MR is actually submitted. I do agree that this would be quite useful. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora kernel emails: too much or just right?
On Mon, Feb 14, 2022 at 5:15 AM Thorsten Leemhuis wrote: > > On 12.02.22 06:21, Neal Gompa wrote: > > On Fri, Feb 11, 2022 at 11:25 AM Justin Forbes wrote: > >> On Fri, Feb 11, 2022 at 8:07 AM Thorsten Leemhuis > >> wrote: > >>> On 08.02.22 20:24, Donald Zickus wrote: > >>>> > >>>> It has been awhile since we changed how this mailing list is used. As > >>>> folks have noticed, we have increased traffic significantly over the > >>>> past couple of years to reflect the activity Red Hat developers are > >>>> performing on the Fedora kernel. > >>>> > >>>> My question to this list is around the thoughts of this activity: > >>>> * Is there too much noise? Should we throttle back? > >>>> * is the volume ok? Folks have good filters? > >>>> * Other suggestions on how we use this list? > >>>> > >>>> Trying to continue to make this mailing list useful. > >>>> > >>>> Thanks for any feedback! > >>> > >>> The mails are not a big problem for me, but they are related to a bigger > >>> question that again and again pops up in my head: > >>> > >>> Is it really a good idea to have all those totally RHEL specific patches > >>> in the Fedora rpm (and thus discussed here)? And does that approach mean > >>> that Red Hat is special, or are willing to include downstream patches > >>> for other distros as well? Say Amazon Linux? How is this handled in > >>> other packages? Or is it an issue that only happens with the kernel? > >> > >> It is a trade off, and I think one that tends to be worthwhile. The > >> patches that are included and discussed here also typically include > >> special casing with #ifdef CONFIG_RHEL_DIFFERENCES and the code path > >> does not actually impact Fedora kernel users. More importantly, those > >> patches are backed out on fedora stable branches, so they only exist > >> in Rawhide. > > Yeah, I'm glad that they are not in stable, thx for this. Still I'm not > really happy with the overall situation, as those patch increases the > patch count by quite a bit, which for me doesn't feel really in line > with our "we are close to upstream" claim -- and makes us look bad if > kernel developers, journalists and others count patches (I did that a > few times when I still wrote for a living -- and actually hope to write > an article about this sooner or later which takes a close look at how > various vendors patch their kernels). Patch count is really a marketing thing, that I am not particularly worried about. I am much more worried that the kernel we are building and running for Fedora behaves as similarly to upstream as possible. This is why having things like CONFIG_RHEL_DIFFERENCES does introduce additional code, but I think is an overall win because the Fedora kernel should be avoiding those codepaths all together. I can get problematic from the "apply this patch" to test a bug stance upstream, but given the locations for these, I expect actual conflict to be rare, and easy to fixup when it exists. > I'm not a git master, but would it maybe be possible to have those > patches in a separate branch and a separate %patch only applied for ELN? > Just wondering, as upstream development mostly happens with separate > branches, that's why I wonder why this can't be done here. But I fear > that things are slightly different in this case and might makes things > impossible in this case hard. Anyway: > This is possible, but it turns out to be a bit more of a nightmare to manage. The way it would be set up would be master is still the linus branch, a fedora-rawhide type branch would have to exist which merges in master regularly, and os-build would add the RHEL patches. Changing the spec to keep a linus tarball and separate patch sets for fedora and rhel, only applying the RHEL patch set if not fedora is trivial. What gets weird is from a maintainer or developer point of view. I would have to remember which branch to target my changes and it can get all very confusing, with different changes requiring different targets. > >> By including these and the process that brings them in to > >> begin with, we also get a much larger group of the RHEL kernel > >> developers, QA, etc paying attention to upstream and fixing issues > >> before they make it to a stable release. > > > >>> Sure, Fedora is mainly sponsored by Red Hat and all Fedora kernel > >>> developers are working for Red Hat, but somehow it feels to me like a > >>
Re: Fedora kernel emails: too much or just right?
On Fri, Feb 11, 2022 at 8:07 AM Thorsten Leemhuis wrote: > > [sending this a second time with a different "From" address to get it on > the list; sorry!] > > Lo! > > On 08.02.22 20:24, Donald Zickus wrote: > > > > It has been awhile since we changed how this mailing list is used. As > > folks have noticed, we have increased traffic significantly over the > > past couple of years to reflect the activity Red Hat developers are > > performing on the Fedora kernel. > > > > My question to this list is around the thoughts of this activity: > > * Is there too much noise? Should we throttle back? > > * is the volume ok? Folks have good filters? > > * Other suggestions on how we use this list? > > > > Trying to continue to make this mailing list useful. > > > > Thanks for any feedback! > > The mails are not a big problem for me, but they are related to a bigger > question that again and again pops up in my head: > > Is it really a good idea to have all those totally RHEL specific patches > in the Fedora rpm (and thus discussed here)? And does that approach mean > that Red Hat is special, or are willing to include downstream patches > for other distros as well? Say Amazon Linux? How is this handled in > other packages? Or is it an issue that only happens with the kernel? > It is a trade off, and I think one that tends to be worthwhile. The patches that are included and discussed here also typically include special casing with #ifdef CONFIG_RHEL_DIFFERENCES and the code path does not actually impact Fedora kernel users. More importantly, those patches are backed out on fedora stable branches, so they only exist in Rawhide. By including these and the process that brings them in to begin with, we also get a much larger group of the RHEL kernel developers, QA, etc paying attention to upstream and fixing issues before they make it to a stable release. > Sure, Fedora is mainly sponsored by Red Hat and all Fedora kernel > developers are working for Red Hat, but somehow it feels to me like a > boundary was overstepped. I can see that point of view, and I do understand it. There is a tradeoff involved. While it does mean some additional overhead in dealing with patches that do not impact Fedora, in return we do get some additional kernel dev attention when we run into real issues. I have been a Fedora kernel maintainer for a rather long time at this point, and I can tell you that it used to be easier to get help with issues from outside resources because everyone internally was busy and the Fedora tree was not included in their responsibility list. This has gotten considerably better since we moved to the ark process, because suddenly the ark tree is on people's responsibility list. While there is a defined workflow, there are improvements being made over time, and we are still looking at places the current process can be improved. This is why the thread was started. Is the mailing list interaction where it should be from an automation point of view? Are we sending too much? Not enough? Justin > Ciao, Thorsten > ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
On Sun, Feb 6, 2022 at 10:18 PM stan wrote: > > On Sun, 6 Feb 2022 15:25:28 -0600 > Justin Forbes wrote: > > > Always best to check kernel-ark's "include in releases" tag to find > > out if anything is required for it to build that haven't been merged > > yet because review was not finished: > > > > https://gitlab.com/cki-project/kernel-ark/-/merge_requests?scope=all&state=opened&label_name[]=Include%20in%20Releases > > > > There are 2 patches required to properly build with gcc 12, both have > > been submitted upstream. > > Thanks for both the information and the link. I'm not completely clear > on what is happening, but I think you added the patches manually to > build the 5.17 rc2 Fedora kernel so they are not in the src.rpm. I > would have to add them to the spec myself for the kernel 5.17 rc2 to > build properly with gcc 12. And once they are accepted upstream, they > will be included in the src.rpm. Is that correct? Oh, no, the patches are in the src rpm and dist-git, they just are not in the os-build branch of kernel-ark yet, which is what most people building custom kernels are working with. Apologies, I did not know you were working from the srpm. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Compiling a kernel from kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm fails if warnings as errors is turned on
On Sun, Feb 6, 2022 at 12:56 PM stan via kernel wrote: > > Hi, > > I'm on rawhide with latest updates, except for some that have package > version conflicts. But, the latest gcc and glibc packages. > > First, when I was configuring, (make menuconfig), even though it > said that sysfb and sysfb-simplefb were in /drivers/firmware, they > weren't there. They took the setting from the last 5.16 kernel config > that I used as a template. > > Then, when I tried to compile the 5.17 kernel from > kernel-5.17.0-0.rc2.20220204gitdcb85f85fa6f.86.fc36.src.rpm > it failed because I had warnings as errors, and the kernel warned about > ssh version being deprecated for openssl 3. e.g. > scripts/sign-file.c: In function 'read_private_key': > scripts/sign-file.c:142:17: warning: 'ENGINE_load_builtin_engines' is > deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] > 142 | ENGINE_load_builtin_engines(); > | ^~~ > > There were also warnings about an infinite recursion error on the > header files because of memcmp, memcpy and memset. This is puzzling to > me since the kernel compiled just fine in koji. Did it use different > header files? And aren't all header files protected from being read > more than once? Or are Fedora kernels compiled with warnings as errors > turned off? e.g. > ./include/linux/fortify-string.h:269:16: note: in expansion of macro > '__underlying_memcmp' > 269 | return __underlying_memcmp(p, q, size); > |^~~ > In file included from ./include/linux/string.h:253, > from ./include/linux/bitmap.h:11, > from ./include/linux/cpumask.h:12, > from ./arch/x86/include/asm/cpumask.h:5, > from ./arch/x86/include/asm/msr.h:11, > from ./arch/x86/include/asm/processor.h:22, > from ./arch/x86/include/asm/timex.h:5, > from ./include/linux/timex.h:65, > from ./include/linux/time32.h:13, > from ./include/linux/time.h:60, > from ./include/linux/stat.h:19, > from ./include/linux/module.h:13, > from init/do_mounts.c:2: > ./include/linux/fortify-string.h: In function 'strncpy': > ./include/linux/fortify-string.h:51:24: warning: infinite recursion detected > [-Winfinite-recursion] >51 | __FORTIFY_INLINE char *strncpy(char *p, const char *q, > __kernel_size_t size) > |^~~ > > When I turned off warnings as errors, the kernel compiled successfully. > This is not a problem in the 5.16 series, they compile cleanly with > warnings as errors turned on. > > Anyway, I am attaching the error output from the attempt with warnings > as errors. Always best to check kernel-ark's "include in releases" tag to find out if anything is required for it to build that haven't been merged yet because review was not finished: https://gitlab.com/cki-project/kernel-ark/-/merge_requests?scope=all&state=opened&label_name[]=Include%20in%20Releases There are 2 patches required to properly build with gcc 12, both have been submitted upstream. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Test Week] Fedora Linux Kernel 5.16 2022-01-23 through 2022-01-29
On Wed, Jan 26, 2022 at 3:38 AM Thorsten Leemhuis wrote: > > Lo! > > On 20.01.22 09:38, Sumantro Mukherjee wrote: > > > > I would like to invite all of you to participate in the Kernel 5.16 > > Test week is happening from 2022-01-23 to 2022-01-29. It's > > fairly simple, head over to the wiki [0] and read in detail about the > > test week and simply run the test case mentioned in[1] and enter your > > results. > > [...] > > [0] https://fedoraproject.org/wiki/Test_Day:2022-01-23_Kernel_5.16_Test_Week > > [1] https://testdays.fedoraproject.org/events/126 > > [2] https://badges.fedoraproject.org/badge/science-kernel-tester-i > > Wouldn't it be better for everyone if stable pre-releases would be > offered for testing in these test weeks, *if* they are available at that > time? I was just wondering that, as according to your [0] it seems that > 5.16.2 is still being tested currently, but 5.16.3 is up for review > already since Monday -- with more that 1000 changes: > https://lore.kernel.org/stable/20220124184125.121143...@linuxfoundation.org/ > > [note, there are newer pre-releases for 5.16.3 already] > > These changes might fix a few bugs testers otherwise might run into > without need -- or introduce new bugs that thus can be found and fixed > before 5.16.y hits updates-testing. I do create test builds for stable rc kernels usually, but they are scratch builds and not secure boot signed. With the time it takes for full kernel builds, and then the time to spin new ISOs, etc. I would never get feedback in time for a stablerc before the kernel is released. And with 5.15 and 5.16, the early stable's often have more than 1 rc release. For most of the 5.15 test week, we were iterating over rcs to get 5.15.3 out because of an issue that would impact many/most users, which was a regression from 5.15.2. We knew about this issue, but having it as a test week kernel would have lost a lot of meaningful feedback because many testers would hit the known bug and stop testing. > I bring this up, as situations like happened a few times already, as > Greg often merges a big bunch of changes in the first two weeks after a > mainline rc1 is out (see https://lwn.net/Articles/863505/ ) -- and > that's usually the time when the kernel test week happens. > > Ciao, Thorsten > > P.S.: kernel.spec until a few years had some code that made building > stable rcs easy, but it was removed (and likely won't work well the the > ask based kernel.spec anyway). There are still a couple of ways to go about it. If you just want to deal with dist-git and the stable-queue quilt trees, it is pretty simple to cat the patches (in series order) to a patch file and apply that patch before the redhat patch. For kernel ark with the source tree, there are still some issues with the scripts that I need to fix up to handle a stable rc. Right now, the logic expects either an rc or a stable. I will try to get that done as we get further in the 5.17 cycle. It is still possible, and pretty easy to build a stable rc with a caveat. An example workflow for building the 5.16.3-rc2 stable kernel (this expects you have local branches for both stable/linux-5.16.y and stablerc/linux-5.16.y as linux-5.16.y-rc). 1) Update linux-5.16.y, linux-5.16.y-rc, and fedora-5.16 branches 2) In fedora-5.16 'git merge linux-5.16.y-rc' and fix any merge issues if they appear 3) git revert Greg's latest commit which actually changes the version to 5.16.3-rc2 (this chokes up our scripts). From there you can build as you typically would. The kernel is still versioned as 5.16.2, so I tend to specify the release to match the rc number, but that is personal preference. Once I get the scripts fixed, we won't need to revert the version patch, and the spec should be versioned correctly. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The kernel-ark os-build branch has been rebased.
As we did with 5.15, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 5.17 releases, and again with 5.18... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: FYI: dracut needs some changes for 5.17
On Mon, Dec 20, 2021 at 7:51 AM Hans de Goede wrote: > > Hi All, > > As you may have already seen, dracut needs some changes for 5.17: > https://hansdegoede.livejournal.com/25948.html > > The necessary changes have landed in dracut's upstream git; and > I've just started a build of dracut for rawhide with the patch > added. > > So until we start pushing 5.17 to F34 / F35 we are are good, > the main purpose of this mail is to remind people to not forget > to sync dracut with rawhide when we start testing the 5.17 > kernels on F34/F35. Thanks for the heads up, I have added a note to redhat/rebase-notes.txt to remind me to check on the status as we start pushing 5.17. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: depmod exits with error needs unknown symbol when I build kernel with upstream patch
On Sun, Dec 5, 2021 at 12:18 PM Mikhail Gavrilov
wrote:
>
> Hi!
> Usually for testing upstream patches I could easily include patch to spec
> file.
>
> For example:
> %if !%{nopatches}
>
> Patch1: patch-%{patchversion}-redhat.patch
> + Patch2: nct6775.diff
> %endif
>
> %if !%{nopatches}
>
> ApplyOptionalPatch patch-%{patchversion}-redhat.patch
> + ApplyOptionalPatch nct6775.diff
> %endif
>
> But today I ran into an error for the first time:
>
> + echo 'Depmod failure'
> + cat depmod.out
> Depmod failure
> depmod: WARNING:
> /builddir/build/BUILDROOT/kernel-5.15.6-200.fc35.x86_64/./lib/modules/5.15.6-200.fc35.x86_64+debug/kernel/drivers/hwmon/nct6775.ko
> needs unknown symbol wmi_evaluate_method
> + exit 1
>
This makes sense because you are changing that module and need to add
it to filter-modules.sh.fedora
Just append nct6775 to the singlemods= line.
Justin
> I don’t know how to fix it.
>
> Full build log is here: https://pastebin.com/T3bLWFEd
> Here is topic with patch: https://bugzilla.kernel.org/show_bug.cgi?id=204807
> ___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
The kernel-ark os-build branch has been rebased.
If you have a pending merge request, you will need to rebase your source tree and force push so that things will cleanly merge. As we did with 5.14, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 5.16 releases, and again with 5.17... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The kernel-ark os-build branch has been rebased.
If you have a pending merge request, you will need to rebase your source tree and force push so that things will cleanly merge. As we did with 5.13, we have done this again for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 5.15 releases, and again with 5.16... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rawhide non-debug kernel is debug-kernel config ?
On Mon, Aug 2, 2021 at 3:59 PM Joel Wirāmu Pauling wrote: > > Understood; app streams would enable this as you can tag versions and > collections of packages so would be easy to have a default of say the > nodebug module of the kernel be the default appstream in rawhide and also > provide a nodebug variant as a appstream module. > > Likewise for headers/tools etc. > > This would also make it easier to provide rawhide kernels in stable ; I > guess in my view the appstream/modules is the 'right' way to do the kernel > as it would solve for most of the existing usecases within an existing > capability of package management. This is not so easy as it sounds, yes, you can install and boot a rawhide kernel in stable Fedora version. No, it will not function as expected. Anyone running a 3rd party module would be unable to build that module because the compiler versions are typically different. Toolchain matters. > Historically the pushback seems to have been 'but we already have a > weird way of doing the kernel' likewise for glibc and python. This seems > like a bit of a weird argument. Push back is it would imply some level of support, which is not possible to offer. Justin > On Tue, 3 Aug 2021 at 00:27, Justin Forbes wrote: > > > On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling wrote: > > > > > > Just my 0.2$ - I run rawhide on most of my systems. The last couple of > > weeks the no-debug kernel ( > > https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/$basearch/) > > repo has not been appearing to be built as usual. Resulting primarily for > > me in my Optimus/NVIDIA blobs failing > > > > > > > For the past year or so, the rawhide no-debug repo is only getting > > updated on the rc build, as these are secure boot signed, and there is > > not a way to sign the other builds that were going there. It is > > currently on kernel-5.14.0-0.rc3.29.fc35.x86_64.rpm, which is the > > latest no-debug kernel available until the rc4 build finishes today. > > > > > I agree the situation is confusing as it is. Would much prefer some > > other way of handling other than having to add a repo in addition to base. > > > > > > I've previously argued that we should be using appstreams for the > > kernel, and this, to me seems as good a reason as any to potentially > > investigate that approach. > > > > > > On Mon, 2 Aug 2021 at 21:08, Hans de Goede wrote: > > >> > > >> Hi, > > >> > > >> On 7/29/21 2:44 PM, Justin Forbes wrote: > > >> > On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede > > wrote: > > >> >> > > >> >> Hi All, > > >> >> > > >> >> Every now and then I sync the .config for the kernels which I build > > locally > > >> >> with the Fedora kernel's .config . > > >> >> > > >> >> After downloading > > kernel-core-5.14.0-0.rc3.20210728git7d549995d4e0.31.fc35.x86_64.rpm > > >> >> and extracting the /lib/modules/5/config file I noticed that all > > the debug > > >> >> options seem to be enabled. > > >> >> > > >> >> AFAIK those should only be enabled for the kernel-debug-core variant > > ? > > >> >> So this seems to be a bug. > > >> >> > > >> > > > >> > This is incorrect, and has never been the case for rawhide, or at > > >> > least not in the last 10 years. For rawhide, the first build of any > > >> > given rc is built as a release kernel with separate debug kernels. > > >> > Any "git snapshot" kernel is built as a debug kernel only. For > > >> > example, kernel-5.14.0-0.rc3.29.fc35 has both debug and nondebug > > >> > variants built, but > > >> > kernel-5.14.0-0.rc3.20210728git7d549995d4e0.31.fc35 only has debug > > >> > kernels. In the past, we did not even have a subpackage named > > >> > kernel-debug, but not too long ago, some people asked that we create a > > >> > meta package so that people who only wanted to run debug kernels could > > >> > keep kernel-debug installed, and it would always point to the correct > > >> > option. This was MR > > >> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1133 > > >> > > >> Ah, that is what was causing my confusion since there are now > > >> both a kernel-core-5... and a kernel-debug-core-5... pkgs in > > >> rawhide I a
Re: Rawhide non-debug kernel is debug-kernel config ?
On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling wrote: > > Just my 0.2$ - I run rawhide on most of my systems. The last couple of weeks > the no-debug kernel > (https://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/$basearch/) > repo has not been appearing to be built as usual. Resulting primarily for me > in my Optimus/NVIDIA blobs failing > For the past year or so, the rawhide no-debug repo is only getting updated on the rc build, as these are secure boot signed, and there is not a way to sign the other builds that were going there. It is currently on kernel-5.14.0-0.rc3.29.fc35.x86_64.rpm, which is the latest no-debug kernel available until the rc4 build finishes today. > I agree the situation is confusing as it is. Would much prefer some other > way of handling other than having to add a repo in addition to base. > > I've previously argued that we should be using appstreams for the kernel, and > this, to me seems as good a reason as any to potentially investigate that > approach. > > On Mon, 2 Aug 2021 at 21:08, Hans de Goede wrote: >> >> Hi, >> >> On 7/29/21 2:44 PM, Justin Forbes wrote: >> > On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede wrote: >> >> >> >> Hi All, >> >> >> >> Every now and then I sync the .config for the kernels which I build >> >> locally >> >> with the Fedora kernel's .config . >> >> >> >> After downloading >> >> kernel-core-5.14.0-0.rc3.20210728git7d549995d4e0.31.fc35.x86_64.rpm >> >> and extracting the /lib/modules/5/config file I noticed that all the >> >> debug >> >> options seem to be enabled. >> >> >> >> AFAIK those should only be enabled for the kernel-debug-core variant ? >> >> So this seems to be a bug. >> >> >> > >> > This is incorrect, and has never been the case for rawhide, or at >> > least not in the last 10 years. For rawhide, the first build of any >> > given rc is built as a release kernel with separate debug kernels. >> > Any "git snapshot" kernel is built as a debug kernel only. For >> > example, kernel-5.14.0-0.rc3.29.fc35 has both debug and nondebug >> > variants built, but >> > kernel-5.14.0-0.rc3.20210728git7d549995d4e0.31.fc35 only has debug >> > kernels. In the past, we did not even have a subpackage named >> > kernel-debug, but not too long ago, some people asked that we create a >> > meta package so that people who only wanted to run debug kernels could >> > keep kernel-debug installed, and it would always point to the correct >> > option. This was MR >> > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1133 >> >> Ah, that is what was causing my confusion since there are now >> both a kernel-core-5... and a kernel-debug-core-5... pkgs in >> rawhide I assumed (going by the name) that rawhide was now >> always doing normal + debug builds like how the build for >> the released Fedora versions are done (assuming I got >> that right). Thank you for explaining this. >> >> I must say that this rawhide now having both >> kernel-core-5... and a kernel-debug-core-5... pkgs, but the >> kernel-core-5... pkgs sometimes being debug builds and sometimes >> not is quite confusing. >> >> I was aware that rawhide was doing the debug-builds except for the >> first-build of any rc thing, but that was before the merge-req which >> you point to which introduces having both kernel-core-5... and >> kernel-debug-core-5... pkgs, like the released branches have. >> >> If we're going to do that would it then not be more consistent >> (and simpler in the spec file?) to always to a debug + non-debug >> build in rawhide like how we are doing for the released branches ? >> It would certainly be simpler, yes, but the purpose of running those debug builds is to force testing with those debug options. We have made an effort to ensure that the most invasive debug options are kept off, but over the years, this additional testing has helped uncover issues that can be addressed before things hit a stable kernel release. If we built both release and debug kernels, everything would default to the release, and we would not get that same testing. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Rawhide non-debug kernel is debug-kernel config ?
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede wrote: > > Hi All, > > Every now and then I sync the .config for the kernels which I build locally > with the Fedora kernel's .config . > > After downloading > kernel-core-5.14.0-0.rc3.20210728git7d549995d4e0.31.fc35.x86_64.rpm > and extracting the /lib/modules/5/config file I noticed that all the debug > options seem to be enabled. > > AFAIK those should only be enabled for the kernel-debug-core variant ? > So this seems to be a bug. > This is incorrect, and has never been the case for rawhide, or at least not in the last 10 years. For rawhide, the first build of any given rc is built as a release kernel with separate debug kernels. Any "git snapshot" kernel is built as a debug kernel only. For example, kernel-5.14.0-0.rc3.29.fc35 has both debug and nondebug variants built, but kernel-5.14.0-0.rc3.20210728git7d549995d4e0.31.fc35 only has debug kernels. In the past, we did not even have a subpackage named kernel-debug, but not too long ago, some people asked that we create a meta package so that people who only wanted to run debug kernels could keep kernel-debug installed, and it would always point to the correct option. This was MR https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1133 Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: f34 on J1900D2Y (quad-core Celeron) mobo: kernel <= 5.12.15, OK; kernel >= 5.12.17, 5.13.4, slow boot (>> 660 secs) until FAIL/hang ?
On Thu, Jul 22, 2021 at 10:00 AM PGNet Dev wrote: > > Found 'vanilla kernels' for Fedora, > > https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories > > https://repos.fedorapeople.org/repos/thl/kernel-vanilla-stable/fedora-34/x86_64/ > > Installed from repo > > kernel-5.13.4-250.vanilla.1.fc34.x86_64.rpm > kernel-devel-5.13.4-250.vanilla.1.fc34.x86_64.rpm > kernel-modules-extra-5.13.4-250.vanilla.1.fc34.x86_64.rpm > kernel-core-5.13.4-250.vanilla.1.fc34.x86_64.rpm > kernel-modules-5.13.4-250.vanilla.1.fc34.x86_64.rpm > > then, re-gen'd init & re-booted > > Same issue as above ... long/slow boot, eventual hang. > > Again, drop back to 5.12.15, all's good. Are you sure this isn't another case of the dracut/dbus bug that has been hitting everyone for a few weeks now? 5.12.16+ was roughly the timeline that it hit. https://bugzilla.redhat.com/show_bug.cgi?id=1976653 Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel 5.14 spec file problems, one solved, one unresolved, help
On Wed, Jul 7, 2021 at 2:40 PM stan via kernel wrote: > > On Wed, 7 Jul 2021 10:04:07 -0700 > stan via kernel wrote: > > > On Wed, 7 Jul 2021 10:21:01 -0500 > > Justin Forbes wrote: > > > > > > > > bpftool is a builreq, the failure there has to do with where you are > > > building it. You need bpftool from 5.13 to build a 5.14 snapshot. > > > The error is unclear, but that is the solution. This is actually a > > > very useful bit in that we will use that vmlinux.h to build > > > kernel-tools for Fedora. It is built in kernel for ELN. As I > > > rebase stable Fedora to 5.13, it will require a prebuild of > > > kernel-tools for 5.13 followed by the kernel build. > > > > I have bpftool-5.13.0-1.fc35.x86_64 installed, and that seems to have > > satisfied the buildrequire. I am also building perf, tools, > > headers, and devel, so that everything is in sync with the custom > > kernel. That used to work fine as late as 5.10 kernels. So, my > > takeaway is that this has changed, and I now need to enable the build > > of vmlinux.h. > > > > The error message I received was that bpftool could not find BFT. I > > infer from your response that turning on the build of bpf will remedy > > that. > > It doesn't. Here is the output of a compile with bpf turned on > everywhere. It shows the creation of the link that causes the problem > of an upackaged file being packaged, and then the failure to build > vmlinux.h using bpftool. > > + cp certs/signing_key.pem certs/signing_key.pem.sign > + cp certs/signing_key.x509 certs/signing_key.x509.sign > + mkdir -p > /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/usr/src/kernels > + mv > /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/lib/modules/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/build > > /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64//usr/src/kernels/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64 > + ln -sf > /usr/src/kernels/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64 > /home/stan/rpmbuild/BUILDROOT/kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/lib/modules/5.14.0-0.rc0.20210706git79160a603bdb.11.20210706.fc35.x86_64/build > + bpftool btf dump file vmlinux format c > Error: failed to load BTF from vmlinux: No such file or directory > error: Bad exit status from /var/tmp/rpm-tmp.Zt6DVC (%build) > Bad exit status from /var/tmp/rpm-tmp.Zt6DVC (%build) > > I have debug builds turned off. Are they required for bpftool to work? No, BTF debuginfo is set on regular kernels as well. Are you building this on a rawhide system? My build/test system here is F34, but with bpftool-5.13.0-1.fc35.x86_64 (rebuilt against F34) it seems to pass fine on this. I got the same error that you did when I was running an older version of kernel-tools. In your particular user case though, you can comment out that line. The vmlinux.h created there is only used in 2 instances, where kernel-tools is built separately from the kernel, and when cross compiling the kernel (because tools have to be built native). Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: kernel 5.14 spec file problems, one solved, one unresolved, help
On Wed, Jul 7, 2021 at 9:41 AM stan via kernel wrote: > > Hi, > I'm building the 5.14 kernel from > kernel-5.14.0-0.rc0.20210706git79160a603bdb.11.fc35.src.rpm > I've run into two issues. > > The first is to do with bpftool. I see in the comments that it is > supposed to be disabled in Fedora. But, it still has a buildrequires:, > and there is a segment of code that is not protected even if bpftool is > turned off. > > %ifnarch armv7hl > # Generate vmlinux.h and put it to kernel-devel path > bpftool btf dump file vmlinux format c > > $RPM_BUILD_ROOT/$DevelDir/vmlinux.h > %endif > > Because bpftool is turned off, this chokes. bpftool is a builreq, the failure there has to do with where you are building it. You need bpftool from 5.13 to build a 5.14 snapshot. The error is unclear, but that is the solution. This is actually a very useful bit in that we will use that vmlinux.h to build kernel-tools for Fedora. It is built in kernel for ELN. As I rebase stable Fedora to 5.13, it will require a prebuild of kernel-tools for 5.13 followed by the kernel build. > > The second is to do with a symbolic link. > > > # Move the devel headers out of the root file system > mkdir -p $RPM_BUILD_ROOT/usr/src/kernels > mv $RPM_BUILD_ROOT/lib/modules/$KernelVer/build $RPM_BUILD_ROOT/$DevelDir > > # This is going to create a broken link during the build, but we don't use > # it after this point. We need the link to actually point to something > # when kernel-devel is installed, and a relative link doesn't work across > # the F17 UsrMove feature. > ln -sf $DevelDir $RPM_BUILD_ROOT/lib/modules/$KernelVer/build > > The comment says that symbolic link should not matter, but rpmbuild > complains that files are being packaged that are not registered (?, > from memory). Building something else right now, but if you need the > exact error message, I can regenerate it later. This code is in > prior kernel spec files without problems. It seems that something > is being more assiduous now. I've tried various things to work around > this, but they haven't worked. I guess that is because I don't really > understand why this symbolic link is being created. What is your > suggestion for how to fix this? Would need to know what link this is. I know perf messed up the makefile and created a link in the wrong place. We don't package this link, but our command to remove it wasn't looking in the right place. Rather than fix this in spec, I sent a fix upstream which is applied and waiting for the next Linus perf pull. https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1237 but you shouldn't be hitting that at all if you are doing a fedora build which doesn't build perf. If it isn't that, let me know what it actually is, since I am not seeing it in rawhide builds. > Finally, I've built the kernel successfully several times while testing > my fixes. I've noticed that ccache is not being used; it is rebuilding > everything every time. Since I'm building a kernel customized to my > hardware, that isn't so onerous. But, how would I enable ccache so > that rebuilds are basically copy operations? > For building rpms, I am not sure here. When I am debugging and testing non packaging related fixes, I tend to just build manually in the kernel tree. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Kernel-ark os-build branch has been rebased
On Tue, Jun 29, 2021 at 7:35 AM Thorsten Leemhuis wrote: > > Lo! > > On 28.06.21 22:10, Justin Forbes wrote: > > If you have a pending merge request, you will need to rebase your > > source tree and force push so that things will cleanly merge. > > > > While this is the first time we have done this for os-build, we expect > > to keep it up as a cadence with every upstream release. This means we > > will do it again when 5.14 releases, and again with 5.15... […] > > BTW, does anyone occasionally review the patches to check which ones > still need to be upstreamed or maybe can be dropped? To me it looks like > it would be a good idea after a quick review: > We don't have a specific schedule to do so. It has been done in the past, but it ends up being pretty random. I think it has been a couple of years at this point. It would be good to do so on a more regular basis. Perhaps every 5 upstream releases? > I looked at > > https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/Patchlist.changelog > > and randomly picked one that didn't look like it was RHEL specific. It > was this one: > > https://gitlab.com/cki-project/kernel-ark/-/commit/5ef51389cf6673a0e9e004909c7be1dc785050b2 > > Looks to me like it was never merged upstream: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/hid/hid-rmi.c > > For a quick search it looks like things stalled here: > https://lore.kernel.org/lkml/20170331085751.gf22...@mail.corp.redhat.com/ > > > Funnily enough it seems that patch was fixing a regression I ran into > myself back in 2017 (yes, I really picked that patch from the list > nearly at random; I can't even remember that regression). But seems it > was fixed somewhere/somehow/somewhen, because until recently I regular > used the particular XPS13 with vanilla kernels and never noticed any > touchpad problems (I can recheck the dmesg output if anyone is > interested, I still have access to the machine occationally). > > Okay, it was good/bad luck that I immediately picked one that looks > obsolete, but it IMHO clearly shows that revisiting the patches every > now and them might be good idea, which made me write this mail. Don#t > known, maybe even some kind of policy like "after one/two years somebody > has to vouch for a patch, otherwise it gets dropped" might be a good idea? > > Side note: All those RHEL-only patches make it look like the Fedora > kernel is quite a bit modified, which might be bad for Fedora's > reputation. If they really have to be there (do they?), can't they at > least be marked more clearly? Maybe when generating Patchlist.changelog > add "RHEL-only: " to the description if the commit message contains > "RHEL-only"? > That makes it a bit more difficult because we generate the patch list with a simple git log output, and don't actually look at the entire commit message. Also, some of them are not clearly labelled. Most of those patches are simple support housekeeping such as marking specific hardware as deprecated and the like. I do drop all of those RHEL specific patches when I do the rebases on fedora-5.x branches so they are not carried in Fedora stable releases at all. I maintain a list of them so that I can drop them when we rebase to create those branches. It might be good to add that list to the redhat directory. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Kernel-ark os-build branch has been rebased
If you have a pending merge request, you will need to rebase your source tree and force push so that things will cleanly merge. While this is the first time we have done this for os-build, we expect to keep it up as a cadence with every upstream release. This means we will do it again when 5.14 releases, and again with 5.15... It is difficult to manage a regularly rebased tree, because any outstanding MR is invalidated and has to also be rebased. But not doing somewhat regular rebases can also be difficult in the spirit of the openness that Fedora is based upon. While there are plenty of ways to see which patches we carry compared to upstream, some of those patches are fairly old, and would not apply cleanly at all to a modern tree after several releases were merged in with them. As we have gotten into a flow of things with merge requests, we can get to the point of very few outstanding MRs towards the end of a release cycle, and that makes it an opportune time to rebase the tree. This also means that the patches we carry should be no more than 1 release out of date, making them easier to apply to various other trees. I do realize that this is a minor inconvenience every 2-3 months, but I believe the results are worth it. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
The 5.13 kernel and Fedora
With 5.13 having been officially released, we will work towards the typical path of stabilizing 5.13 for rebases. This means a test week in about 2 weeks, and Fedora 33 and 34 will rebase to a 5.13 kernel shortly after the test week, depending on the feedback we get.I have created a branch in the kernel-ark repository where 5.13 will be maintained. I am accepting merge requests into the fedora-5.13 branch right now. Unfortunately, that branch is not properly buildable until 5.13.1 is released. At some point I should update our scripts to be a bit more flexible. Also of note, the os-build branch has been fully rebased on top of 5.13 so that our patches are not so out of date. More information on that will follow shortly, but do not be surprised when a simple git pull will not work. Thanks, Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2] configs: enable CONFIG_LEDS_BRIGHTNESS_HW_CHANGED
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1169#note_598017347 Acked-by: Justin Forbes (via approve button) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] [redhat] perf: enable CoreSight support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1167#note_596781310 Acked-by: Justin Forbes (via approve button) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] [redhat] perf: enable CoreSight support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1167#note_596780470 > I prefer cutting this down to be arm-specific and "trade the spec file complexity", since I see no reason for x86 (and other arch) customers (which I believe is a majority) to install completely useless packages. This is valid. I wasn't thinking about the dep on install, only the build side. As I didn't make the original change in Fedora, I was just verifying that we had this functionality and saw how it was put in. > A better question is, whether linking opencsd would allow the x86 users to e.g. analyse the coresight trace from perf.data obtained on aarch64. In such case, it would make sense. I would have to look at the code to see, or Fedora has been built this way for about a year, so any existing Fedora perf package should be a valid way to test. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_596135080 > is it worth throwing a 'include in release' label and seeing if this can build in eln? I have tagged it with "include in release" and done a test build with it against ELN koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=69629902 The test build was successful, though I can't boot it anywhere to verify that it is working as intended. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595919862 > glibc 2.34 will detect `-march=z14` and refuse to run on z13 or earlier, to avoid hard-to-diagnose crashes later. We learned the hard way that this very desirable during the ppc64le bringup. Would it still detect this if the kernel running in the build root is a z13 kernel? There are kernel advantages to limiting supported hardware, but z13 added the vector bits, I don't recall z14 adding much instruction wise, so perhaps there is no benefit to building userspace with z14? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595910611 > do we know which s390x machines ELN builds on? The koji builders are Z13. They are running a Fedora kernel to do the build, so the 5.13-rc5 eln build was done in koji running 5.12.8-300.fc34. These tend to be updated regularly with Fedora, but we do not plan to set to Z14 in Fedora. Of course the build root is running eln userspace packages, so we would need to ensure that nothing in userspace requires Z14, or it will fail. I don't recall Z14 adding a bunch of new instructions, so this might not be an issue. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] [redhat] perf: enable CoreSight support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1167#note_595825564 Curious on this, as Fedora has been building with CORESIGHT for a bit now (since July 2020). We did not case the changes on arch, and simply added openscd-devel as a buildreq for everyone and pass CORESIGHT=1 to perf_make. This builds fine across all arches, even though it is unnecessary. As coresight is an arm specific thing, it is really only used in arch/arm/util/ files and shouldn't be a problem for other architectures. Which makes me ask, do we trade spec complexity for more specific build command line, or do we go the simple spec route and expect it to continue working? ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2 0/0] kernel.spec: tools: sync with RHEL 8
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1155#note_595488507 We have been building with it here since rc4. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH 0/0] [redhat] New configs in drivers/hwtracing
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1085#note_592234983 Acked-by: Justin Forbes (via approve button) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] all: Changing CONFIG_UV_SYSFS to build uv_sysfs.ko as a loadable
On Thu, Jun 3, 2021 at 8:22 AM Prarit Bhargava (via Email Bridge) wrote: > > From: Prarit Bhargava on gitlab.com > https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1165#note_592074102 > > Would it hurt to switch Fedora to "is not set" with a note to THIS MR so we > can point to this simple discussion in the future? > > Just a thought. Fedora already "is not set" so there is nothing to change there. I don't have an issue with a note being added, and honestly I am not too concerned with what HPE supports. If we have users requesting it be turned on because they feel like experimenting, I can turn it on. I just haven't had anyone ask, and assume no one is wanting to run Fedora in this environment. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] all: Changing CONFIG_UV_SYSFS to build uv_sysfs.ko as a loadable
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1165#note_592015240 I haven't had a request to turn on UV for Fedora, and I am not sure that there is anyone interested in it, but I don't have an issue with flipping it on if anyone is. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH 0/0] Fix sysctl_unprivileged_bpf_disabled sysctl
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1162#note_591410772 Acked-by: Justin Forbes (via approve button) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] Enable NITRO_ENCLAVES on RHEL
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1163#note_591028806 Acked-by: Justin Forbes (via approve button) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH 0/0] Fix sysctl_unprivileged_bpf_disabled sysctl
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1162#note_590350124 Added "include in releases" as the kernel will not build without it. I added it to dist-git for rc4 in Fedora, which is building with this patch now successfully. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCHv2] RHEL: disable io_uring support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_590315781 Acked-by: Justin Forbes (via approve button) ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] RHEL: disable io_uring support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_587024136 So it seems Jens is against this for upstream, as IO_URING is "a core feature, and something that more and more apps or libraries are relying on", which is the direction it is heading. I would still like to see the patch follow the path of removing the if EXPERT, which follows a couple of other patches that we are carrying and makes it very clear in our source repository and in dist- git which setting a kernel is going to be built for. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] RHEL: disable io_uring support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_586022475 Or just wait it out, I submitted it upstream. Pavel has at least acked it: https://lore.kernel.org/io- uring/0d335e81-9a94-ca60-5659-bb46080b9...@gmail.com/T/#t ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] RHEL: disable io_uring support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_585992923 And x86_64 at least has completed the build successfully for ELN with expert removed and CONFIG_IO_URING turned off: ``` >cat ./lib/modules/5.13.0-0.rc3.20210526gitad9f25d33860.27.eln110.x86_64/config | grep IO_URING # CONFIG_IO_URING is not set ``` ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [OS-BUILD PATCH] RHEL: disable io_uring support
From: Justin Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1159#note_585939162 Not sure what Kconfig options you are saying it adds. In this case, it only adds one for CONFIG_IO_URING. Running a test with the following diff show no unset config options or mismatches in either case when I set CONFIG_IO_URING=y for Fedora and off for ELN. Diff below: `diff --git a/init/Kconfig b/init/Kconfig index 1ea12c64e4c9..0decca696bf7 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1621,7 +1621,7 @@ config AIO this option saves about 7k. config IO_URING - bool "Enable IO uring support" if EXPERT + bool "Enable IO uring support" select IO_WQ default y help diff --git a/redhat/configs/common/generic/CONFIG_IO_URING b/redhat/configs/common/generic/CONFIG_IO_URING new file mode 100644 index ..dcae2b3a1327 --- /dev/null +++ b/redhat/configs/common/generic/CONFIG_IO_URING @@ -0,0 +1 @@ +# CONFIG_IO_URING is not set diff --git a/redhat/configs/fedora/generic/CONFIG_IO_URING b/redhat/configs/fedora/generic/CONFIG_IO_URING new file mode 100644 index ..eff85c7a8f85 --- /dev/null +++ b/redhat/configs/fedora/generic/CONFIG_IO_URING @@ -0,0 +1 @@ +CONFIG_IO_URING=y ` And the resulting configs: `>grep IO_URING redhat/configs/kernel-*.config redhat/configs/kernel-aarch64-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-aarch64-debug-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-aarch64-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-aarch64-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-armv7hl-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-armv7hl-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-armv7hl-lpae-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-armv7hl-lpae-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-i686-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-i686-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-ppc64le-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-ppc64le-debug-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-ppc64le-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-ppc64le-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-s390x-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-s390x-debug-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-s390x-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-s390x-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-s390x-zfcpdump-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-x86_64-debug-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-x86_64-debug-rhel.config:# CONFIG_IO_URING is not set redhat/configs/kernel-x86_64-fedora.config:CONFIG_IO_URING=y redhat/configs/kernel-x86_64-rhel.config:# CONFIG_IO_URING is not set` Of course things seem to be building as expected on rawhide, the config doesn't change. I am testing a build in ELN to be sure, though I exect if issues show up, they would also show up with the original patch as they would be the result of turning off CONFIG_IO_URING. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
