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.
Regards,
Hans
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede hdegoede@redhat.com 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
Hi,
On 7/29/21 2:44 PM, Justin Forbes wrote:
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede hdegoede@redhat.com 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 ?
Regards,
Hans
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
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 hdegoede@redhat.com wrote:
Hi,
On 7/29/21 2:44 PM, Justin Forbes wrote:
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede hdegoede@redhat.com
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 ?
Regards,
Hans _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@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
On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling jwp@redhat.com 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 hdegoede@redhat.com wrote:
Hi,
On 7/29/21 2:44 PM, Justin Forbes wrote:
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede hdegoede@redhat.com 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
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.
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.
On Tue, 3 Aug 2021 at 00:27, Justin Forbes jforbes@redhat.com wrote:
On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling jwp@redhat.com 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 hdegoede@redhat.com wrote:
Hi,
On 7/29/21 2:44 PM, Justin Forbes wrote:
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede hdegoede@redhat.com
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
On Mon, Aug 2, 2021 at 3:59 PM Joel Wirāmu Pauling jwp@redhat.com 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 jforbes@redhat.com wrote:
On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling jwp@redhat.com 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 hdegoede@redhat.com wrote:
Hi,
On 7/29/21 2:44 PM, Justin Forbes wrote:
On Thu, Jul 29, 2021 at 6:48 AM Hans de Goede hdegoede@redhat.com
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-leave@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@lists.fedoraproject.org
-
Hans de Goede -
Joel Wirāmu Pauling -
Justin Forbes -
Justin Forbes