| Message ID | 20250321151245.21227-1-mario.schuknecht@iris-sensing.com |
|---|---|
| State | New |
| Headers | show |
| Series | [meta-core,v2] libgpg-error: inherit lib_package | expand |
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!
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
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
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] > -=-=-=-=-=-=-=-=-=-=-=- >
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
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
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
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
> 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
> 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
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
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
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
> 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
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
> '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
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
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"
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(-)