On Sun, 2026-08-16 at 14:19 +0200, Benjamin Robin via lists.openembedded.org
wrote:
> On Sunday, August 16, 2026 at 1:37 PM, Paul Barker wrote:
> > On Sun, 2026-08-16 at 13:25 +0200, Benjamin Robin wrote:
> > > On Sunday, August 16, 2026 at 1:12 PM, Benjamin Robin wrote:
> > > > On Sunday, August 16, 2026 at 12:46 PM, Paul Barker wrote:
> > > > > On Mon, 2026-08-10 at 09:11 +0200, Benjamin Robin wrote:
> > > > > > Previously, except for a kernel recipe, the source file paths were
> > > > > > never
> > > > > > "resolved" since the KERNEL_SRC_PATH variable is always defined. So
> > > > > > in
> > > > > > the ${PN}-debugsources.json.zstd file the source file paths always
> > > > > > started
> > > > > > with /usr/src/debug/${PN}/${PV} (which is the value of
> > > > > > TARGET_DBGSRC_DIR).
> > > > > >
> > > > > > Currently the debugsources.json file is only used by the spdx
> > > > > > generation.
> > > > > > - In `get_patched_src()` the sources of the recipe are extracted
> > > > > > (again).
> > > > > > The unpack task is executed from a modified local context with
> > > > > > UNPACKDIR
> > > > > > set to the value of `${SPDXWORK}`. So in summary the sources are
> > > > > > extracted in a sub-directory of `${SPDXWORK}`.
> > > > > > - In `add_package_files()`, with topdir equal to `${SPDXWORK}`, all
> > > > > > the
> > > > > > files (recursively) found in topdir are listed. For each source
> > > > > > file,
> > > > > > if the file path (relative to topdir) is in the list of source
> > > > > > files
> > > > > > retrieved by save_debugsources_info, then the file is added to
> > > > > > the SPDX
> > > > > > SBoM.
> > > > > >
> > > > > > So try to handle that by replacing ${TARGET_DBGSRC_DIR} by the
> > > > > > relative
> > > > > > path of ${S} relative to ${UNPACKDIR}. If ${S} is not relative to
> > > > > > ${UNPACKDIR}, do nothing.
> > > > > >
> > > > > > Signed-off-by: Benjamin Robin <[email protected]>
> > > > >
> > > > > The paths in ${PN}-debugsources.json currently match where the files
> > > > > will be installed on the target. If we change these to be relative
> > > > > paths within ${UNPACKDIR} then we would break other ways that the
> > > > > debugsources json files may be used.
> > > >
> > > > Hello Paul,
> > > >
> > > > This was never the purpose of ${PN}-debugsources.json if I am not
> > > > mistaken.
> > > > If you look at the code (before my patches) the path should have been
> > > > modified to be somewhat relative to WORKDIR. But the code had a bug, and
> > > > the paths were never modified.
> > > >
> > > > Also, for the kernel, the kernel sources paths were already modified to
> > > > be
> > > > the same as the path in SPDX, so starting with ${BP}. This part was
> > > > mostly working for the "main" use case. In a previous RFC series that
> > > > was
> > > > merged, I fix that to be working for any kernel recipe.
> > > >
> > > > > What is currently broken?
> > > >
> > > > SPDX_INCLUDE_COMPILED_SOURCES for a normal recipe (not the kernel) is
> > > > not
> > > > working.
> > > >
> > > > > Can this be fixed at the point where the
> > > > > debugsources json file is parsed instead of where it is generated?
> > >
> > > Yes, I guess we could modify how oe.spdx_common.get_compiled_sources() is
> > > implemented. In that case I would recommend to no longer modify the paths
> > > of kernel sources in save_debugsources_info(). We would keep the paths as
> > > is,
> > > we would only filter for "<internal>", "<built-in>", ...
> > >
> > > In any cases, this is kind of a breaking change since the
> > > ${PN}-debugsources.json is not going to contain the same paths as before.
> > >
> > > But what you are "proposing" (modifying get_compiled_sources()) is a bit
> > > cleaner from my point of view. This is a bit more work, that is why I did
> > > not do that.
> > > Joshua do you have an option on that?
> > >
> > > > > Sorry if I'm missing some context here.
> > > >
> > > > For the full context see:
> > > > https://lore.kernel.org/all/[email protected]/
> > > > https://github.com/bootlin/yocto-kiss/pull/26#discussion_r3626224833
> >
> > Hi Benjamin,
> >
> > Yes, I was missing some context! I was replying based off discussions we
> > had on the patch review call on Thursday.
> >
> > If the paths in debugsources.json files are currently inconsistent
> > between kernel and non-kernel recipes then we should fix that. So
> > perhaps your patch is correct after all. I'll let Joshua give an
> > opinion.
>
> Be aware that with all my patches, the content of debugsources.json will
> still contain paths starting with /usr/src/debug/ since there are paths
> from others recipes (header files from glibc for example, ...).
>
> I am not sure I will have time this week to take a look at the second
> solution (modifying get_compiled_sources which is a bit cleaner from my
> point of view). I'll let Joshua give his opinion first :)
Giving some extra data here, we list all the sources the binaries
reference, whether they're from the current recipe or a different one.
The sources from a different recipe use the on target paths for the
soruces and I think the paths for the current recipe should be the same
for consistency.
The /usr/src/debug/ paths are therefore correct and we should be
standarising on that, not on transient build paths IMO.
If other code has to resolve that to find the real files, so be it.
That will depend on the context the file is being used in as to whether
they're even still available.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243867):
https://lists.openembedded.org/g/openembedded-core/message/243867
Mute This Topic: https://lists.openembedded.org/mt/120681384/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
