Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Benjamin Robin <benjamin.robin@bootlin.com>
To: openembedded-core@lists.openembedded.org, Paul Barker <paul@pbarker.dev>
Cc: jpewhacker@gmail.com, antonin.godard@bootlin.com,
	mathieu.dubois-briand@bootlin.com, thomas.petazzoni@bootlin.com,
	daniel.turull@ericsson.com
Subject: Re: [PATCH 2/2] package: fix source path in save_debugsources_info()
Date: Sun, 16 Aug 2026 13:12:41 +0200	[thread overview]
Message-ID: <foNKo7xSSzG14aIsBMYQlA@bootlin.com> (raw)
In-Reply-To: <96d72ef99f426d380cd090740ff636df1512ba2f.camel@pbarker.dev>

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 <benjamin.robin@bootlin.com>
> 
> 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? Sorry
> if I'm missing some context here.

For the full context see:
https://lore.kernel.org/all/20260727-fix-get-patched-src-v1-0-f5054ca10e14@bootlin.com/
https://github.com/bootlin/yocto-kiss/pull/26#discussion_r3626224833


-- 
Benjamin Robin, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com





  reply	other threads:[~2026-08-16 11:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-10  7:11 [PATCH 0/2] package: improve save_debugsources_info() Benjamin Robin
2026-08-10  7:11 ` [PATCH 1/2] package: Fix source info when PACKAGE_DEBUG_STATIC_SPLIT is set Benjamin Robin
2026-08-10  7:11 ` [PATCH 2/2] package: fix source path in save_debugsources_info() Benjamin Robin
2026-08-16 10:46   ` Paul Barker
2026-08-16 11:12     ` Benjamin Robin [this message]
2026-08-16 11:25       ` Benjamin Robin
2026-08-16 11:37         ` Paul Barker
2026-08-16 12:19           ` Benjamin Robin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=foNKo7xSSzG14aIsBMYQlA@bootlin.com \
    --to=benjamin.robin@bootlin.com \
    --cc=antonin.godard@bootlin.com \
    --cc=daniel.turull@ericsson.com \
    --cc=jpewhacker@gmail.com \
    --cc=mathieu.dubois-briand@bootlin.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul@pbarker.dev \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox