On Mon, Aug 2, 2021 at 3:59 PM Joel Wirāmu Pauling <jwp(a)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(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
> >
> >
> _______________________________________________
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)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