Date   

Yocto Project Status WW28'20

Stephen Jolley
 

Current Dev Position: YP 3.2 M2

Next Deadline: YP 3.2 M2 build date 2020/7/27

 

Next Team Meetings:

 

Key Status/Updates:

  • A key autobuilder race has been identified as a race around the bitbake lock file which will hopefully continue to reduce the number of intermittent failures being seen. It potentially explains a number of the open bugs. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT
  • We are struggling with maintainers for some key components of the system/infrastructure such as devtool, wic, buildhistory and patchwork/patchtest. If anyone can help in these areas please contact Richard.
  • Another way to help the project is to help us with bugs that are currently unassigned but ideally needed during 3.2. See: https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.2_Unassigned_Enhancements.2FBugs
  • We’re planning to migrate the project documentation from docbook to sphinx. If you’re interested/able to help with this please join the discussion over on the docs mailing list.

 

YP 3.2 Milestone Dates:

  • YP 3.2 M2 build date 2020/7/27
  • YP 3.2 M2 Release date 2020/8/7
  • YP 3.2 M3 build date 2020/8/31
  • YP 3.2 M3 Release date 2020/9/11
  • YP 3.2 M4 build date 2020/10/5
  • YP 3.2 M4 Release date 2020/10/30

 

Planned upcoming dot releases:

  • YP 3.0.4 build date 2020/8/10
  • YP 3.0.4 release date 2020/8/21
  • YP 3.1.2 build date 2020/9/14
  • YP 3.1.2 release date 2020/9/25

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Query regarding the use of wic image during device upgrades

Riz
 

Hi,
 
I have been using wic image format lately to create partitioned image for my device.
I was wondering if wic image format can also be used during the device upgrade scenarios?
 
After using wic image, I have an impression that it is mainly used for initially writing the wic image to sdcard/eMMC but does not support all the thinkable use cases related to device upgrade.
 
As in, for example, can we selectively upgrade any single partition in the device using the wic image?
It would be really helpful if I can get some references or pointers on this topic.
 
Thanks.


Re: Stable Warrior branch

Adrian Bunk
 

On Thu, Jun 04, 2020 at 09:28:00PM -0700, akuster wrote:
Hello,

The Warrior branch of Poky has had its last official dot release. It
will be moving to Community support and EOL within 6 weeks if no one
steps up.
If someone is interested in taking on the responsibilities of
maintaining the "Warrior" branch moving forward, please email this list.
I have an interest in keeping warrior branch alive in poky and meta-oe,
and I'll take this responsibility since noone else seems to be interested.

Please look at the
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS for what will
be expected.
I have some ideas, but not yet a fixed plan how I will set this up.

regards,
Armin
cu
Adrian


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

Thanks why I did not think of that. Anyway it works so thanks again.

BR

Den tis 14 juli 2020 kl 14:12 skrev <Mikko.Rapeli@bmw.de>:


Hi,

On Tue, Jul 14, 2020 at 02:08:37PM +0200, Mans Zigher wrote:
I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?
You can try with SRC_URI_prepend_machine1.

Cheers,

-Mikko


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mikko Rapeli
 

Hi,

On Tue, Jul 14, 2020 at 02:08:37PM +0200, Mans Zigher wrote:
I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?
You can try with SRC_URI_prepend_machine1.

Cheers,

-Mikko


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

I figured it out the problem was that in meta-layer1 we had
SRC_URI_append_machine1 += "file://0001-patch-one.patch" this
apparently will always be added to the end of SRC_URI list and
thereby the meta-layer2 patches will be applied first. Is it possible
to get machine specific patches applied first?

BR

Den tis 14 juli 2020 kl 13:29 skrev zigext <mans.zigher@gmail.com>:


I have debugged cooker.py and everything looks good it produces a list
of the bbappend files that matches the expected result so something is
screwing it up when the recipe is baked since I can see that the order
is wrong when dumping the environment for the virtual/kernel.

BR

Den tis 14 juli 2020 kl 11:21 skrev zigext <mans.zigher@gmail.com>:

Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

BR


Re: meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

I have debugged cooker.py and everything looks good it produces a list
of the bbappend files that matches the expected result so something is
screwing it up when the recipe is baked since I can see that the order
is wrong when dumping the environment for the virtual/kernel.

BR

Den tis 14 juli 2020 kl 11:21 skrev zigext <mans.zigher@gmail.com>:


Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

BR


meta layers priority using BBFILE_PRIORITY in layer.conf is not working for me?

Mans Zigher <mans.zigher@...>
 

Hi,

I am using thud for my distro and I have two bbappend for my kernel I
need to make sure that meta-layer1 is parsed before meta-layer2 to get
the patches applied in the right order. So the patches in meta-layer2
need to be applied after meta-layer1 patches have been applied. I have
adjusted the BBFILE_PRIORITY accordingly so layer1 has 1120 and layer2
has 1110 based on "A larger value for the BBFILE_PRIORITY variable
results in a higher precedence." but whatever I do I am still getting
the wrong order and do_patch is failing. Any pointers to what I am
doing wrong? I must be doing something wrong that is preventing the
BBFILE_PRIORITY in my layer.conf to have an effect. Running
"bitbake-layers show-layers" shows the expected output but when
running the do_patch it is wrong and when dumping the env using
"bitbake -e virtual/kernel" it is clear the order is wrong.

BR


Re: Linker error undefined reference to `_rtld_global_ro'

Robert Varga
 

Thank you very much for your response.

it seems static apps with glibc compiled with PIE related.
I'm afraid I didn't understand (as I am new to yocto and try to understand it). Did you mean, the following statement in my-image.bb file generates the static apps which is not a good approach?
SDKIMAGE_FEATURES_append = " staticdev-pkgs"

I introduced this statement because I got linking errors when compiling/linking using the SDK complaining about missing libs just like ...
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lpthread
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -ldl
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lstdc++
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lm
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: cannot find -lc
collect2: error: ld returned 1 exit status
makefile:128: recipe for target 'arm' failed
make: *** [arm] Error 1

When using this statement (SDKIMAGE_FEATURES_append = " staticdev-pkgs") I can see in /opt/mydistro/1.0.0/sysroots/usr/lib many *.a files which are not present without this statement. But I am not sure if this statement is correct? Maybe there is another approach for including the missing libs?

And what do you mean with "PIE related"? Are you thinking of an Raspberri PI?

Can you verfiy if you get same issue with aarch64 or mips ?
Also I would like to verify, but do not know how to setup for aarch64 or mips. Can you provide a short example?

Thank you for your support.

--

Rob


[meta-security][master|dunfell][PATCH 2/2] packagegroup-security-tpm2: Depend on preferred provider for cryptsetup

Jeremy Puhlman
 

From: Jeremy Puhlman <jpuhlman@mvista.com>

Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
---
meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
index 8f5c537..a553a63 100644
--- a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
+++ b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
@@ -7,6 +7,7 @@ inherit packagegroup

PACKAGES = "${PN}"

+PREFERRED_PROVIDER_cryptsetup ?= "cryptsetup-tpm-incubator"
SUMMARY_packagegroup-security-tpm2 = "Security TPM 2.0 support"
RDEPENDS_packagegroup-security-tpm2 = " \
tpm2-tools \
@@ -19,5 +20,5 @@ RDEPENDS_packagegroup-security-tpm2 = " \
tpm2-abrmd \
tpm2-pkcs11 \
ibmswtpm2 \
- cryptsetup-tpm-incubator \
+ ${PREFERRED_PROVIDER_cryptsetup} \
"
--
1.8.2.3


[meta-security][master|dunfell][PATCH 1/2] cryptsetup-tpm-incubator: RPROVIDES cryptsetup and cryptsetup-dev

Jeremy Puhlman
 

From: Jeremy Puhlman <jpuhlman@mvista.com>

Without this we get weird conflict when you include dev packages:
rror: Transaction check error:
file /usr/include/libcryptsetup.h conflicts between attempted installs of
cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
lib32-cryptsetup-dev-2.3.2-r0.1.i586
file /usr/lib64/libcryptsetup.so conflicts between attempted installs of
cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
cryptsetup-dev-2.3.2-r0.1.corei7_64
file /usr/lib64/pkgconfig/libcryptsetup.pc conflicts between attempted
installs of cryptsetup-tpm-incubator-dev-0.9.9-r0.corei7_64 and
cryptsetup-dev-2.3.2-r0.1.corei7_64
file /usr/lib/libcryptsetup.so conflicts between attempted installs of
lib32-cryptsetup-tpm-incubator-dev-0.9.9-r0.i586 and
lib32-cryptsetup-dev-2.3.2-r0.1.i586
file /usr/lib/pkgconfig/libcryptsetup.pc conflicts between attempted installs
of lib32-cryptsetup-tpm-incubator-dev-0.9.9-r0.i586 and
lib32-cryptsetup-dev-2.3.2-r0.1.i586

Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
---
.../cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb b/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
index b706d15..2617162 100644
--- a/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
+++ b/meta-tpm/recipes-tpm2/cryptsetup-tpm-incubator/cryptsetup-tpm-incubator_0.9.9.bb
@@ -36,7 +36,12 @@ FILES_${PN} += "${libdir}/tmpfiles.d"
RDEPENDS_${PN} += "lvm2 libdevmapper"
RRECOMMENDS_${PN} += "lvm2-udevrules"

+RPROVIDES_${PN} = "cryptsetup"
RREPLACES_${PN} = "cryptsetup"
RCONFLICTS_${PN} ="cryptsetup"

+RPROVIDES_${PN}-dev = "cryptsetup-dev"
+RREPLACES_${PN}-dev = "cryptsetup-dev"
+RCONFLICTS_${PN}-dev ="cryptsetup-dev"
+
BBCLASSEXTEND = "native nativesdk"
--
1.8.2.3


M+ & H bugs with Milestone Movements WW28

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11766

nobody group added by systemd sysusers.d

yi.zhao@...

yi.zhao@...

3.2 M1

3.2 M2

 

12937

Consistent naming scheme for deployed artifacts

randy.macleod@...

Martin.Jansa@...

3.2 M1

3.2 M2

 

12963

nativesdk-opkg prefixes all internal paths with $SDKPATH and won't work

randy.macleod@...

unassigned@...

3.2 M1

3.2 M2

 

13016

How to run our test suites for boards like beaglebone remotely on a LAVA board farm?

randy.macleod@...

limon.anibal@...

3.2 M1

3.99

 

13071

Multiconfig builds may try to execute events that don't exist for them

randy.macleod@...

alejandro@...

3.2 M1

3.2 M2

 

13229

ttm_bo_vm_open kernel warning

randy.macleod@...

jon.mason@...

3.2 M1

3.2 M2

 

13230

Switch qemuarm (another others) to virtio graphics

randy.macleod@...

jon.mason@...

3.2 M1

3.2 M2

 

13374

Determine 32bit guest support on arm64

randy.macleod@...

jon.mason@...

3.2 M1

3.2 M2

 

13533

Devtool finish on _git package with SRCPV in PV points to wrong WORKDIR

randy.macleod@...

jaewon@...

3.2 M1

3.2 M2

 

13527

Add SPDX license headers to all source files for layerindex-web

randy.macleod@...

amber.n.elliot@...

3.2 M1

3.2 M2

 

13529

Add SPDX license headers to all source files for prelink-cross

randy.macleod@...

newcomer@...

3.2 M1

3.2 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW28!

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

5

jpuhlman@...

3

randy.macleod@...

2

chee.yang.lee@...

1

ross@...

1

mingli.yu@...

1

Grand Total

13

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.2

Stephen Jolley
 

All,

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

Who

Count

david.reyna@...

10

mark.morton@...

9

ross@...

7

bluelightning@...

7

richard.purdie@...

7

Qi.Chen@...

5

michael@...

5

raj.khem@...

3

rpjday@...

3

JPEWhacker@...

2

randy.macleod@...

2

sakib.sajal@...

2

mark.hatle@...

2

trevor.gamblin@...

2

mostthingsweb@...

2

kergoth@...

2

dl9pf@...

2

yi.zhao@...

2

timothy.t.orling@...

2

kai.kang@...

2

maxime.roussinbelanger@...

1

alejandro@...

1

chee.yang.lee@...

1

liu.ming50@...

1

matthew.zeng@...

1

kai.ruhnau@...

1

naveen.kumar.saini@...

1

hongxu.jia@...

1

bruce.ashfield@...

1

jpuhlman@...

1

matt.ranostay@...

1

jaewon@...

1

changqing.li@...

1

Grand Total

91

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

 

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 341 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.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”.

 

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@...

 


Re: [ptest-runner][PATCH v2] Fix inappropriate ioctl when detaching tty

Anibal Limon
 

Applied, Thanks!.

Anibal

On Fri, 10 Jul 2020 at 00:44, Tero Kinnunen <tero.kinnunen@...> wrote:
Fixes error

    ERROR: Unable to detach from controlling tty, Inappropriate ioctl for device

when running multiple ptests

    ptest-runner a b

or when invoked over ssh single command, like

    $ ssh localhost ptest-runner

For ssh case, fd 0 is not a tty. (isatty(0) is false).
When running multiple ptests, deattach for parent needs to be
done only once.

Signed-off-by: Tero Kinnunen <tero.kinnunen@...>
---
 utils.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/utils.c b/utils.c
index a8ba190..a4e190e 100644
--- a/utils.c
+++ b/utils.c
@@ -437,6 +437,9 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
                        break;
                }
                fprintf(fp, "START: %s\n", progname);
+               if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) {
+                       fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
+               }
                PTEST_LIST_ITERATE_START(head, p)
                        char *ptest_dir = strdup(p->run_ptest);
                        if (ptest_dir == NULL) {
@@ -444,9 +447,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
                                break;
                        }
                        dirname(ptest_dir);
-                       if (ioctl(0, TIOCNOTTY) == -1) {
-                               fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
-                       }

                        if ((pgid = getpgid(0)) == -1) {
                                fprintf(fp, "ERROR: getpgid() failed, %s\n", strerror(errno));
--
2.25.1


Re: Linker error undefined reference to `_rtld_global_ro'

Khem Raj
 

On 7/13/20 4:21 AM, Robert Varga wrote:
Hello,
I am new to the Yocto project and need some help in solving a linker issue when compiling/linking an application using the SDK. It seems, that the compilation is completed, but the linker could not resolve to "_rtld_global_ro". Here is the output of the last stage
<snip>
...
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: /opt/mydistro/1.0.0/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libc.a(getcontext.o): in function `getcontext':
/usr/src/debug/glibc/2.29-r0/git/stdlib/../sysdeps/unix/sysv/linux/arm/getcontext.S:101: undefined reference to `_rtld_global_ro'
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: /opt/mydistro/1.0.0/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libc.a(setcontext.o): in function `__startcontext':
/usr/src/debug/glibc/2.29-r0/git/stdlib/../sysdeps/unix/sysv/linux/arm/setcontext.S:100: undefined reference to `_rtld_global_ro'
collect2: error: ld returned 1 exit status
makefile:116: recipe for target 'ortable' failed
make: *** [ortable] Error 1
</snip>
What I can see from the output is, that both getcontext.S and setcontext.S are referencing to "_rtld_global_ro". What I do not understand is, why the glibc is located in the debug folder? Is this probably the issue?
it seems static apps with glibc compiled with PIE related. Can you verfiy if you get same issue with aarch64 or mips ?

I have sourced the SDK using following command:
source /opt/mydistro/1.0.0/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi
Here's image bb file (which I have used for building the SDK using this command (bitbake my-image -c populate_sdk).
require recipes-extended/images/core-image-full-cmdline.bb
IMAGE_INSTALL_append = " \
    emmy-w1-driver-sdiosdio \
    emmy-w1-systemd \
    eth-systemd \
    can-systemd \
    can-utils \
    lighttpd \
    dnsmasq \
    parted \
    swupdate \
    swupdate-www \
    u-boot-fw-utils \
    linux-firmware-imx-sdma-imx6q \
    "
TOOLCHAIN_HOST_TASK_append = " nativesdk-perl-modules"
SDKIMAGE_FEATURES_append = " staticdev-pkgs"
Any help on resolving this issue would be greatly appreciated.
Thanks.
--
Rob


Re: [poky] python-setuptools dependency loops error #yocto #python

Khem Raj
 

On 7/13/20 2:04 AM, Bel Hadj Salem Talel wrote:
Hi all,
I have a problem using *python-setuptools* with yocto when bitbaking any recipe that inherits *setuptools* , or even when I execute "bitbake setuptools"
but there is no problem with setuptools3, but I need to use python2 for now.
perhaps you can see if commit [1] helps and if sumo already has it then there might be something else going on

[1] https://git.openembedded.org/openembedded-core/commit/?id=3e3c5cc579482041f0233e3e03ace736b62fb364

Here is the log:
------------------------------
*ERROR: 176 unbuildable tasks were found.
########################################## | ETA:  0:00:00*
*These are usually caused by circular dependencies and any circular dependency chains found will be printed below. Increase the debug level to see a list of unbuildable tasks.*
*Identifying dependency loops (this may take a short while)...*
*ERROR: *
*Dependency loop #1 found:*
*  Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_compile (dependent Tasks ['python-setuptools_40.0.0.bb:do_configure'])*
*  Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_install (dependent Tasks ['python-setuptools_40.0.0.bb:do_compile'])*
*  Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_populate_sysroot (dependent Tasks ['python-setuptools_40.0.0.bb:do_install'])*
*  Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_prepare_recipe_sysroot (dependent Tasks ['python-setuptools_40.0.0.bb:do_populate_sysroot', 'python-native_2.7.15.bb:do_populate_sysroot', 'python-setuptools_40.0.0.bb:do_fetch'])*
*  Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_configure (dependent Tasks ['python-setuptools_40.0.0.bb:do_prepare_recipe_sysroot', 'python-setuptools_40.0.0.bb:do_patch'])*
*ERROR: Command execution failed: 1
*------------------------------
Thansk, Talel


Updating to Zeus with zcu102

Emily
 

Hi all - 

I am in the process of attempting to update from rocko -> zeus, which is perhaps a bit ambitious considering I'm skipping quite a few releases. 

I have a custom layer here: and was able to build core-image-minimal with rocko as well as a custom image (core-image-gfex) for the xilinx zcu102 board. Unfortunately after switching all the repos to zeus I can't get core-image-minimal to build for the zcu102.

I've attached the full log, but I seem to be getting an error with the u-boot and/or pmu build: 

Cannot read ../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-pmu.bin

And then also with the spl: 

/local/d6/easmith5/zeus_bitbake/poky/build/tmp/work/zcu102_zynqmp-poky-linux/u-boot-xlnx/v2019.01-xilinx-v2019.2+gitAUTOINC+dc61275b1d-r0/git/Makefile:1653: recipe for target 'spl/u-boot-spl' failed             make[1]: *** [spl/u-boot-spl] Error 2 

Am I missing something obvious in terms of building with an existing image and existing machine conf with zeus? 

Thanks,
Emily Smith


Linker error undefined reference to `_rtld_global_ro'

Robert Varga
 

Hello,

I am new to the Yocto project and need some help in solving a linker issue when compiling/linking an application using the SDK. It seems, that the compilation is completed, but the linker could not resolve to "_rtld_global_ro". Here is the output of the last stage
<snip>
...
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: /opt/mydistro/1.0.0/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libc.a(getcontext.o): in function `getcontext':
/usr/src/debug/glibc/2.29-r0/git/stdlib/../sysdeps/unix/sysv/linux/arm/getcontext.S:101: undefined reference to `_rtld_global_ro'
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: /opt/mydistro/1.0.0/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libc.a(setcontext.o): in function `__startcontext':
/usr/src/debug/glibc/2.29-r0/git/stdlib/../sysdeps/unix/sysv/linux/arm/setcontext.S:100: undefined reference to `_rtld_global_ro'
collect2: error: ld returned 1 exit status
makefile:116: recipe for target 'ortable' failed
make: *** [ortable] Error 1
</snip>

What I can see from the output is, that both getcontext.S and setcontext.S are referencing to "_rtld_global_ro". What I do not understand is, why the glibc is located in the debug folder? Is this probably the issue?

I have sourced the SDK using following command:
source /opt/mydistro/1.0.0/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi

Here's image bb file (which I have used for building the SDK using this command (bitbake my-image -c populate_sdk).

require recipes-extended/images/core-image-full-cmdline.bb
 
IMAGE_INSTALL_append = " \
    emmy-w1-driver-sdiosdio \
    emmy-w1-systemd \
    eth-systemd \
    can-systemd \
    can-utils \
    lighttpd \
    dnsmasq \
    parted \
    swupdate \
    swupdate-www \
    u-boot-fw-utils \
    linux-firmware-imx-sdma-imx6q \
    "
 
TOOLCHAIN_HOST_TASK_append = " nativesdk-perl-modules"
SDKIMAGE_FEATURES_append = " staticdev-pkgs"
 
Any help on resolving this issue would be greatly appreciated.

Thanks.
--

Rob

3521 - 3540 of 53454