Date   

: When compiling code, how to make a package not hash checked?

ouyangxuan10@163.com
 

Dear all,

I would like to ask the reasons for the following problems and how to solve them? When compiling a program, how to make a package not hash checked?


thanks,
Byron


 


Re: poky oe-init-build-env doesn't update local.conf with changes from local.conf.sample

 

On Tue, 10 Nov 2020 at 09:56, Andy Basey <a.basey@landguardsystems.com> wrote:

I have an existing build with packages defined in my own layer outside the build directory in the local.conf.sample
I want to add a package so I add it to my local.conf.sample and then source oe-init-build-env again
It doesn't overwrite the local.conf in poky/build/conf as it already exists

Is there a preferred way to make it update?
Or do I just need to manually delete the files in that directory and then run source oe-init-build-env?
I don't want to delete the whole build directory as it takes far too long to do it again from scratch

For reference I am using the local.conf.sample because that is my source controllable config file
If you're adding packages to an image, the best thing to do is to
create your own image recipe and put that in your layer (so it will be
under version control).

--
Paul Barker
Konsulko Group


poky oe-init-build-env doesn't update local.conf with changes from local.conf.sample

Andy Basey
 

I have an existing build with packages defined in my own layer outside the build directory in the local.conf.sample
I want to add a package so I add it to my local.conf.sample and then source oe-init-build-env again
It doesn't overwrite the local.conf in poky/build/conf as it already exists

Is there a preferred way to make it update?
Or do I just need to manually delete the files in that directory and then run source oe-init-build-env?
I don't want to delete the whole build directory as it takes far too long to do it again from scratch

For reference I am using the local.conf.sample because that is my source controllable config file


Re: Error when building eSDK for a `docker load`able tarball

Josef Holzmayr
 

Howdy!

Am Sa., 7. Nov. 2020 um 16:04 Uhr schrieb Manuel Wagesreither
<ManWag@fastmail.fm>:
ERROR: Task linux-dummy.do_fetch attempted to execute unexpectedly
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa, unihash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844, taskhash d18d2179024bc6595110c2f10112e7a8e2bd6021d3ea754af30ad9b68ebd9844
Task /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete, unihash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b, taskhash c2d86d42a7fc84df5f6ad94b3ed65f6991b3e680d99d40e07ee631aedee9970b
This is usually due to missing setscene tasks. Those missing in this build were: {'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_complete',
'/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta-manwag/recipes-core/images/bora-container.bb:do_image_qa'}
ERROR: Task (/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch) failed with exit code 'setscene whitelist'
NOTE: Tasks Summary: Attempted 142 tasks of which 141 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/sdk-ext/image/tmp-renamed-sdk/layers/poky/meta/recipes-kernel/linux/linux-dummy.bb:do_fetch
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
ERROR: Logfile of failure stored in: /data/proj/poky/build-bora-docker/tmp/work/containerx86_64-poky-linux/bora-container/1.0-r0/temp/log.do_populate_sdk_ext.8096
ERROR: Task (/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2358 tasks of which 2356 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/data/proj/poky/build-bora-docker/../meta-manwag/recipes-core/images/bora-container.bb:do_populate_sdk_ext
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
```
I can reproduce it, the issue being caused by the combination of
linux-dummy as kernel provider and the esdk. While there is no obvious
fix at the moment, Bruce (CCed) knows about it and will have a look.
Additionally it might be worth filing a bug.

Greetz


Re: Yoctoproject.org cgit tags CSS

Anders Montonen
 

Hi,

The previous change also seems to have broken the tag highlighting for the light theme.

Regards,
Anders Montonen

On 10 Nov 2020, at 10:52, Anders Montonen <Anders.Montonen@...> wrote:

Hi,

The tags now show as white text on yellow background, which is unreadable. I think you must copy "table.list td a.tag-deco” too, to set the text color.
Btw, this is probably the same as <https://bugzilla.yoctoproject.org/show_bug.cgi?id=13668>.

Regards,
Anders Montonen

On 10 Nov 2020, at 9:24, Michael Halstead <mhalstead@...> wrote:

I've copied the style into the new class name. Please let me know if this looks correct to you.

On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer







[PATCH yocto-autobuilder-helper] auh-config: add non-default distro features

Alexander Kanavin
 

This adds systemd and pam related recipes to upstream checks and devtool-driven updates.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
scripts/auh-config/local.conf.append | 1 +
1 file changed, 1 insertion(+)

diff --git a/scripts/auh-config/local.conf.append b/scripts/auh-config/local.conf.append
index 9628737..b18590f 100644
--- a/scripts/auh-config/local.conf.append
+++ b/scripts/auh-config/local.conf.append
@@ -1,3 +1,4 @@

INHERIT += "buildhistory"
LICENSE_FLAGS_WHITELIST = "commercial"
+DISTRO_FEATURES_append = ' systemd pam'
--
2.29.1


Re: Yoctoproject.org cgit tags CSS

Anders Montonen
 

Hi,

The tags now show as white text on yellow background, which is unreadable. I think you must copy "table.list td a.tag-deco” too, to set the text color.
Btw, this is probably the same as <https://bugzilla.yoctoproject.org/show_bug.cgi?id=13668>.

Regards,
Anders Montonen

On 10 Nov 2020, at 9:24, Michael Halstead <mhalstead@...> wrote:

I've copied the style into the new class name. Please let me know if this looks correct to you.

On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer





Re: Yoctoproject.org cgit tags CSS

Alexander Kanavin
 

I am not seeing a change - the tags are still not highlighted (e.g. commit on top):

This file still contains only the old name:

Alex


On Tue, 10 Nov 2020 at 08:24, Michael Halstead <mhalstead@...> wrote:
I've copied the style into the new class name. Please let me know if this looks correct to you.

On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer




Re: Yoctoproject.org cgit tags CSS

Michael Halstead
 

I've copied the style into the new class name. Please let me know if this looks correct to you.


On Mon, Nov 9, 2020 at 12:29 PM Anders Montonen <Anders.Montonen@...> wrote:
Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen




--
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer


[meta-selinux][PATCH] setools: fix build with Python 3.9

Yi Zhao
 

The Py_UNICODE_COPY, Py_UNICODE_FILL, PyUnicode_WSTR_LENGTH,
PyUnicode_FromUnicode(), PyUnicode_AsUnicode(), _PyUnicode_AsUnicode,
and PyUnicode_AsUnicodeAndSize() are marked as deprecated in Python 3.9.
(See: https://docs.python.org/3/whatsnew/3.9.html). But the current
python3-cython (0.29.21) hasn't adapt it yet.
Append '-Wno-deprecated-declarations' in CFLAGS as a workaround to fix
the build issue.

Fixes:
In file included from
/build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/unicodeobject.h:1026,
from /build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/Python.h:97,
from setools/policyrep.c:49:
/build/tmp-glibc/work/corei7-64-wrs-linux/setools/4.3.0-r0/recipe-sysroot/usr/include/python3.9/cpython/unicodeobject.h:446:26:
note: declared here
446 | static inline Py_ssize_t _PyUnicode_get_wstr_length(PyObject *op) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
setools/policyrep.c:97302:3: error: 'PyUnicode_AsUnicode' is deprecated [-Werror=deprecated-declarations]

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-security/setools/setools_4.3.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-security/setools/setools_4.3.0.bb b/recipes-security/setools/setools_4.3.0.bb
index 8fdeeb0..0f166c8 100644
--- a/recipes-security/setools/setools_4.3.0.bb
+++ b/recipes-security/setools/setools_4.3.0.bb
@@ -30,6 +30,8 @@ RDEPENDS_${PN} += "python3-networkx python3-decorator python3-setuptools \

RDEPENDS_${PN}_class-native = ""

+CFLAGS_append = " -Wno-deprecated-declarations"
+
RPROVIDES_${PN} += "${PN}-console"

inherit setuptools3
--
2.17.1


M+ & H bugs with Milestone Movements WW45

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW45 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

6437

Document how to set up the Yocto Project for production work

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M2

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.2 M4

3.3 M2

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.2 M4

3.3 M1

 

13288

pseudo should not follow symlinks in /proc

randy.macleod@...

sakib.sajal@...

3.3

3.3 M2

 

13520

many valgrind tests fail for arm64

randy.macleod@...

stacy.gaikovaia@...

3.2 M4

3.3 M1

 

13589

Document sstate cache mirror best practices

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M1

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.2 M4

3.3 M2

 

13766

Using TCLIB=musl results in SDKs producing incompatible binaries

randy.macleod@...

sakib.sajal@...

3.3

3.3 M2

 

13767

Creating PDF docs doesn't include image files

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M2

 

13904

do_prepare_recipe_sysroot: postinst-useradd-* does not run in order of dependency and sometimes fails

randy.macleod@...

sakib.sajal@...

3.3

3.3 M1

 

13997

[QA 3.2 M2 RC1] failure in ptest : libinput.libinput-test-suite

randy.macleod@...

sakib.sajal@...

3.3

3.3 M1

 

14026

documentation how to use systemd is inconsistent

randy.macleod@...

mark.morton@...

3.2 M4

3.3 M1

 

14051

[QA 3.2 M3 RC1] failure in ptest : valgrind.drd and valgrind.helgrind

randy.macleod@...

stacy.gaikovaia@...

3.2 M4

3.3 M1

 

14077

devtool doesn't handle server failing to startup gracefully

randy.macleod@...

stacy.gaikovaia@...

3.2 M4

3.3 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW45!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

ross@...

2

akuster808@...

1

randy.macleod@...

1

david.reyna@...

1

Grand Total

5

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW45 of who have open medium or higher bugs and enhancements against YP 3.3.   There are 121 possible work days left until the final release candidates for YP 3.3 needs to be released.

Who

Count

richard.purdie@...

34

ross@...

22

david.reyna@...

21

bruce.ashfield@...

19

bluelightning@...

19

timothy.t.orling@...

12

JPEWhacker@...

12

sakib.sajal@...

11

mark.morton@...

11

akuster808@...

9

trevor.gamblin@...

9

kai.kang@...

8

Qi.Chen@...

6

stacy.gaikovaia@...

5

raj.khem@...

5

randy.macleod@...

4

rpjday@...

4

mingli.yu@...

4

mostthingsweb@...

4

idadelm@...

4

chee.yang.lee@...

4

yi.zhao@...

3

alejandro@...

3

hongxu.jia@...

3

ydirson@...

3

jeanmarie.lemetayer@...

2

mark.hatle@...

2

matthewzmd@...

2

kergoth@...

2

saul.wold@...

2

jpuhlman@...

2

jaewon@...

2

jon.mason@...

2

Martin.Jansa@...

1

kai.ruhnau@...

1

jason.wessel@...

1

nicolas.dechesne@...

1

liezhi.yang@...

1

ankur.tyagi85@...

1

jbb5044@...

1

dl9pf@...

1

aehs29@...

1

kamensky@...

1

anuj.mittal@...

1

liu.ming50@...

1

apoorvsangal@...

1

joe.slater@...

1

fede@...

1

maxime.roussinbelanger@...

1

mhalstead@...

1

kexin.hao@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 325 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


cipd ensure -log-level error -root

yuvaraj.velumani@...
 

Hi, 

I am getting the below error messages when trying to build meta-flutter.

Error: Command 'cipd ensure -log-level error -root -ensure-file /tmp/tmpHyUQvg.ensure' returned non-zero exit status 2
- wget: --user-agent: Invalid value ‘depot_tools/HEAD\n???’.
CalledProcessError: Command 'git -c core.deltaBaseCacheLimit=2g clone --no-checkout --progress git@...:flutter/engine.git


#devtool #toolchain #yocto #warning #toolchain #yocto #warning #devtool

yuvaraj.velumani@...
 

Hi,

I am trying to use meta-flutter to my Renesas R-Car build environment.
I get the below error, can anyone help me. I am not sure if it is network issue or I need to do add/remove additional configurations.

 

Thanks in advance


Yoctoproject.org cgit tags CSS

Anders Montonen
 

Hi,

Since some time, the tags in the log view of yoctoproject.org’s cgit have not been highlighted correctly. The problem seems to be that in the HTML, tags are given the class “tag-annotated-deco”, which doesn’t exist in the CSS. The CSS does have a “tag-deco” style which is probably what’s intended.

Regards,
Anders Montonen


Re: [PATCH 1/1] openssl: Add c_rehash to misc package and add perl runtime dependency - resend...

Randy MacLeod
 

Resend to get Stephen's correct email address.

On 2020-10-19 11:29 p.m., Federico Pellegrin wrote:

Sorry, new to the process, adding the pull URL here:

https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=fedepell/bug14083

Cheers,
F.
Hi Federico,

Sorry for the delay. We've been getting the 3.2 release out the door
and participating in conferences.

Please rebase to openssl_1.1.1h and send it to the oe-core list:
openembedded-core@lists.openembedded.org

See: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded


We really should have a link to that site on a "Developers" page on https://www.yoctoproject.org

Stephen Jolly, can you get that to happen and if not, who can?

../Randy


Il giorno mar 20 ott 2020 alle ore 05:27 Federico Pellegrin <fede@evolware.org <mailto:fede@evolware.org>> ha scritto:


c_rehash implemented in perl is back (in history was moved to
shell for
some time), so handle it inside the -misc package so just that one
will
carry the heavy runtime dependency on perl and not the whole openssl
package. Note: in misc there were already before a few perl files
(tsget.pl <http://tsget.pl> and CA.pl) so the added perl
dependency will fix those too.

[YOCTO #14083]

Signed-off-by: Federico Pellegrin <fede@evolware.org
<mailto:fede@evolware.org>>
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
<http://openssl_1.1.1g.bb> | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
<http://openssl_1.1.1g.bb>
b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
<http://openssl_1.1.1g.bb>
index 815955837b..66d8851426 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
<http://openssl_1.1.1g.bb>
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
<http://openssl_1.1.1g.bb>
@@ -195,13 +195,14 @@ FILES_openssl-conf =
"${sysconfdir}/ssl/openssl.cnf \
                       ${libdir}/ssl-1.1/openssl.cnf* \
                       "
 FILES_${PN}-engines = "${libdir}/engines-1.1"
-FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
+FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
 FILES_${PN} =+ "${libdir}/ssl-1.1/*"
 FILES_${PN}_append_class-nativesdk = "
${SDKPATHNATIVE}/environment-setup.d/openssl.sh"

 CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"

 RRECOMMENDS_libcrypto += "openssl-conf"
+RDEPENDS_${PN}-misc = "perl"
 RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash"

 RDEPENDS_${PN}-bin += "openssl-conf"
--
2.26.2




--
# Randy MacLeod
# Wind River Linux


Re: [PATCH 1/1] openssl: Add c_rehash to misc package and add perl runtime dependency

Randy MacLeod
 

On 2020-10-19 11:29 p.m., Federico Pellegrin wrote:

Sorry, new to the process, adding the pull URL here:


Cheers,
F.

Hi Federico,

Sorry for the delay. We've been getting the 3.2 release out the door
and participating in conferences.

Please rebase to openssl_1.1.1h and send it to the oe-core list:
   openembedded-core@...

See:  https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded


We really should have a link to that site on a "Developers" page on https://www.yoctoproject.org

Stephen Jolly, can you get that to happen and if not, who can?

../Randy


Il giorno mar 20 ott 2020 alle ore 05:27 Federico Pellegrin <fede@...> ha scritto:

c_rehash implemented in perl is back (in history was moved to shell for
some time), so handle it inside the -misc package so just that one will
carry the heavy runtime dependency on perl and not the whole openssl
package. Note: in misc there were already before a few perl files
(tsget.pl and CA.pl) so the added perl dependency will fix those too.

[YOCTO #14083]

Signed-off-by: Federico Pellegrin <fede@...>
---
 meta/recipes-connectivity/openssl/openssl_1.1.1g.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
index 815955837b..66d8851426 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1g.bb
@@ -195,13 +195,14 @@ FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf \
                       ${libdir}/ssl-1.1/openssl.cnf* \
                       "
 FILES_${PN}-engines = "${libdir}/engines-1.1"
-FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
+FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
 FILES_${PN} =+ "${libdir}/ssl-1.1/*"
 FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
 
 CONFFILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
 
 RRECOMMENDS_libcrypto += "openssl-conf"
+RDEPENDS_${PN}-misc = "perl"
 RDEPENDS_${PN}-ptest += "openssl-bin perl perl-modules bash"
 
 RDEPENDS_${PN}-bin += "openssl-conf"
--
2.26.2







-- 
# Randy MacLeod
# Wind River Linux


Re: [gtk+3][zeus] building only with wayland backend, no x11

Alexander Kanavin
 

Do you actually need gtk+3 in your image?

There is a poky configuration that builds core-image-weston without x11, and core-image-weston does pull in gtk+3, and all that happens without errors:
so I'd suggest you reproduce that, get it to build, then investigate where your build diverges.

Alex


On Mon, 9 Nov 2020 at 14:10, Adrian <adrian.fiergolski@...> wrote:

Hi,

I am building an image based on core-image-weston.

I would like to use only wayland backend, thus I defined in my machine's configuration:

DISTRO_FEATURES_append = " wayland"
DISTRO_FEATURES_remove = " x11"

I have a problem with build of gtk+3:

| checking for pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7... no
| configure: error: Package requirements (pango pangocairo gdk-pixbuf-2.0 >= 2.30.0 cairo >= 1.14.0 cairo-gobject >= 1.14.0 gio-unix-2.0 >= 2.53.4  wayland-client >= 1.9.91 wayland-protocols >= 1.12 xkbcommon >= 0.2.0 wayland-cursor >= 1.9.91 wayland-egl   cairo epoxy >= 1.4  fribidi >= 0.19.7) were not met:
|
| Package 'x11', required by 'gl', not found

The configuration flags in config.log seems to be ok:

  $ ../gtk+-3.24.8/configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/afiergol/fastree/falcon/poky/build/tmp/work/aarch64-poky-linux/gtk+3/3.24.8-r0/recipe-sysroot --enable-introspection --disable-gtk-doc --disable-glibtest --disable-xinerama --enable-modules --disable-colord --disable-gtk-doc --disable-static --disable-cups --disable-glx --enable-opengl --enable-wayland-backend --disable-x11-backend --enable-nls

Has anybody else experience similar issue? Do you know a fix? I work with the latest zeus (d88d62c20d7d8da85f02edb170dae0280624ad7e) version.

Regards,

Adrian





2941 - 2960 of 54255