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@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
