[meta-core][PATCH v2] libgpg-error: inherit lib_package

[meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

Inherit lib_package to create an extra libgpg-error-bin package for
executables. As a result, the gpg-error and yat2m executables are now in
this libgpg-error-bin package, and no longer in the libgpg-error
package.

Signed-off-by: Mario Schuknecht <mario.schuknecht@iris-sensing.com>
---
 meta/recipes-support/libgpg-error/libgpg-error_1.51.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.51.bb b/meta/recipes-support/libgpg-error/libgpg-error_1.51.bb
index 741969beb0..e0287d813b 100644
--- a/meta/recipes-support/libgpg-error/libgpg-error_1.51.bb
+++ b/meta/recipes-support/libgpg-error/libgpg-error_1.51.bb
@@ -24,7 +24,7 @@ SRC_URI[sha256sum] = "be0f1b2db6b93eed55369cdf79f19f72750c8c7c39fc20b577e7245454
 
 BINCONFIG = "${bindir}/gpg-error-config"
 
-inherit autotools binconfig-disabled pkgconfig gettext multilib_header multilib_script ptest
+inherit autotools lib_package binconfig-disabled pkgconfig gettext multilib_header multilib_script ptest
 
 RDEPENDS:${PN}-ptest:append = " make bash"
 
@@ -47,7 +47,6 @@ do_install_ptest() {
     install ${B}/tests/Makefile ${D}${PTEST_PATH}
 }
 
-FILES:${PN}-dev += "${bindir}/gpg-error"
 FILES:${PN}-doc += "${datadir}/libgpg-error/errorref.txt"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.35.3

Patchtest results for [meta-core][PATCH v2] libgpg-error: inherit lib_package

[patchtest]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:

---
Testing patch /home/patchtest/share/mboxes/meta-core-v2-libgpg-error-inherit-lib_package.patch

FAIL: test target mailing list: Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists (test_mbox.TestMbox.test_target_mailing_list)

PASS: pretest src uri left files (test_metadata.TestMetadata.pretest_src_uri_left_files)
PASS: test CVE check ignore (test_metadata.TestMetadata.test_cve_check_ignore)
PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence)
PASS: test commit message user tags (test_mbox.TestMbox.test_commit_message_user_tags)
PASS: test lic files chksum modified not mentioned (test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)
PASS: test max line length (test_metadata.TestMetadata.test_max_line_length)
PASS: test mbox format (test_mbox.TestMbox.test_mbox_format)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)
PASS: test src uri left files (test_metadata.TestMetadata.test_src_uri_left_files)

SKIP: pretest pylint: No python related patches, skipping test (test_python_pylint.PyLint.pretest_pylint)
SKIP: test CVE tag format: No new CVE patches introduced (test_patch.TestPatch.test_cve_tag_format)
SKIP: test Signed-off-by presence: No new CVE patches introduced (test_patch.TestPatch.test_signed_off_by_presence)
SKIP: test Upstream-Status presence: No new CVE patches introduced (test_patch.TestPatch.test_upstream_status_presence_format)
SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format)
SKIP: test lic files chksum presence: No added recipes, skipping test (test_metadata.TestMetadata.test_lic_files_chksum_presence)
SKIP: test license presence: No added recipes, skipping test (test_metadata.TestMetadata.test_license_presence)
SKIP: test pylint: No python related patches, skipping test (test_python_pylint.PyLint.test_pylint)
SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head)
SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence)

---

Please address the issues identified and
submit a new revision of the patch, or alternatively, reply to this
email with an explanation of why the patch should be accepted. If you
believe these results are due to an error in patchtest, please submit a
bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category
under 'Yocto Project Subprojects'). For more information on specific
failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank
you!

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mathieu Dubois-Briand]

On Fri Mar 21, 2025 at 4:12 PM CET, Mario Schuknecht via lists.openembedded.org wrote:
> Inherit lib_package to create an extra libgpg-error-bin package for
> executables. As a result, the gpg-error and yat2m executables are now in
> this libgpg-error-bin package, and no longer in the libgpg-error
> package.
>
> Signed-off-by: Mario Schuknecht <mario.schuknecht@iris-sensing.com>
> ---

Hi Mario,

Thanks for the v2, but it looks like we still have a build error:

ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Unable to install packages. Command '/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1148269/tmp/work/qemux86_64-poky-linux/core-image-full-cmdline/1.0/recipe-sysroot-native/usr/bin/apt-get  install --allow-downgrades --allow-remove-essential --allow-change-held-packages --allow-unauthenticated --no-remove  apt dpkg gnupg packagegroup-core-boot packagegroup-core-full-cmdline packagegroup-core-ssh-openssh psplash run-postinsts signing-keys-packagefeed ssh-pregen-hostkeys' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gnupg : Depends: gnupg-gpg but it is not going to be installed
         Depends: libgpg-error (>= 1.51)
         Recommends: pinentry but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

https://autobuilder.yoctoproject.org/valkyrie/#/builders/54/builds/1247
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/1159

Best regards,
Mathieu

-- 
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

Hi Mathieu,

thanks for your reply.

I have tried to reproduce the error but without success.

How do you set up the environment and what command do you run?

Regards,
Mario

________________________________________
Von: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Gesendet: Sonntag, 23. März 2025 18:44
An: Mario Schuknecht <Mario.Schuknecht@iris-sensing.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
Cc: Mario Schuknecht <mario.schuknecht@iris-sensing.com>
Betreff: Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

On Fri Mar 21, 2025 at 4:12 PM CET, Mario Schuknecht via lists.openembedded.org wrote:
> Inherit lib_package to create an extra libgpg-error-bin package for
> executables. As a result, the gpg-error and yat2m executables are now in
> this libgpg-error-bin package, and no longer in the libgpg-error
> package.
>
> Signed-off-by: Mario Schuknecht <mario.schuknecht@iris-sensing.com>
> ---

Hi Mario,

Thanks for the v2, but it looks like we still have a build error:

ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Unable to install packages. Command '/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1148269/tmp/work/qemux86_64-poky-linux/core-image-full-cmdline/1.0/recipe-sysroot-native/usr/bin/apt-get  install --allow-downgrades --allow-remove-essential --allow-change-held-packages --allow-unauthenticated --no-remove  apt dpkg gnupg packagegroup-core-boot packagegroup-core-full-cmdline packagegroup-core-ssh-openssh psplash run-postinsts signing-keys-packagefeed ssh-pregen-hostkeys' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 gnupg : Depends: gnupg-gpg but it is not going to be installed
         Depends: libgpg-error (>= 1.51)
         Recommends: pinentry but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

https://autobuilder.yoctoproject.org/valkyrie/#/builders/54/builds/1247
https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/1159

Best regards,
Mathieu

--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com/

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

You can see in the error log that this selftest failed:

2025-03-23 17:20:09,617 - oe-selftest - INFO - RESULTS -
runtime_test.TestImage.test_testimage_apt: FAILED (69.22s)

You can find what it does here:
https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/runtime_test.py#n183

Alex

On Mon, 24 Mar 2025 at 11:39, Mario Schuknecht via
lists.openembedded.org
<Mario.Schuknecht=iris-sensing.com@lists.openembedded.org> wrote:
>
> Hi Mathieu,
>
> thanks for your reply.
>
> I have tried to reproduce the error but without success.
>
> How do you set up the environment and what command do you run?
>
> Regards,
> Mario
>
> ________________________________________
> Von: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
> Gesendet: Sonntag, 23. März 2025 18:44
> An: Mario Schuknecht <Mario.Schuknecht@iris-sensing.com>; openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
> Cc: Mario Schuknecht <mario.schuknecht@iris-sensing.com>
> Betreff: Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package
>
> On Fri Mar 21, 2025 at 4:12 PM CET, Mario Schuknecht via lists.openembedded.org wrote:
> > Inherit lib_package to create an extra libgpg-error-bin package for
> > executables. As a result, the gpg-error and yat2m executables are now in
> > this libgpg-error-bin package, and no longer in the libgpg-error
> > package.
> >
> > Signed-off-by: Mario Schuknecht <mario.schuknecht@iris-sensing.com>
> > ---
>
> Hi Mario,
>
> Thanks for the v2, but it looks like we still have a build error:
>
> ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Unable to install packages. Command '/srv/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-1148269/tmp/work/qemux86_64-poky-linux/core-image-full-cmdline/1.0/recipe-sysroot-native/usr/bin/apt-get  install --allow-downgrades --allow-remove-essential --allow-change-held-packages --allow-unauthenticated --no-remove  apt dpkg gnupg packagegroup-core-boot packagegroup-core-full-cmdline packagegroup-core-ssh-openssh psplash run-postinsts signing-keys-packagefeed ssh-pregen-hostkeys' returned 100:
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  gnupg : Depends: gnupg-gpg but it is not going to be installed
>          Depends: libgpg-error (>= 1.51)
>          Recommends: pinentry but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.
>
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/54/builds/1247
> https://autobuilder.yoctoproject.org/valkyrie/#/builders/48/builds/1159
>
> Best regards,
> Mathieu
>
> --
> Mathieu Dubois-Briand, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com/
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#213524): https://lists.openembedded.org/g/openembedded-core/message/213524
> Mute This Topic: https://lists.openembedded.org/mt/111829729/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Richard Purdie]

On Mon, 2025-03-24 at 11:45 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> You can see in the error log that this selftest failed:
> 
> 2025-03-23 17:20:09,617 - oe-selftest - INFO - RESULTS -
> runtime_test.TestImage.test_testimage_apt: FAILED (69.22s)
> 
> You can find what it does here:
> https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/runtime_test.py#n183

Probably worth adding that the command to run this is:

oe-selftest -r runtime_test.TestImage.test_testimage_apt

Cheers,

Richard

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

On Mon, 2025-03-24 at 11:45 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> You can see in the error log that this selftest failed:
>
> 2025-03-23 17:20:09,617 - oe-selftest - INFO - RESULTS -
> runtime_test.TestImage.test_testimage_apt: FAILED (69.22s)
>
> You can find what it does here:
> https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/selftest/cases/runtime_test.py#n183

Probably worth adding that the command to run this is:

oe-selftest -r runtime_test.TestImage.test_testimage_apt



Hi,

unfortunately I cannot reproduce the bug that the do_rootfs task of core-image-full-cmdline fails.

I used the git poky/master branch, sourced the environment, applied the patch and startet the test.
oe-selftest -r runtime_test.TestImage.test_testimage_apt

The do_rootfs task runs fine.
NOTE: recipe core-image-full-cmdline-1.0-r0: task do_rootfs: Started
NOTE: recipe core-image-full-cmdline-1.0-r0: task do_rootfs: Succeeded

I see the error in your log file, but I do not see the reason for the error.
I am not sure if the gnupg-pg package exists or why it is not installed.
Are there more detailed log files?

Regards,
Mario

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

On Tue, 25 Mar 2025 at 08:18, Mario Schuknecht
<Mario.Schuknecht@iris-sensing.com> wrote:
> unfortunately I cannot reproduce the bug that the do_rootfs task of core-image-full-cmdline fails.
>
> I used the git poky/master branch, sourced the environment, applied the patch and startet the test.
> oe-selftest -r runtime_test.TestImage.test_testimage_apt
>
> The do_rootfs task runs fine.
> NOTE: recipe core-image-full-cmdline-1.0-r0: task do_rootfs: Started
> NOTE: recipe core-image-full-cmdline-1.0-r0: task do_rootfs: Succeeded
>
> I see the error in your log file, but I do not see the reason for the error.
> I am not sure if the gnupg-pg package exists or why it is not installed.
> Are there more detailed log files?

I suspect the problem originates in 'debian renaming' (seen via buildhistory):

packages/core2-64-poky-linux/libgpg-error/libgpg-error: RPROVIDES:
added "libgpg-error (['= 1.51'])"
packages/core2-64-poky-linux/libgpg-error/libgpg-error: PKG changed
from libgpg-error [default] to libgpg-error0

It appears that somehow dependent packages (e.g. gnupg) aren't rebuilt
to use 'libgpg-error0', and at the same time apt isn't able to see the
newly added RPROVIDES that would satisfy the old dependency?

I don't have a local reproducer yet, trying to get to one. Plain
selftest passes for me too.

The easy way out is probably to set PR to force a repackaging?

Alex

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

On Tue, 25 Mar 2025 at 14:05, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:

> It appears that somehow dependent packages (e.g. gnupg) aren't rebuilt
> to use 'libgpg-error0', and at the same time apt isn't able to see the
> newly added RPROVIDES that would satisfy the old dependency?
>
> I don't have a local reproducer yet, trying to get to one. Plain
> selftest passes for me too.

I have reproduced this. You need to build the image twice to see it.

1. Set up a plain yocto build, put this in local.conf (which
replicates the selftest, particularly in putting gnupg into the
image):

IMAGE_CLASSES += "testimage"
TEST_SUITES = "ping ssh apt.AptRepoTest.test_apt_install_from_repo"
PACKAGE_FEED_URIS = "http://bogus_ip:bogus_port"
EXTRA_IMAGE_FEATURES += "package-management"
PACKAGE_CLASSES = "package_deb"
IMAGE_INSTALL:append:pn-core-image-full-cmdline = " gnupg"

2. bitbake core-image-full-cmdline

3. Apply the patch.

4. bitbake core-image-full-cmdline ---> kaboom.

Alex

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

> It appears that somehow dependent packages (e.g. gnupg) aren't rebuilt
> to use 'libgpg-error0', and at the same time apt isn't able to see the
> newly added RPROVIDES that would satisfy the old dependency?
>
> I don't have a local reproducer yet, trying to get to one. Plain
> selftest passes for me too.

I have reproduced this. You need to build the image twice to see it.

1. Set up a plain yocto build, put this in local.conf (which
replicates the selftest, particularly in putting gnupg into the
image):

IMAGE_CLASSES += "testimage"
TEST_SUITES = "ping ssh apt.AptRepoTest.test_apt_install_from_repo"
PACKAGE_FEED_URIS = "[http://bogus_ip:bogus_port]http://bogus_ip:bogus_port"
EXTRA_IMAGE_FEATURES += "package-management"
PACKAGE_CLASSES = "package_deb"
IMAGE_INSTALL:append:pn-core-image-full-cmdline = " gnupg"

2. bitbake core-image-full-cmdline

3. Apply the patch.

4. bitbake core-image-full-cmdline ---> kaboom.

Alex


Great. I'm going to test that.

Mario

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

> It appears that somehow dependent packages (e.g. gnupg) aren't rebuilt
> to use 'libgpg-error0', and at the same time apt isn't able to see the
> newly added RPROVIDES that would satisfy the old dependency?
>
> I don't have a local reproducer yet, trying to get to one. Plain
> selftest passes for me too.

I have reproduced this. You need to build the image twice to see it.

1. Set up a plain yocto build, put this in local.conf (which
replicates the selftest, particularly in putting gnupg into the
image):

IMAGE_CLASSES += "testimage"
TEST_SUITES = "ping ssh apt.AptRepoTest.test_apt_install_from_repo"
PACKAGE_FEED_URIS = "[http://bogus_ip:bogus_port]http://bogus_ip:bogus_port"
EXTRA_IMAGE_FEATURES += "package-management"
PACKAGE_CLASSES = "package_deb"
IMAGE_INSTALL:append:pn-core-image-full-cmdline = " gnupg"

2. bitbake core-image-full-cmdline

3. Apply the patch.

4. bitbake core-image-full-cmdline ---> kaboom.

Alex


I was able to reproduce the problem now.
And as you mentioned, PR="r1" fixes the problem.
But setting the PR variable is rarely used. So I wonder if this solution is okay?

Mario

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

On Wed, 26 Mar 2025 at 16:17, Mario Schuknecht
<Mario.Schuknecht@iris-sensing.com> wrote:

> I was able to reproduce the problem now.
> And as you mentioned, PR="r1" fixes the problem.
> But setting the PR variable is rarely used. So I wonder if this solution is okay?

Probably not. There seems to be a deeper issue here, and it's better
to get to the bottom of it. If you have a bit of time, I'd appreciate
if you narrrow it down: inspect the metadata of the .deb packages:
gnupg, and then gpg-error, before and after the change. In other
words, is the problem with apt, or with not repackaging gnupg
properly? How does it compare to when using rpm?

Alex

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

On Wed, 26 Mar 2025 at 16:17, Mario Schuknecht
<Mario.Schuknecht@iris-sensing.com> wrote:

> I was able to reproduce the problem now.
> And as you mentioned, PR="r1" fixes the problem.
> But setting the PR variable is rarely used. So I wonder if this solution is okay?

Probably not. There seems to be a deeper issue here, and it's better
to get to the bottom of it. If you have a bit of time, I'd appreciate
if you narrrow it down: inspect the metadata of the .deb packages:
gnupg, and then gpg-error, before and after the change. In other
words, is the problem with apt, or with not repackaging gnupg
properly? How does it compare to when using rpm?

Alex


I have found out the following:

After applying the libgpg-error patch, the gnupg deb-packages are not rebuilt.

My guess is that the gnupg recipe is missing a dependency on libgpg-error.
However, gnupg uses the shared library from libgpg-error, so this dependency
is necessary. 

That the gnupg built has been successful so far is probably due to the fact that
gnupg depends on libgcrypt and libgcrypt depends on libgpg-error. As a
result, libgpg-error was available in the recipe-sysroot directory of gnugp.

libgpg-error should be added to gnupg's DEPENDS variable. Then the
libgpg-error patch will work correctly.

If this analysis is confirmed:
Should I create a separate patch to add the dependency?
Alternatively, someone else could do this and then the libgpg-error patch
could be used unchanged.

Regards,
Mario

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

On Fri, 4 Apr 2025 at 17:14, Mario Schuknecht
<Mario.Schuknecht@iris-sensing.com> wrote:
> I have found out the following:
>
> After applying the libgpg-error patch, the gnupg deb-packages are not rebuilt.
>
> My guess is that the gnupg recipe is missing a dependency on libgpg-error.
> However, gnupg uses the shared library from libgpg-error, so this dependency
> is necessary.
>
> That the gnupg built has been successful so far is probably due to the fact that
> gnupg depends on libgcrypt and libgcrypt depends on libgpg-error. As a
> result, libgpg-error was available in the recipe-sysroot directory of gnugp.
>
> libgpg-error should be added to gnupg's DEPENDS variable. Then the
> libgpg-error patch will work correctly.
>
> If this analysis is confirmed:
> Should I create a separate patch to add the dependency?
> Alternatively, someone else could do this and then the libgpg-error patch
> could be used unchanged.

Unfortunately this is not correct. DEPENDS has no relevance for
package dependencies; those are set either from RDEPENDS, or from
auto-discovery of shared library dependencies (this is done in
do_package by inspecting the binaries). Then there's code that maps
those shared library dependencies to packages that contain them.
That's why I asked you to look into packaging metadata, and I can only
repeat that:

If you have a bit of time, I'd appreciate if you narrrow it down:
inspect the metadata of the .deb packages: gnupg, and then gpg-error,
before and after the change. In other words, is the problem with apt,
or with not repackaging   gnupg properly? How does it compare to when
using rpm?

Alex

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

[-- Attachment #1: Type: text/plain, Size: 3910 bytes --]

> I have found out the following:
>
> After applying the libgpg-error patch, the gnupg deb-packages are not rebuilt.
>
> My guess is that the gnupg recipe is missing a dependency on libgpg-error.
> However, gnupg uses the shared library from libgpg-error, so this dependency
> is necessary.
>
> That the gnupg built has been successful so far is probably due to the fact that
> gnupg depends on libgcrypt and libgcrypt depends on libgpg-error. As a
> result, libgpg-error was available in the recipe-sysroot directory of gnugp.
>
> libgpg-error should be added to gnupg's DEPENDS variable. Then the
> libgpg-error patch will work correctly.
>
> If this analysis is confirmed:
> Should I create a separate patch to add the dependency?
> Alternatively, someone else could do this and then the libgpg-error patch
> could be used unchanged.

Unfortunately this is not correct. DEPENDS has no relevance for
package dependencies; those are set either from RDEPENDS, or from
auto-discovery of shared library dependencies (this is done in
do_package by inspecting the binaries). Then there's code that maps
those shared library dependencies to packages that contain them.
That's why I asked you to look into packaging metadata, and I can only
repeat that:

If you have a bit of time, I'd appreciate if you narrrow it down:
inspect the metadata of the .deb packages: gnupg, and then gpg-error,
before and after the change. In other words, is the problem with apt,
or with not repackaging   gnupg properly? How does it compare to when
using rpm?

Alex


Following insights:
gnupg depends on libgcrypt (libgcrypt is in DEPENDS)
gnupg depends on libgpg-error (libgpg-error is not in DEPENDS)
libgcrypt depends on libgpg-error (libgpg-error is in DEPENDS)

After the libgpg-error change:
The libgcrypt .deb packages were rebuilt with the correct dependency libgpg-error0.
libgcrypt  log.taskorder:
20250405-152044.315670 do_collect_spdx_deps (47077): log.do_collect_spdx_deps.47077
20250405-152044.557403 do_create_spdx (47085): log.do_create_spdx.47085
20250405-152046.094642 do_package_write_deb (47188): log.do_package_write_deb.47188
20250405-152046.783490 do_create_package_spdx (47258): log.do_create_package_spdx.47258

The gnupg .deb packages were not rebuilt.
gnupg log.taskorder:
20250405-152046.254829 do_collect_spdx_deps (47191): log.do_collect_spdx_deps.47191
20250405-152046.560586 do_create_spdx (47254): log.do_create_spdx.47254
20250405-152047.590069 do_create_package_spdx (47448): log.do_create_package_spdx.47448

gnupg does not execute the task 'do_package_write_deb'.


bitbake-dumpsig -t libgcrypt do_package_write_deb
...
Tasks this task depends on: ['dpkg-native:do_populate_sysroot', 'gcc-runtime:do_packagedata', 'glibc:do_packagedata', 'libcap:do_packagedata', 'libgcrypt:do_deploy_source_date_epoch', 'libgcrypt:do_package', 'libgcrypt:do_packagedata', 'libgpg-error:do_packagedata', 'pseudo-native:do_populate_sysroot', 'ptest-runner:do_packagedata']

bitbake-dumpsig -t gnupg do_package_write_deb
...
Tasks this task depends on: ['bzip2:do_packagedata', 'dpkg-native:do_populate_sysroot', 'gcc-runtime:do_packagedata', 'glibc:do_packagedata', 'gnupg:do_deploy_source_date_epoch', 'gnupg:do_package', 'gnupg:do_packagedata', 'gnutls:do_packagedata', 'libassuan:do_packagedata', 'libgcrypt:do_packagedata', 'libksba:do_packagedata', 'npth:do_packagedata', 'pinentry:do_packagedata', 'pseudo-native:do_populate_sysroot', 'readline:do_packagedata', 'zlib:do_packagedata']

As I understand it, the problem is not with apt but with not repackaging gnupg.
'gnupg:do_package_write_deb' is missing the dependency to 'libgpg-error:do_packagedata'.


To stay on the right track, should the code that maps these shared library dependencies
to packages that contain them also add this missing task dependency?


Regards,
Mario

[-- Attachment #2: Type: text/html, Size: 11784 bytes --]

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

On Sat, 5 Apr 2025 at 17:34, Mario Schuknecht
<Mario.Schuknecht@iris-sensing.com> wrote:

> As I understand it, the problem is not with apt but with not repackaging gnupg.
> 'gnupg:do_package_write_deb' is missing the dependency to 'libgpg-error:do_packagedata'.
>
>
> To stay on the right track, should the code that maps these shared library dependencies
> to packages that contain them also add this missing task dependency?

I do not think so, I believe apt and metadata in .deb files should be
investigated first. I went and looked into libgpg-error0 .deb control
file, and it does contain the needed Provides, but crucially, the
Provides line itself lacks version info:

Package: libgpg-error0
Version: 1.51-r0
...
Provides: libgpg-error

If you built .rpm, then the Provides does include the version info:

%package -n libgpg-error0
...
Provides: libgpg-error = 1.51

So I suspect apt gets confused somehow: either it doesn't pick up this
Provides at all, or it rejects it because the version isn't known, and
gnupg has version constraints:

Depends: gnupg-gpg, libassuan9 (>= 3.0.2), libbz2-1 (>= 1.0.8), libc6
(>= 2.41+git0+0a7c7a3e28), libgcrypt (>= 1.11.0), libgnutls30 (>=
3.8.9), libgpg-error (>= 1.51), libksba8 (>= 1.6.7), libnpth0 (>=
1.8), libreadline8 (>= 8.2.13), libz1 (>= 1.3.1)

I'm out of time to look further into this today, but maybe you can
check if we're missing something in .deb generation (compared to rpm),
particularly having version info in Provides as explained here:

https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides

Alex

AW: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Mario Schuknecht]

[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]

> 'gnupg:do_package_write_deb' is missing the dependency to 'libgpg-error:do_packagedata'.
>
>
> To stay on the right track, should the code that maps these shared library dependencies
> to packages that contain them also add this missing task dependency?

I do not think so, I believe apt and metadata in .deb files should be
investigated first. I went and looked into libgpg-error0 .deb control
file, and it does contain the needed Provides, but crucially, the
Provides line itself lacks version info:

Package: libgpg-error0
Version: 1.51-r0
...
Provides: libgpg-error

If you built .rpm, then the Provides does include the version info:

%package -n libgpg-error0
...
Provides: libgpg-error = 1.51

So I suspect apt gets confused somehow: either it doesn't pick up this
Provides at all, or it rejects it because the version isn't known, and
gnupg has version constraints:

Depends: gnupg-gpg, libassuan9 (>= 3.0.2), libbz2-1 (>= 1.0.8), libc6
(>= 2.41+git0+0a7c7a3e28), libgcrypt (>= 1.11.0), libgnutls30 (>=
3.8.9), libgpg-error (>= 1.51), libksba8 (>= 1.6.7), libnpth0 (>=
1.8), libreadline8 (>= 8.2.13), libz1 (>= 1.3.1)

I'm out of time to look further into this today, but maybe you can
check if we're missing something in .deb generation (compared to rpm),
particularly having version info in Provides as explained here:

https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.debian.org%2Fdoc%2Fdebian-policy%2Fch-relationships.html%23virtual-packages-provides&data=05%7C02%7CMario.Schuknecht%40iris-sensing.com%7C7d331cff1d704027549b08dd75c3c5c5%7C963f3913ffae43fd856b2dfd3f6604e3%7C0%7C0%7C638796205873578643%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JMn%2FbF3dKvmDYXvqXxxywyg09nY%2BQjal9vwRA9SKdIo%3D&reserved=0<https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides>

Alex

So far I understand the problem now, the "Provides:" version information
inside the .deb package is missing.

I have checked the rpm and deb class and it seems that the deb class
does not support the "Provides:" version on purpose.

There is the following code comment:
 "drop version information here, not wanted/supported by deb"
http://web.git.yoctoproject.org/poky/tree/meta/classes-global/package_deb.bbclass#n223

That comes with this commit:
https://web.git.yoctoproject.org/poky/commit/?h=00765258a2fd0627e0b8b15ed917e1caeda30b38

Should the deb class be extended by the "Provides:" version or is the problem somewhere else?

Regards,
Mario

[-- Attachment #2: Type: text/html, Size: 6650 bytes --]

Re: [OE-core] [meta-core][PATCH v2] libgpg-error: inherit lib_package

[Alexander Kanavin]

On Tue, 8 Apr 2025 at 17:12, Mario Schuknecht
<Mario.Schuknecht@iris-sensing.com> wrote:

> So far I understand the problem now, the "Provides:" version information
> inside the .deb package is missing.
>
> I have checked the rpm and deb class and it seems that the deb class
> does not support the "Provides:" version on purpose.
>
> There is the following code comment:
>  "drop version information here, not wanted/supported by deb"
> http://web.git.yoctoproject.org/poky/tree/meta/classes-global/package_deb.bbclass#n223
>
> That comes with this commit:
> https://web.git.yoctoproject.org/poky/commit/?h=00765258a2fd0627e0b8b15ed917e1caeda30b38
>
> Should the deb class be extended by the "Provides:" version or is the problem somewhere else?

Note that the commit is ten years old, and it's well possible versions
in Provides were not supported back then, but are both supported and
enforced now. Maybe you can run local experiments to confirm that?

Alex