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(a)redhat.com> wrote:
On Mon, Aug 2, 2021 at 6:06 AM Joel Wirāmu Pauling
<jwp(a)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(a)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(a)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