Date   

[meta-gplv2] [PATCH 2/3] disable-gplv3.inc: Disable glib-2.0 ptest python3-dbusmock dependency

Richard Purdie
 

The newly added dependency on python3-dbusmock in OE-Core is GPLv3
and would fail to work with this layer. Remove it in the config
for enabling the layer.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
conf/distro/include/disable-gplv3.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/distro/include/disable-gplv3.inc b/conf/distro/include/disable-gplv3.inc
index 45834b7..761be7d 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,2 +1,3 @@
INCOMPATIBLE_LICENSE = '*GPLv3'
WARN_QA_remove = 'incompatible-license'
+RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
--
2.25.1


[meta-gplv2] [PATCH 1/3] conf/distro: Add disable-gplv3.inc

Richard Purdie
 

We're finding meta-gplv2 needs configuration to work as intended. Rather
than teaching this to things like the project autobuilder, collect
the configuration inside an include file in the layer itself which
everyone can either use directly or refer to.

Initial population is from the autobuilder config currently used for
testing meta-gplv2.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
conf/distro/include/disable-gplv3.inc | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 conf/distro/include/disable-gplv3.inc

diff --git a/conf/distro/include/disable-gplv3.inc b/conf/distro/include/disable-gplv3.inc
new file mode 100644
index 0000000..45834b7
--- /dev/null
+++ b/conf/distro/include/disable-gplv3.inc
@@ -0,0 +1,2 @@
+INCOMPATIBLE_LICENSE = '*GPLv3'
+WARN_QA_remove = 'incompatible-license'
--
2.25.1


[PATCH 2/2] disable-gplv3.inc: Disable glib-2.0 ptest python3-dbusmock dependency

Richard Purdie
 

The newly added dependency on python3-dbusmock in OE-Core is GPLv3
and would fail to work with this layer. Remove it in the config
for enabling the layer.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
conf/distro/include/disable-gplv3.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/distro/include/disable-gplv3.inc b/conf/distro/include/disable-gplv3.inc
index 45834b7..761be7d 100644
--- a/conf/distro/include/disable-gplv3.inc
+++ b/conf/distro/include/disable-gplv3.inc
@@ -1,2 +1,3 @@
INCOMPATIBLE_LICENSE = '*GPLv3'
WARN_QA_remove = 'incompatible-license'
+RDEPENDS_${PN}-ptest_remove_pn-glib-2.0 = "python3-dbusmock"
--
2.25.1


[PATCH 1/2] conf/distro: Add disable-gplv3.inc

Richard Purdie
 

We're finding this layer needs configuration to work as intended. Rather
than teaching this to things like the project autobuilder, collect
the configuration inside an include file in the layer itself which
everyone can either use directly or refer to.

Initial population from the autobuilder config used for this
testing this layer.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
conf/distro/include/disable-gplv3.inc | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 conf/distro/include/disable-gplv3.inc

diff --git a/conf/distro/include/disable-gplv3.inc b/conf/distro/include/disable-gplv3.inc
new file mode 100644
index 0000000..45834b7
--- /dev/null
+++ b/conf/distro/include/disable-gplv3.inc
@@ -0,0 +1,2 @@
+INCOMPATIBLE_LICENSE = '*GPLv3'
+WARN_QA_remove = 'incompatible-license'
--
2.25.1


BSP layer for Firecracker: Launch point #linux #yocto

mark@...
 

Hi,
Following up on my earlier email; it seems that a BSP layer targeting the Firecracker VM model could/should pay some dividends.

Recapping the Firecracker 'board' model is: "only 5 emulated devices are available: virtio-net, virtio-block, virtio-vsock, serial console, and a minimal keyboard controller used only to stop the microVM"

Does any one know of a conceptually similar BSP layer, or any other that could serve as a launch point?

Kind regards
Mark


oddities(?) when appending to an override

Robert P. J. Day
 

in aid of torturing myself, i'm poring over the bitbake manual and i
recall the initial confusion i had when reading the section on
overrides and appends, especially section 3.3.3 which turns things
around by showing what happens when applying an append to an override,
as opposed to the other way around. here's what i mean, and why i
think there are a few issues in the code base.

i'm building a core-image-minimal for a qemuarm64, so there are two
overrides in play i care about: "qemuall" and "qemuarm64". now watch
what happens when i do things normally. i add this to local.conf:

RDAY = "first"
RDAY_append = " second"
RDAY_append_qemuarm64 = " third"
RDAY_append_qemuall = " fourth"

unsurprisingly, when i run "bitbake -e", i see exactly what i expect:

RDAY="first second third fourth"

this was entirely predictable, and the way i like to think about this
is that there is exactly one variable in play -- RDAY -- and all those
operations are working on that one variable. so far, so good.

now let's flip things around and apply the appends to the overrides:

RDAY = "first"
RDAY_append = " second"
RDAY_qemuarm64_append = " third"
RDAY_qemuall_append = " fourth"

bonus points if you can guess what RDAY is set to in the above.
perhaps unexpectedly, what you get is:

RDAY=" third second"

the way i interpret this (based on that section from the BB manual) is
that, in the above, there are *three* variables being worked on:

* RDAY
* RDAY_qemuall
* RDAY_qemuarm64

the append operations are being applied to those respective variables,
after which it is determined which of the overrides has precedence (in
this case, "qemuarm64"), so the value in RDAY_qemuarm64 is assigned to
RDAY, whereupon the final "normal" append (RDAY_append) is processed,
giving a final value of " third second".

and why do i care? because i don't think there's enough caution for
new developers about the significant difference between those two ways
of doing things; that is, a developer might not realize the result of
doing something like this, thinking it's the right way to do it:

VAR = "first stuff"
VAR_<override>_append = " more stuff"

where VAR will quietly end up with the value " more stuff".

i bring this up because i've run across occasional examples of that
in the code base -- here's
meta-gnome/recipes-connectivity/libnma/libnma_1.8.28.bb:

EXTRA_OEMESON_mipsarchn32_append = " -Dvapi=false"

is that deliberate, or is it just asking for trouble?

rday

p.s. there's more examples of that.

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: [WIC] Multiple WKS Files

Joshua Watt
 


On 5/4/20 11:14 AM, Rudolf J Streif wrote:


On 5/2/20 2:47 PM, Joshua Watt wrote:


On Sat, May 2, 2020, 1:22 PM Rudolf J Streif <rudolf.streif@...> wrote:
eMMC devices commonly have three hardware partitions: two boot
partitions and a user partition. I was looking for a convenient way to
have wic build an image for the boot partition and one for the user
partition. However, that does not seem to be possible right out of the
box. The variable WKS_FILE only accepts one file and not a list. The
class image_types_wic.bbclass uses WKS_FILES internally but that seems
to be a search list and the code only builds the file it finds first.

I think part of the problem is that wks files are tied to a rootfs image, so it's not currently possible to have multiple because there is no way to differentiate them. Also because of that it's a little odd to have a wks file that doesn't reference the rootfs it's built with.

You might be able to do it by making a simple dummy image recipe for the boot partition(s), then overriding the WKS_FILE variable for the image with a pn override in the machine.conf file (e.g. WKS_FILE_pn-my-emmc-boot = "emmc-boot.wks" )

Thank you, Joshua. I might try your idea. I have noticed that it is tied to the rootfs as I tried to use ondisk/ondrive to create images for different partitions. But that did not work. Actually, the use of the ondisk/ondrive parameter is not entirely obvious to me (but I also have not dissected the code to figure it out).

I haven't used it a whole lot because of the way we provision our devices, but I think its mostly so that wic can create a valid fstab in the root file system that will mount all the partitions. This way, the root file system image can remain generic and work with different partitions layouts specified in the wks file.

It might be worthwhile looking into enhancing wic to be able to create multiple images. Devices now also use universal flash storage (UFS) which supports multiple logical disks like a SCSI drive once it is provisioned.

Yes, that would be really nice. I don't think that wic currently has any concept of "hardware partitions" (e.g. the emmc boot partitions or the UFS SCSI LUNs), just GPT/MBR partitions. I'm not sure how you would add support for it.




Is my understanding correct?

Any smart ideas to make this work?

Thanks,
Rudi






-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


    


Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Stephen Jolley
 

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (5/5) 

 

Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

When            Monthly from 8am to 8:30am on the first Tuesday Pacific Time

Where           Zoom Meeting: https://zoom.us/j/990892712

 

We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them.  The world should have view access.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


M+ & H bugs with Milestone Movements WW18

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13459

sdk: compiler targets glibc, even though rootfs uses musl-libc

randy.macleod@...

randy.macleod@...

3.1 M4

3.2 M1

 

13727

unable to run dockerd on MACHINE=intel-corei7-64 yet works on MACHINE=genericx86-64

timothy.t.orling@...

chee.yang.lee@...

3.1 M4

3.2 M1

 

13793

layerindex-web: Django 1.11 LTS EOL April 2020; need to upgrade to Django 2.2 LTS

timothy.t.orling@...

amber.n.elliot@...

3.1 M4

3.2 M1

 

13841

quilt ptest intermittent failure

randy.macleod@...

matthew.zeng@...

3.2

3.2 M2

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW18!

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

11

akuster808@...

2

alex.kanavin@...

1

hongxu.jia@...

1

alejandro@...

1

ee.peng.yeoh@...

1

Grand Total

17

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: [WIC] Multiple WKS Files

Rudolf J Streif
 


On 5/2/20 2:47 PM, Joshua Watt wrote:


On Sat, May 2, 2020, 1:22 PM Rudolf J Streif <rudolf.streif@...> wrote:
eMMC devices commonly have three hardware partitions: two boot
partitions and a user partition. I was looking for a convenient way to
have wic build an image for the boot partition and one for the user
partition. However, that does not seem to be possible right out of the
box. The variable WKS_FILE only accepts one file and not a list. The
class image_types_wic.bbclass uses WKS_FILES internally but that seems
to be a search list and the code only builds the file it finds first.

I think part of the problem is that wks files are tied to a rootfs image, so it's not currently possible to have multiple because there is no way to differentiate them. Also because of that it's a little odd to have a wks file that doesn't reference the rootfs it's built with.

You might be able to do it by making a simple dummy image recipe for the boot partition(s), then overriding the WKS_FILE variable for the image with a pn override in the machine.conf file (e.g. WKS_FILE_pn-my-emmc-boot = "emmc-boot.wks" )

Thank you, Joshua. I might try your idea. I have noticed that it is tied to the rootfs as I tried to use ondisk/ondrive to create images for different partitions. But that did not work. Actually, the use of the ondisk/ondrive parameter is not entirely obvious to me (but I also have not dissected the code to figure it out).

It might be worthwhile looking into enhancing wic to be able to create multiple images. Devices now also use universal flash storage (UFS) which supports multiple logical disks like a SCSI drive once it is provisioned.



Is my understanding correct?

Any smart ideas to make this work?

Thanks,
Rudi







    
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Current high bug count owners for Yocto Project 3.2

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

28

david.reyna@...

18

bluelightning@...

17

akuster808@...

14

bruce.ashfield@...

11

mark.morton@...

10

Qi.Chen@...

9

kai.kang@...

9

randy.macleod@...

8

ross@...

7

trevor.gamblin@...

7

JPEWhacker@...

7

timothy.t.orling@...

6

changqing.li@...

6

michael@...

5

pbarker@...

4

raj.khem@...

4

mingli.yu@...

4

chee.yang.lee@...

3

yi.zhao@...

3

alex.kanavin@...

3

akuster@...

3

jon.mason@...

3

hongxu.jia@...

3

alejandro@...

2

ycnakajsph@...

2

jpuhlman@...

2

seebs@...

2

mostthingsweb@...

2

jaewon@...

2

rpjday@...

2

kergoth@...

2

mark.hatle@...

2

kexin.hao@...

2

limon.anibal@...

2

bunk@...

1

Martin.Jansa@...

1

zhe.he@...

1

yang.wang@...

1

nicolas.dechesne@...

1

jason.wessel@...

1

denis@...

1

matthew.zeng@...

1

maxime.roussinbelanger@...

1

dl9pf@...

1

naveen.kumar.saini@...

1

ricardo.ribalda@...

1

kai.ruhnau@...

1

mshah@...

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

 

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 339 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: [error-report-web][PATCH] Add SPDX license headers to source files

Randy MacLeod
 

On 2020-05-01 2:54 a.m., Milan Shah wrote:
Hi All,
This is Gentle Reminder to review these changes.
This address bug #13530
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13530
Patch to review:
https://patchwork.openembedded.org/patch/170541/
Thanks Milan.
Looks good to me.

Michael,
Are you still maintaining the repo?

../Randy
Thanks & Regards,
*Milan Shah*
MontaVista Software, Bangaluru, India
On Wed, Feb 26, 2020 at 3:17 PM Milan Shah via Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org> <mshah=mvista.com@... <mailto:mvista.com@...>> wrote:
Post/* all ( except Post/migrations/* , __init__.py and templatetags/* )
have some sort of MIT headers; adding SPDX header to make it obvious.
project/* & test-data/* all ( except __init__.py ) have some sort of
MIT headers;
adding SPDX header to make it obvious.
This address bug #13530
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13530
Signed-off-by: Milan Shah <mshah@... <mailto:mshah@...>>
---
 Post/admin.py                      | 2 ++
 Post/createStatistics.py           | 1 +
 Post/feed.py                       | 2 ++
 Post/management/commands/culldb.py | 2 ++
 Post/models.py                     | 2 ++
 Post/parser.py                     | 1 +
 Post/views.py                      | 2 ++
 manage.py                          | 2 ++
 project/settings.py                | 2 ++
 project/urls.py                    | 2 ++
 project/wsgi.py                    | 4 ++++
 test-data/test-send-error.py       | 3 ++-
 12 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/Post/admin.py b/Post/admin.py
index f11ff65..43aa9a6 100644
--- a/Post/admin.py
+++ b/Post/admin.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # error reporting tool - admin interface definitions
 #
 # Copyright (C) 2013 Intel Corporation
diff --git a/Post/createStatistics.py b/Post/createStatistics.py
index 213927a..09d098e 100644
--- a/Post/createStatistics.py
+++ b/Post/createStatistics.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: MIT
 # Create statistics. Update database.
 #
diff --git a/Post/feed.py b/Post/feed.py
index 745ee23..7e5bfdb 100644
--- a/Post/feed.py
+++ b/Post/feed.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # error-reporting-tool - URL definitions
 #
 # Copyright (C) 2013 Intel Corporation
diff --git a/Post/management/commands/culldb.py
b/Post/management/commands/culldb.py
index 698537c..bd70ffc 100644
--- a/Post/management/commands/culldb.py
+++ b/Post/management/commands/culldb.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # error-reporting-tool -  culldb
 #
 # Copyright (C) 2015 Intel Corporation
diff --git a/Post/models.py b/Post/models.py
index ddf2fc7..cf8c1c2 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # error-reporting-tool - model definitions
 #
 # Copyright (C) 2013 Intel Corporation
diff --git a/Post/parser.py b/Post/parser.py
index 9639308..ed65d4f 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -1,4 +1,5 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: MIT
 # Add errors to database from client
 #
diff --git a/Post/views.py b/Post/views.py
index 7f2cffb..cc6aed9 100644
--- a/Post/views.py
+++ b/Post/views.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # error-reporting-tool - view definitions
 #
 # Copyright (C) 2013 Intel Corporation
diff --git a/manage.py b/manage.py
index 82cfa83..8edb2e4 100755
--- a/manage.py
+++ b/manage.py
@@ -1,4 +1,6 @@
 #!/usr/bin/env python
+# SPDX-License-Identifier: MIT
+
 import os
 import sys
diff --git a/project/settings.py b/project/settings.py
index 3c6c87e..2d1ab92 100644
--- a/project/settings.py
+++ b/project/settings.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # Django settings for error-reporting-tool project.
 # Based on settings.py from the Django project template
 # Copyright (c) Django Software Foundation and individual
contributors.
diff --git a/project/urls.py b/project/urls.py
index 0e8f39c..1f51c7c 100644
--- a/project/urls.py
+++ b/project/urls.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: MIT
+#
 # error-reporting-tool - URL definitions
 #
 # Copyright (C) 2013 Intel Corporation
diff --git a/project/wsgi.py b/project/wsgi.py
index 7d4fc73..8d3ba66 100644
--- a/project/wsgi.py
+++ b/project/wsgi.py
@@ -1,3 +1,7 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
 """
 WSGI config for errorsreport project.
diff --git a/test-data/test-send-error.py b/test-data/test-send-error.py
index 7070c18..1252855 100755
--- a/test-data/test-send-error.py
+++ b/test-data/test-send-error.py
@@ -1,5 +1,6 @@
 #!/usr/bin/env python
-#
+# SPDX-License-Identifier: MIT
+
 # test/example script for sending data to error-report-web
 import urllib2
--
2.7.4

--
# Randy MacLeod
# Wind River Linux


Re: #yocto do_package error for custom app #yocto

Ross Burton <ross@...>
 

On Mon, 4 May 2020 at 14:06, Bastien0530
<bastien.gallet-pesenti@...> wrote:
I have just resolved the issue, that was a mistake in my makefile, I fixed CC=GCC instead of CC?=GCC.
FWIW, you never need that in a Makefile, as there is a default value for CC.

Ross


Re: #yocto do_package error for custom app #yocto

Quentin Schulz
 

Salut Bastien,

On Mon, May 04, 2020 at 06:05:19AM -0700, Bastien0530 wrote:
This file is supposed to be my application.
The `file` command on Linux (could be run on the host and not the
target) will give you important info such as the architecture for which
it was built. In that case, we would have detected that it was built for
your host architecture and guide you to CC=gcc (which is a classic in
many pieces of SW).

I tried to run it on my target cible but doesn't work.
I have just resolved the issue, that was a mistake in my makefile, I fixed CC=GCC instead of CC?=GCC.
Make sure that all variables that could be set from outside are weakly
set as well. (e.g. CFLAGS, LDFLAGS, etc...) otherwise you might
encounter some other issues later (though in some cases, you'll then
need to modify CFLAGS/LDFLAGS from the recipe if the recipe does not
compile with Yocto CFLAGS/LDFLAGS, if it's not fixable in the source
code).

BTW, you most probably don't need your FILEXTRAPATHS_prepend, nor your
do_compile and do_install as what you've in there is their default
"content". (c.f. base.bbclass and cross.bbclass in openembedded-core).

Have fun!
Quentin


Building cython based module with numpy dependency in SDK

Einar Vading
 

Hello!

I've been trying to build a python package which has a component
written in c that is used through cython.

But when I try to build in the SDK I first got:

#error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."

I figured it had to do with
"-I/home/einar/tmp/sdk/poky/3.0.2/sysroots/x86_64-pokysdk-linux/usr/lib/python3.7/site-packages/numpy/core/include"
since that points to my native sysroot instead of the target sysroot.

So I added:

numpy_incdir = numpy.get_include()
python_incdir = '.' # Just some harmeless directory
try:
native = os.environ['OECORE_NATIVE_SYSROOT']
target = os.environ['OECORE_TARGET_SYSROOT']
except KeyError:
pass
else:
rel_path = Path(numpy_incdir).relative_to(native)
numpy_incdir = target / rel_path
python_incdir = target + '/usr/include/python3.7m/'

to my setup.py and got passed the first compiler error.

So now my extension module is built ok but after that there is a step
that fails:

creating build/lib.linux-x86_64-3.7
x86_64-pokysdk-linux-gcc -shared -Wl,-O1 -L -Wl,-O1 -Wl,-O1
-Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong
-Wl,-z,relro,-z,now -O2 -pipe -g -feliminate-unused-debug-types
build/temp.linux-x86_64-3.7/myext.o
build/temp.linux-x86_64-3.7/extlib.o
build/temp.linux-x86_64-3.7/myextmodule.o
-L/home/einar/tmp/poky/3.0.2/sysroots/x86_64-pokysdk-linux/usr/lib
-lpython3.7m -o
build/lib.linux-x86_64-3.7/bbfit.cpython-37m-x86_64-linux-gnu.so -lm
unable to execute 'x86_64-pokysdk-linux-gcc': No such file or directory
error: command 'x86_64-pokysdk-linux-gcc' failed with exit status 1

And I can't get passed this error and I think it's weird that it's
trying to use x86_64-pokysdk-linux-gcc since my extension module is
built with

CC=arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/einar/tmp/poky/3.0.2/sysroots/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi

Should building a cython extension in the SDK work? Any ideas why ming
won't compile. Or why it's trying to use a compiler for host instead
of target in the end?

Best regards,
Einar


Re: #yocto do_package error for custom app #yocto

Bastien0530 <bastien.gallet-pesenti@...>
 

This file is supposed to be my application.
I tried to run it on my target cible but doesn't work.
I have just resolved the issue, that was a mistake in my makefile, I fixed CC=GCC instead of CC?=GCC.

Thanks for you answer


Yocto img file deployment

Damien LEFEVRE
 

Hi,

I have a yocto image: image.img.

On my build PC I have
> file image.img
image.img: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 802815 sectors, extended partition table (last)

> fdisk -l image.img
Disk image.img: 392 MiB, 411041792 bytes, 802816 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 45C0DFD4-267E-4C4A-820F-B94F180165E7

Device     Start    End Sectors  Size Type
image.img1  2048 800767  798720  390M Linux filesystem



And I can calculate the offset (512 * 2048 = 1048576) to mount image.img1 to let say /tmp/update
mount -t ext4 -o loop,offset=1048576 image.img /tmp/update



Now on the target device (Tegra), I'd like to write the content of image.img1 to /dev/mmcblk0p38. But the output of busybox's fdisk is different

> fdisk -l image.img
Disk image.img: 392 MB, 411041792 bytes, 802816 sectors
49 cylinders, 255 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device   Boot StartCHS    EndCHS        StartLBA     EndLBA    Sectors  Size Id Type
image.img1    0,0,1       1023,254,63          1     802815     802815  391M ee EFI GPT
Partition 1 has different physical/logical start (non-Linux?):
     phys=(0,0,1) logical=(0,0,2)
Partition 1 has different physical/logical end:
     phys=(1023,254,63) logical=(49,248,7)

How can I deduce the offset from this output?

Better even, is there a way to dd image.img1 directly to /dev/mmcblk0p38?

Thanks,


Re: BSP layer for Firecracker: Sensible? Advisable? #linux #yocto

Ross Burton <ross@...>
 

On Mon, 4 May 2020 at 06:25, <mark@...> wrote:
A goal will be to squeeze out maximum performance and/or minimum-size. so I'm wondering would a BSP layer deliver any benefit? The Firecracker VM has a very small device list, with support for Intel x86_64 and ARM64 CPU's. The devices are: "only 5 emulated devices are available: virtio-net, virtio-block, virtio-vsock, serial console, and a minimal keyboard controller used only to stop the microVM"
In that case a tuned kernel build in a dedicated BSP would make sense, yes.

Ross

8481 - 8500 of 57808