${PN}-ipc
Christian Leeb
Hi Ricardo,
I have a question regarding your commit 76739fe56f0eb0f1eb4eefcc3f250e4b8454cf30 in meta-swupdate, scarthgap, which adds a separate package ${PN}-ipc for libswupdate library (see links at the end of my mail).
In our Yocto Linux distribution we are using multiple instances of swupdate
because some images need a signed and some an unsigned swupdate:
In our distro layer we have
Each one is pointing to the same SRCREV but to a difference defconfig.
This worked all well before ${PN}-ipc was introduced.
Building the recipes works well but in do_packagedata, I’m getting
this error:
ERROR: swupdate-2024.12-r0.spark1 do_packagedata: Recipe swupdate is trying to
install files into a shared area when those files already exist. The files and
the manifests listing them are:
/home/chchlee/scarthgap_arm/build/tmp-glibc/pkgdata/rtu530cpm0x/runtime-reverse/libswupdate0.1 (matched in manifest-rtu530cpm0x-swupdate-pasop-signed.packagedata)
Please adjust the recipes so only one recipe provides a given file.
ERROR: Logfile of failure stored in: /home/chchlee/scarthgap_arm/build/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/swupdate/2024.12/temp/log.do_packagedata.2108593
The reason seems to be that all swupdate instances try to install
libswupdate0.1 in ${PN}-ipc. I guess the “shared area” is the sysroot. Maybe
the new dependencies
RDEPENDS:${PN}-dev += "${PN}-ipc"
RRECOMMENDS:${PN} += "${PN}-ipc"
create the problem.
Maybe you can give me a hint how I could address this issue?
Best regards, Chris
-----------
File: https://github.com/sbabic/meta-swupdate/blob/scarthgap/recipes-support/swupdate/swupdate.inc
Commit message
: swupdate: package libswupdate into separate package
The libswupdate shared library produced by the contents of the ipc
subdirectory can be used by other packages to communicate with SWUpdate.
The library is embedded into the base package which creates two
problems:
- A recipe / program cannot depend on libswupdate without depending on
swupdate
- The complete set of swupdate licenses seems to apply to the program
including strong copyleft GPL-2.0-only instead only LPGL-2.1-or-later
As documented in the source code swupdate-ipc is purely
LGPL-2.1-or-later.
Existing recipes / programs which need libswupdate but only depend on
swupdate will still get libswupdate through a runtime recommendation.
Signed-off-by: Ricardo Simoes <ricardo...@pt.bosch.com>
Signed-off-by: Mark Jonas <mark....@de.bosch.com>
ricardo ungerer
> On 19 Mar 2025, at 07:03, Christian Leeb <christ...@gmail.com> wrote:
>
> Hi Ricardo,
>
> I have a question regarding your commit 76739fe56f0eb0f1eb4eefcc3f250e4b8454cf30 in meta-swupdate, scarthgap, which adds a separate package ${PN}-ipc for libswupdate library (see links at the end of my mail).
>
>
> In our Yocto Linux distribution we are using multiple instances of swupdate because some images need a signed and some an unsigned swupdate:
> In our distro layer we have
> • swupdate-unsigned_2024.12.bb
> • swupdate-signed_2024.12.bb
> Each one is pointing to the same SRCREV but to a difference defconfig.
> This worked all well before ${PN}-ipc was introduced.
possible to do the same for the shared library?
>
> Building the recipes works well but in do_packagedata, I’m getting this error:
>
> ERROR: swupdate-2024.12-r0.spark1 do_packagedata: Recipe swupdate is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
> /home/chchlee/scarthgap_arm/build/tmp-glibc/pkgdata/rtu530cpm0x/runtime-reverse/libswupdate0.1 (matched in manifest-rtu530cpm0x-swupdate-pasop-signed.packagedata)
> Please adjust the recipes so only one recipe provides a given file.
> ERROR: Logfile of failure stored in: /home/chchlee/scarthgap_arm/build/tmp-glibc/work/armv7ahf-neon-oe-linux-gnueabi/swupdate/2024.12/temp/log.do_packagedata.2108593
>
> The reason seems to be that all swupdate instances try to install libswupdate0.1 in ${PN}-ipc. I guess the “shared area” is the sysroot. Maybe the new dependencies
> RDEPENDS:${PN}-dev += "${PN}-ipc"
> RRECOMMENDS:${PN} += "${PN}-ipc"
> create the problem.
populates the pkgdata with libswupdate0.1 (something that does not
happen for the other splitted packages). Then when the second recipe
tries to populate packagedata, the build process is interrupted because
there is already a libswupdate0.1 file.
If you do not need the library, simply remove the package in your recipes.
If you need the library, then you can rename the library (and swupdate
build rules?). Or even better, move swupdate-ipc into its own recipe.
>
> Maybe you can give me a hint how I could address this issue?
>
> Best regards, Chris
>
> -----------
> File: https://github.com/sbabic/meta-swupdate/blob/scarthgap/recipes-support/swupdate/swupdate.inc
> Commit message
> : swupdate: package libswupdate into separate package
>
> The libswupdate shared library produced by the contents of the ipc
> subdirectory can be used by other packages to communicate with SWUpdate.
> The library is embedded into the base package which creates two
> problems:
>
> - A recipe / program cannot depend on libswupdate without depending on
> swupdate
> - The complete set of swupdate licenses seems to apply to the program
> including strong copyleft GPL-2.0-only instead only LPGL-2.1-or-later
>
> As documented in the source code swupdate-ipc is purely
> LGPL-2.1-or-later.
>
> Existing recipes / programs which need libswupdate but only depend on
> swupdate will still get libswupdate through a runtime recommendation.
>
> Signed-off-by: Ricardo Simoes <ricardo...@pt.bosch.com>
> Signed-off-by: Mark Jonas <mark....@de.bosch.com>
>
>
> You received this message because you are subscribed to the Google Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/swupdate/CAMa2sytDRNAW1Nf96ZS_nYdVCMiXLb8QRW2ZGqaAa3LbPCioQg%40mail.gmail.com.
Cheers,
Ricardo
Christian Leeb
Yes, I need the library.
Stefano Babic
> Hi,
>
> Yes, I need the library.
>
> "How do you install both swupdate binaries in the images?"
>
> All swupdate recipes are in the same packagegroup. Hence they are all
> built whichever image I build. This is not the problem.
>
> I then install exactly one swupdate recipe in each image resp. the
> related rootfs. This worked well before libswupdate0.1 was moved to a
> dedicated package.
>
> Since I cannot overwrite / bbappend swupdate.inc I cannot easily rename
> the library...
it several times on the image, you can use thew same to connect to each
instance. So you just let the package in one recipe and remove it in the
other ones.
Best regards,
Stefano Babic
>
> Hmm, still struggeling to understand why the dedicated package leads to
> this problem.
>
> BR, Chris
>
>
> ricardo ungerer schrieb am Mittwoch, 19. März 2025 um 21:53:10 UTC+1:
>
> Hi Christian,
>
> > On 19 Mar 2025, at 07:03, Christian Leeb <christ...@gmail.com>
> wrote:
> >
> > Hi Ricardo,
> >
> > I have a question regarding your commit
> 76739fe56f0eb0f1eb4eefcc3f250e4b8454cf30 in meta-swupdate,
> scarthgap, which adds a separate package ${PN}-ipc for libswupdate
> library (see links at the end of my mail).
> >
> >
> > In our Yocto Linux distribution we are using multiple instances
> of swupdate because some images need a signed and some an unsigned
> swupdate:
> > In our distro layer we have
> > • swupdate-signed_2024.12.bb <http://swupdate-signed_2024.12.bb>
> meta-swupdate/blob/scarthgap/recipes-support/swupdate/swupdate.inc>
> CAMa2sytDRNAW1Nf96ZS_nYdVCMiXLb8QRW2ZGqaAa3LbPCioQg%40mail.gmail.com>.
>
> Cheers,
> Ricardo
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/b8ef3592-d148-4d24-
> b57b-55a276558ca2n%40googlegroups.com?utm_medium=email&utm_source=footer>.
Khem Raj
>
> Hi,
>
> Yes, I need the library.
>
> "How do you install both swupdate binaries in the images?"
>
> All swupdate recipes are in the same packagegroup. Hence they are all built whichever image I build. This is not the problem.
>
> I then install exactly one swupdate recipe in each image resp. the related rootfs. This worked well before libswupdate0.1 was moved to a dedicated package.
>
> Since I cannot overwrite / bbappend swupdate.inc I cannot easily rename the library...
>
> Hmm, still struggeling to understand why the dedicated package leads to this problem.
>
ensure that there are no output package conflicts
if they are installing duplicate files then it will be flagged by
image builder. So consider renaming the binaries etc may
be with some prefix. It gets harder when you have shared libraries,
since having two copies of the same version of shared
library. if one library can fit the bill then delete it from the
second recipe. another option is two spawn a new recipe which
just builds the shared library and nothing else and let both recipes
depend on it and these recipes then do not package
the shared lib.