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.
Best regards,
--
Paul Barker
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#243526):
https://lists.openembedded.org/g/openembedded-core/message/243526
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]]
-=-=-=-=-=-=-=-=-=-=-=-
