Re: [PATCH 2/2] kbuild: rpm-pkg: build debuginfo and debugsource RPMs

[Uday Shankar <ushankar@purestorage.com>]

On Sat, Mar 15, 2025 at 04:56:35AM +0900, Masahiro Yamada wrote:
> Sorry for the long delay.

No worries and thanks for the review!

> On Tue, Feb 11, 2025 at 10:12 AM Uday Shankar <ushankar@purestorage.com> wrote:
> > Note that this feature is incompatible with CONFIG_MODULE_COMPRESS -
> > if it is turned on, the module .ko files are compressed before
> > find-debuginfo.sh sees them, and it will not be able to extract
> > debuginfo from them. There are two potential paths forward here:
> > - teach find-debuginfo.sh to extract debuginfo from compressed kernel
> >   modules
> > - teach the kernel build process to produce split debuginfo and then
> >   package that directly, bypassing find-debuginfo.sh
> 
> 
> 'make bindeb-pkg'  (Debian package) is able to build the debug package with
> CONFIG_MODULE_COMPRESS enabled.
> (see scripts/package/builddeb if you are interested)
> I have not checked if this works for 'make binrpm-pkg' or not.
> If this is a tricky case, I am OK with giving up CONFIG_MODULE_COMPRESS.

scripts/package/builddeb is able to do this because it is more hands-on
with the debuginfo generation - it invokes objcopy --only-keep-debug
directly. Meanwhile for rpm-pkg we are relying on find-debuginfo.sh for
the debuginfo generation - we just set things up appropriately (meaning
that we mark everything to be stripped as executable), and
find-debuginfo.sh does the rest. This means we can get debuginfo without
working as hard, but our flexibility is limited - without nasty hacks,
we cannot really handle compressed modules unless/until
find-debuginfo.sh is patched to handle them.

I could try revising this to remove the dependency on find-debuginfo.sh
and strip the debuginfo ourselves. Then we could handle compressed
modules the same way that deb-pkg does.

> > +# make modules executable so that find-debuginfo.sh strips them
> > +find %{buildroot}/lib/modules/%{KERNELRELEASE} -name "*.ko" -type f \
> > +       | xargs --no-run-if-empty chmod u+x
> 
> This seems necessary and correct.
> 
> One side-effect I noticed is that *.ko under /lib/modules/$(uname -r)/
> now have +x permissions. (Previously, they were non-executables).
> 
> I checked Fedora. Modules under /lib/modules/$(uname -r)/
> do not have +x permissions.
> 
> Do you know how Fedora's kernel.spec handles this?

I'm looking at

https://koji.fedoraproject.org/koji/buildinfo?buildID=2661097

The spec file for that package actually does something similar to what
we're doing above; it has this excerpt

# mark modules executable so that strip-to-file can strip them
xargs --no-run-if-empty chmod u+x < modnames

But later on it compresses the modules, using some RPM macro magic to
ensure that happens _after_ find-debuginfo.sh has seen and stripped the
executable modules. The compression eats the executable bit.

> > +
> > +%if %{with_debuginfo}
> > +mkdir -p %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE}
> > +cp vmlinux %{buildroot}/usr/lib/debug/lib/modules/%{KERNELRELEASE}
> > +%endif
> > +
> >  %clean
> >  rm -rf %{buildroot}
> > +rm -f debugfiles.list debuglinks.list debugsourcefiles.list debugsources.list \
> > +       elfbins.list
> >
> >  %post
> >  if [ -x /usr/bin/kernel-install ]; then
> > diff --git a/scripts/package/mkspec b/scripts/package/mkspec
> > index 4dc1466dfc815c110eb7206f83dd874b17f5170f..4c96bdca381a2fb4cc57415ca914d14e37e16caa 100755
> > --- a/scripts/package/mkspec
> > +++ b/scripts/package/mkspec
> > @@ -23,6 +23,9 @@ else
> >  echo '%define with_devel 0'
> >  fi
> >
> > +WITH_DEBUGINFO=$(grep -c CONFIG_DEBUG_INFO=y include/config/auto.conf)
> > +echo "%define with_debuginfo ${WITH_DEBUGINFO}"
> > +
> 
> How about this code?
> 
> if grep -q CONFIG_DEBUG_INFO=y include/config/auto.conf; then
> echo '%define with_debuginfo %{?_without_debuginfo: 0}
> %{?!_without_debuginfo: 1}'
> else
> echo '%define with_debuginfo 0'
> fi
> 
> This allows users to skip the debuginfo package
> and aligns with the existing code a few lines above.
> 
> Also, it is compatible with Fedora's kernel.spec.
> https://src.fedoraproject.org/rpms/kernel/blob/rawhide/f/kernel.spec#_236
> 
> 
> If you do not support CONFIG_MODULE_COMPRESS,
> you can check it here.

Yes, both suggestions make sense, thanks. Will implement these in v2.