On Mon, Aug 2, 2021 at 3:59 PM Joel Wirāmu Pauling <jwp@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: > > > On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling <jwp@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
