Web interface for Yocto & OE mailing lists defaults to Reply to Sender
Michael, I've just been discussing on IRC with Bartłomiej who used the groups.io web interface to reply to an email on the list. It defaulted to sending a private reply off the list. If I try to do the same "Reply to Sender" is the default for me as well: https://imgur.com/1RGH9AwLooking at the AGL lists on groups.io they have "Reply to Group" as the default. Perhaps this is a configuration issue? Could you take when you get chance? Thanks, -- Paul Barker Konsulko Group
|
|
Can not use wildcard in SRC_URI to apply patches
#yocto
Hi,
I'm trying to apply patches to source code of linux kernel.
With devtool (modify and finish commands), I could apply patches sucessfully by specified each single patch with its file name, like: =========================================== FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "\ file://0001-xxx-xxx-xxx.patch \ file://0002-xxx-xxx-xxx.patch \ " ===========================================
However, if I change files' name into wildcard in SRC_URI like: =========================================== FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += "file://*" =========================================== or =========================================== FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += "file://*.patch" =========================================== or even create a "patches" folder under ${PN} and modify bb file like =========================================== FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" SRC_URI += "file://patches" =========================================== patch files will not be applied either do_patch task or "devtool modify" command.
I tried in the latest version (zeus) and earlier version (sumo), and got the same proble,
Could anyone tell me how to apply patches by wildcard?
Thank you
Qian
|
|
Re: Can't find pyconfig.h with python3
Hi -
The board isn’t buried *too* deeply yet, but lab restrictions are the main barrier at the moment. Hopefully I can figure out how to remotely update at some point, but I should be able to test with Zeus before we actually bury it underground. Right now it has rocko, and I’ve been updating things piecemeal as I go.
Ah I see, so perhaps Zeus is ideal for me until we can drop python2 entirely. Thanks for the info and links!
Best, Emily
toggle quoted messageShow quoted text
On Apr 24, 2020, at 10:59 PM, Tim Orling <ticotimo@...> wrote:
Hi -
Not a super compelling reason other than the momentum required to update! Does Zeus support having both python2 and python3? We have a couple things that haven’t upgraded to python3 yet as well. It’s almost certainly a good idea to move to Zeus, but everything is further complicated because we don’t have physical access to the board right now to update the OS and make sure things still work.
Right. I remember a prior thread about you needing to update remotely. I assume this board is stuffed deep in ATLAS somewhere. (In a prior life I was a materials scientist)
Are you stuck with "rocko" on the deeply buried remote-only device or can you use "sumo"?
Zeus still had python2 [1] and python3 [2]. But you can also get python2 support with meta-python2 [3], since the latest release "dunfell" [4]. For random development reasons, the zeus branch should also work [5]. Note that meta-python2 will have limited support going forward (as in I might not support it after this month, but others might). It was created so we could drop python2 from the other layers, without breaking everything everywhere for everyone.
Sorry about the internal repos, but thanks for the start!
Best, Emily
On Apr 24, 2020, at 10:01 PM, Tim Orling <ticotimo@...> wrote:
I meant to say "zeus" was released in October 2019. I'm sure xilinx support was after that. On Fri, Apr 24, 2020 at 8:00 PM Tim Orling < ticotimo@...> wrote:
I see you are building for "rocko" and that your layer supports "sumo" and "rocko". Do you have a strong compelling reason to stay on these EOL releases? meta-xilinx has a zeus branch which was released in October 2019 and has newer components and will be easier for you and us to support. (We've had "thud" and "warrior" releases in-between, so that's at least a year and a half ahead of your code base).
I started trying to build your layer (on "zeus" release), but unfortunately you have recipes fetching from internal CERN git repos that are not accessible to the rest of us.
Here's what I have so far:
Again, I can't go much further because I can't fetch from your internal repos.
On Fri, Apr 24, 2020 at 6:38 PM Khem Raj < raj.khem@...> wrote:
On 4/24/20 4:17 PM, Emily wrote:
> Hi all -
>
> I'm trying to build an OS with a custom recipe
> (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb).
> I can build it as-is in the link above, but when actually trying to use
> the output of the recipe (Poverty.so) I get the below error in python3:
>
>>>> import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
>
>
> I think that's because I built against python2 in some places. So I
> replaced essentially all of the python dependencies with their
> corresponding python3 dependencies, but that gives a build error in
> bitbake like:
>
> | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory
> | # include <pyconfig.h>
> | ^~~~~~~~~~~~
> | compilation terminated.
>
>
> However, I checked and the offending file pyconfig.h is actually present
> at |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/.
> When I build with python2 dependencies the file is in the same location,
> just /python2.7/.
>
> I can't quite tell if this is a yocto problem, or a problem with my
> recipe and/or build files for that recipe. If anyone has suggestions
> they would be much appreciated!
this seems to be that it is needing python2, so yes it can perhaps be
ported to py3 but you might have to check if it needs some code changes
Looking at the recipe it is ineheriting py2 class here [1]
perhaps you should change that to python3native
[1]
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb#L15
>
> Thanks!
> Emily Smith
>
>
>
>
|
|
Re: Can't find pyconfig.h with python3
Hi -
Not a super compelling reason other than the momentum required to update! Does Zeus support having both python2 and python3? We have a couple things that haven’t upgraded to python3 yet as well. It’s almost certainly a good idea to move to Zeus, but everything is further complicated because we don’t have physical access to the board right now to update the OS and make sure things still work.
Right. I remember a prior thread about you needing to update remotely. I assume this board is stuffed deep in ATLAS somewhere. (In a prior life I was a materials scientist)
Are you stuck with "rocko" on the deeply buried remote-only device or can you use "sumo"?
Zeus still had python2 [1] and python3 [2]. But you can also get python2 support with meta-python2 [3], since the latest release "dunfell" [4]. For random development reasons, the zeus branch should also work [5]. Note that meta-python2 will have limited support going forward (as in I might not support it after this month, but others might). It was created so we could drop python2 from the other layers, without breaking everything everywhere for everyone.
Sorry about the internal repos, but thanks for the start!
Best, Emily
On Apr 24, 2020, at 10:01 PM, Tim Orling <ticotimo@...> wrote:
I meant to say "zeus" was released in October 2019. I'm sure xilinx support was after that. On Fri, Apr 24, 2020 at 8:00 PM Tim Orling < ticotimo@...> wrote:
I see you are building for "rocko" and that your layer supports "sumo" and "rocko". Do you have a strong compelling reason to stay on these EOL releases? meta-xilinx has a zeus branch which was released in October 2019 and has newer components and will be easier for you and us to support. (We've had "thud" and "warrior" releases in-between, so that's at least a year and a half ahead of your code base).
I started trying to build your layer (on "zeus" release), but unfortunately you have recipes fetching from internal CERN git repos that are not accessible to the rest of us.
Here's what I have so far:
Again, I can't go much further because I can't fetch from your internal repos.
On Fri, Apr 24, 2020 at 6:38 PM Khem Raj < raj.khem@...> wrote:
On 4/24/20 4:17 PM, Emily wrote:
> Hi all -
>
> I'm trying to build an OS with a custom recipe
> (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb).
> I can build it as-is in the link above, but when actually trying to use
> the output of the recipe (Poverty.so) I get the below error in python3:
>
>>>> import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
>
>
> I think that's because I built against python2 in some places. So I
> replaced essentially all of the python dependencies with their
> corresponding python3 dependencies, but that gives a build error in
> bitbake like:
>
> | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory
> | # include <pyconfig.h>
> | ^~~~~~~~~~~~
> | compilation terminated.
>
>
> However, I checked and the offending file pyconfig.h is actually present
> at |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/.
> When I build with python2 dependencies the file is in the same location,
> just /python2.7/.
>
> I can't quite tell if this is a yocto problem, or a problem with my
> recipe and/or build files for that recipe. If anyone has suggestions
> they would be much appreciated!
this seems to be that it is needing python2, so yes it can perhaps be
ported to py3 but you might have to check if it needs some code changes
Looking at the recipe it is ineheriting py2 class here [1]
perhaps you should change that to python3native
[1]
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb#L15
>
> Thanks!
> Emily Smith
>
>
>
>
|
|
Re: Can't find pyconfig.h with python3
Hi -
Not a super compelling reason other than the momentum required to update! Does Zeus support having both python2 and python3? We have a couple things that haven’t upgraded to python3 yet as well. It’s almost certainly a good idea to move to Zeus, but everything is further complicated because we don’t have physical access to the board right now to update the OS and make sure things still work.
Sorry about the internal repos, but thanks for the start!
Best, Emily
toggle quoted messageShow quoted text
On Apr 24, 2020, at 10:01 PM, Tim Orling <ticotimo@...> wrote:
I meant to say "zeus" was released in October 2019. I'm sure xilinx support was after that. On Fri, Apr 24, 2020 at 8:00 PM Tim Orling < ticotimo@...> wrote:
I see you are building for "rocko" and that your layer supports "sumo" and "rocko". Do you have a strong compelling reason to stay on these EOL releases? meta-xilinx has a zeus branch which was released in October 2019 and has newer components and will be easier for you and us to support. (We've had "thud" and "warrior" releases in-between, so that's at least a year and a half ahead of your code base).
I started trying to build your layer (on "zeus" release), but unfortunately you have recipes fetching from internal CERN git repos that are not accessible to the rest of us.
Here's what I have so far:
Again, I can't go much further because I can't fetch from your internal repos.
On Fri, Apr 24, 2020 at 6:38 PM Khem Raj < raj.khem@...> wrote:
On 4/24/20 4:17 PM, Emily wrote:
> Hi all -
>
> I'm trying to build an OS with a custom recipe
> (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb).
> I can build it as-is in the link above, but when actually trying to use
> the output of the recipe (Poverty.so) I get the below error in python3:
>
>>>> import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
>
>
> I think that's because I built against python2 in some places. So I
> replaced essentially all of the python dependencies with their
> corresponding python3 dependencies, but that gives a build error in
> bitbake like:
>
> | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory
> | # include <pyconfig.h>
> | ^~~~~~~~~~~~
> | compilation terminated.
>
>
> However, I checked and the offending file pyconfig.h is actually present
> at |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/.
> When I build with python2 dependencies the file is in the same location,
> just /python2.7/.
>
> I can't quite tell if this is a yocto problem, or a problem with my
> recipe and/or build files for that recipe. If anyone has suggestions
> they would be much appreciated!
this seems to be that it is needing python2, so yes it can perhaps be
ported to py3 but you might have to check if it needs some code changes
Looking at the recipe it is ineheriting py2 class here [1]
perhaps you should change that to python3native
[1]
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb#L15
>
> Thanks!
> Emily Smith
>
>
>
>
|
|
Re: Can't find pyconfig.h with python3
I meant to say "zeus" was released in October 2019. I'm sure xilinx support was after that.
toggle quoted messageShow quoted text
On Fri, Apr 24, 2020 at 8:00 PM Tim Orling < ticotimo@...> wrote:
I see you are building for "rocko" and that your layer supports "sumo" and "rocko". Do you have a strong compelling reason to stay on these EOL releases? meta-xilinx has a zeus branch which was released in October 2019 and has newer components and will be easier for you and us to support. (We've had "thud" and "warrior" releases in-between, so that's at least a year and a half ahead of your code base).
I started trying to build your layer (on "zeus" release), but unfortunately you have recipes fetching from internal CERN git repos that are not accessible to the rest of us.
Here's what I have so far:
Again, I can't go much further because I can't fetch from your internal repos.
On Fri, Apr 24, 2020 at 6:38 PM Khem Raj < raj.khem@...> wrote:
On 4/24/20 4:17 PM, Emily wrote:
> Hi all -
>
> I'm trying to build an OS with a custom recipe
> (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb).
> I can build it as-is in the link above, but when actually trying to use
> the output of the recipe (Poverty.so) I get the below error in python3:
>
>>>> import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
>
>
> I think that's because I built against python2 in some places. So I
> replaced essentially all of the python dependencies with their
> corresponding python3 dependencies, but that gives a build error in
> bitbake like:
>
> | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory
> | # include <pyconfig.h>
> | ^~~~~~~~~~~~
> | compilation terminated.
>
>
> However, I checked and the offending file pyconfig.h is actually present
> at |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/.
> When I build with python2 dependencies the file is in the same location,
> just /python2.7/.
>
> I can't quite tell if this is a yocto problem, or a problem with my
> recipe and/or build files for that recipe. If anyone has suggestions
> they would be much appreciated!
this seems to be that it is needing python2, so yes it can perhaps be
ported to py3 but you might have to check if it needs some code changes
Looking at the recipe it is ineheriting py2 class here [1]
perhaps you should change that to python3native
[1]
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb#L15
>
> Thanks!
> Emily Smith
>
>
>
>
|
|
Re: Can't find pyconfig.h with python3
I see you are building for "rocko" and that your layer supports "sumo" and "rocko". Do you have a strong compelling reason to stay on these EOL releases? meta-xilinx has a zeus branch which was released in October 2019 and has newer components and will be easier for you and us to support. (We've had "thud" and "warrior" releases in-between, so that's at least a year and a half ahead of your code base).
I started trying to build your layer (on "zeus" release), but unfortunately you have recipes fetching from internal CERN git repos that are not accessible to the rest of us.
Here's what I have so far:
Again, I can't go much further because I can't fetch from your internal repos.
toggle quoted messageShow quoted text
On Fri, Apr 24, 2020 at 6:38 PM Khem Raj < raj.khem@...> wrote:
On 4/24/20 4:17 PM, Emily wrote:
> Hi all -
>
> I'm trying to build an OS with a custom recipe
> (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb).
> I can build it as-is in the link above, but when actually trying to use
> the output of the recipe (Poverty.so) I get the below error in python3:
>
>>>> import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
>
>
> I think that's because I built against python2 in some places. So I
> replaced essentially all of the python dependencies with their
> corresponding python3 dependencies, but that gives a build error in
> bitbake like:
>
> | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory
> | # include <pyconfig.h>
> | ^~~~~~~~~~~~
> | compilation terminated.
>
>
> However, I checked and the offending file pyconfig.h is actually present
> at |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/.
> When I build with python2 dependencies the file is in the same location,
> just /python2.7/.
>
> I can't quite tell if this is a yocto problem, or a problem with my
> recipe and/or build files for that recipe. If anyone has suggestions
> they would be much appreciated!
this seems to be that it is needing python2, so yes it can perhaps be
ported to py3 but you might have to check if it needs some code changes
Looking at the recipe it is ineheriting py2 class here [1]
perhaps you should change that to python3native
[1]
https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb#L15
>
> Thanks!
> Emily Smith
>
>
>
>
|
|
Re: Can't find pyconfig.h with python3

Khem Raj
On 4/24/20 4:17 PM, Emily wrote: Hi all -
I'm trying to build an OS with a custom recipe (https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb). I can build it as-is in the link above, but when actually trying to use the output of the recipe (Poverty.so) I get the below error in python3:
import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
I think that's because I built against python2 in some places. So I replaced essentially all of the python dependencies with their corresponding python3 dependencies, but that gives a build error in bitbake like:
| /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory | # include <pyconfig.h> | ^~~~~~~~~~~~ | compilation terminated.
However, I checked and the offending file pyconfig.h is actually present at | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/. When I build with python2 dependencies the file is in the same location, just /python2.7/.
I can't quite tell if this is a yocto problem, or a problem with my recipe and/or build files for that recipe. If anyone has suggestions they would be much appreciated! this seems to be that it is needing python2, so yes it can perhaps be ported to py3 but you might have to check if it needs some code changes Looking at the recipe it is ineheriting py2 class here [1] perhaps you should change that to python3native [1] https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb#L15 Thanks! Emily Smith
|
|
Re: Enabling SELinux in an application
#selinux

Khem Raj
On 4/21/20 11:50 AM, Cguerin@middleby.com wrote: I am with The Middleby Corporation. We manufacture a wide variety of commercial ovens, ice machines, coffee brewers, microwaves, soft-serve machines and virtually anything you’d find in a commercial restaurant kitchen. Much of our equipment has a touch-screen display on it – often 4.3” to 10.1” in size. This is part of an embedded control system that includes a separate I/O board to talk to motors, heating elements, etc. The touch-screen control are most often running Yocto Linux with a QT or similar application running on top of Linux. Recently, we have been asked to explore enabling SELinux security provisions in our applications. In speaking with several of our vendors, they all indicated they don’t generally need to enable SELinux and have never done so in the past.
I now know what SELinux is, but I can’t get a good answer if it even is needed to be enabled on a touch-screen application on equipment that a 16 year old kid generally operates. We often do have USB ports on our equipment for software updates and some is connected to the internet as well, but I still don’t see how the security access provisions in SELinux are needed for our application.
Generally devices having ports, or being connected to Internet can become a door to your network and cause some serious damage, so you sould assess the security needs for your devices, I would think. As far as technologies needed to achieve security needs SELinux is one of many options, you have apparmor, tomoyo, and other MAC technologies, and I would think you should do some experiments to see which of these will fit your needs to manage MAC. Then there are other methods to address security concerns. Lastly, I'm not a programmer. I manage the business end of all of Middleby's electronic controls, so the aim of this message is to ask for general guidance regarding the need for SELinux or not. I would think you need security, SELinux is one cog in the wheel and there are other options, I would think doing some proof of concept within your setups after you have done some security analysis, would be the steps to take.
|
|
Re: inconsistencies with selecting systemd as init manager?

Khem Raj
On 4/23/20 5:14 AM, Robert P. J. Day wrote: On Thu, 23 Apr 2020, Nicolas Dechesne wrote:
On Thu, Apr 23, 2020 at 1:18 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
just noticed that, given that since YP 3.0 one could select systemd as the init manager via the single variable INIT_MANAGER, which pulled in init-manager-systemd.inc:
# Use systemd for system initialization DISTRO_FEATURES_append = " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit" VIRTUAL-RUNTIME_init_manager ??= "systemd" VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units" VIRTUAL-RUNTIME_login_manager ??= "shadow-base"
INIT_MANAGER was added in 3.0, see: https://git.openembedded.org/openembedded-core/commit/?id=8d0b4704a526a48cd5e67df6 1b613424bbbdccde i know, that's what i mentioned above.
this doesn't quite seem to match this snippet from meta/lib/oeqa/selftest/cases/imagefeatures.py:
# Switch to systemd DISTRO_FEATURES += "systemd" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "" VIRTUAL-RUNTIME_syslog = "" VIRTUAL-RUNTIME_login_manager = "shadow-base" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
this is the 'old' (pre 3.0) method, and it can (and should) be replaced with INIT_MANAGER, i believe. i suspected as much, i just wanted to point out that those two snippets are not *exactly* equivalent so someone should make sure that INIT_MANAGER usage is precisely defined. perhaps imagefeatures.py should be updated to sync with INIT_MANAGER settings. rday
|
|

Khem Raj
On 4/23/20 2:26 AM, sateesh m wrote: Hi Guys,
I want to test Distro testing in my yocto build image. for that I need setup configurations and how can i check results and where i can get results. can anybody knows please suggest me .
you can check ptest images perhaps see [1] [1] https://wiki.yoctoproject.org/wiki/Image_tests
|
|

Khem Raj
On 4/23/20 12:01 AM, Per Hallsmark wrote: Hi Nicholas,
Thanks, I was thinking as providing it to Yocto but not maintaining it myself. Too much other stuff going on so it would be a slowly updated layer then.
Give it some time and see if someone steps up to maintain it, if not you can also put these recipes in other layers BR, Per
On Thu, 23 Apr 2020 at 07:59, Nicholas Krause <xerofoify@gmail.com <mailto:xerofoify@gmail.com>> wrote:
On 4/23/20 1:28 AM, per@hallsmark.se <mailto:per@hallsmark.se> wrote:
Hello fellow Yocto developers,
To be able todo efficient HTML5 programming we of course needs some javascript libraries. I've not seen Yocto have them packaged so I made up this idea of putting them into their own /usr/lib/js path with a subdir for each javascript library. It is published here :
https://gitlab.com/saxofon/meta-javascripts
With an example usage here :
https://github.com/Wind-River/device-remote-gui
Would this be something yoctoproject is interested of perhaps?
BR, Per Hi,
I'm not a maintainer but you may want to see if you or other people are able to maintain then as a open embedded layer as part of the index. Not sure if someone else can chip in if this is a useful recipe set to add to the open embedded index.
That would ideally be where you would want this to go if this is useful and maintained,
Nick
|
|
Can't find pyconfig.h with python3
Hi all -
>>> import Poverty Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: /usr/bin/Poverty.so: undefined symbol: _ZN5boost6python6detail11init_moduleEPKcPFvvE
I think that's because I built against python2 in some places. So I replaced essentially all of the python dependencies with their corresponding python3 dependencies, but that gives a build error in bitbake like: | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/boost/python/detail/wrap_python.hpp:50:11: fatal error: pyconfig.h: No such file or directory | # include <pyconfig.h> | ^~~~~~~~~~~~ | compilation terminated.
However, I checked and the offending file pyconfig.h is actually present at | /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot/usr/include/python3.5m/. When I build with python2 dependencies the file is in the same location, just /python2.7/.
I can't quite tell if this is a yocto problem, or a problem with my recipe and/or build files for that recipe. If anyone has suggestions they would be much appreciated!
Thanks! Emily Smith
|
|
Re: Enabling SELinux in an application
#selinux

Rudolf J Streif
Hi,
There is no simply answer to your question. Most generally
speaking any type of security, not just for computers and embedded
systems, is a tradeoff between risk and cost.
The fact that your appliances have USB ports and are potentially
connected to the Internet makes them vulnerable for attacks. They
can potentially be used to gain access to your appliances, put
malicious software on them, potentially damage them. be used as
bots for cyber attacks, etc. An expert and embedded security can
assess the risk by examining your appliances, software etc. You
only can assess the risk for your business and the business of
your customers. What will it mean for a customer and your business
if multiple appliances are hacked and not functioning anymore and
the customer cannot deliver their product and services possibly
for days until you are able to reinstall the software? What does
that mean for your business if that happens at many of your
customers' locations at the same time?
It does not need to be professional hackers that are out for
financial gain doing that. Your proverbial 16 year old kid
operating the equipment could be an aspiring embedded systems
engineer who is curious about what's behind the scenes of the
appliances.
It's never a bad idea to think about security for your embedded
systems. Having done a whole lot deal of embedded systems in
automotive and explicitly for securing content and devices for
digital television I can only advise you to take it seriously.
It's better to be proactive then reactive. Bad embedded systems
security practices are all around. Just because your vendors have
not done it does not really mean anything.
SELinux is only one consideration. There are other things that go
into hardening an embedded system.
Best regards,
Rudi
I am with The Middleby Corporation. We manufacture a wide
variety of commercial ovens, ice machines, coffee brewers,
microwaves, soft-serve machines and virtually anything you’d
find in a commercial restaurant kitchen. Much of our equipment
has a touch-screen display on it – often 4.3” to 10.1” in size.
This is part of an embedded control system that includes a
separate I/O board to talk to motors, heating elements, etc.
The touch-screen control are most often running Yocto Linux with
a QT or similar application running on top of Linux. Recently,
we have been asked to explore enabling SELinux security
provisions in our applications. In speaking with several of our
vendors, they all indicated they don’t generally need to enable
SELinux and have never done so in the past.
I now know what SELinux is, but I can’t get a good answer if it
even is needed to be enabled on a touch-screen application on
equipment that a 16 year old kid generally operates. We often
do have USB ports on our equipment for software updates and some
is connected to the internet as well, but I still don’t see how
the security access provisions in SELinux are needed for our
application.
Lastly, I'm not a programmer. I manage the business end of all
of Middleby's electronic controls, so the aim of this message is
to ask for general guidance regarding the need for SELinux or
not.
--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700
|
|
Re: [PATCH yocto-autobuilder-helper 2/2] scripts/send-qa-email: fix bug in git push logic for yocto-testresults
On Wed, 2020-04-22 at 14:43 -1000, Steve Sakoman wrote: We were mistakenly doing a force push if the branch was in either BUILD_HISTORY_FORKPUSH or BUILD_HISTORY_DIRECTPUSH.
Now we force push for branches in BUILD_HISTORY_FORKPUSH, regular push for branches in BUILD_HISTORY_DIRECTPUSH, and no push if the branch is in neither list.
Signed-off-by: Steve Sakoman <steve@sakoman.com> --- scripts/send-qa-email | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/send-qa-email b/scripts/send-qa-email index 205f6d1..b4d4cec 100755 --- a/scripts/send-qa-email +++ b/scripts/send-qa-email @@ -80,10 +80,10 @@ if 'poky' in repos and os.path.exists(resulttool) and args.results_dir: extraopts = None subprocess.check_call([resulttool, "store", args.results_dir, tempdir]) - if basebranch: + if comparebranch: subprocess.check_call(["git", "push", "--all", "--force"], cwd=tempdir) subprocess.check_call(["git", "push", "--tags", "--force"], cwd=tempdir) - else: + elif basebranch: subprocess.check_call(["git", "push", "--all"], cwd=tempdir) subprocess.check_call(["git", "push", "--tags"], cwd=tempdir) Thanks, well found! I tweaked the first patch to use comparerepo instead of baserepo. The confusion came from cut and paste from the buildhistory code. Cheers, Richard
|
|
Re: inconsistencies with selecting systemd as init manager?
On Thu, 23 Apr 2020, Nicolas Dechesne wrote:
On Thu, Apr 23, 2020 at 1:18 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
just noticed that, given that since YP 3.0 one could select systemd as the init manager via the single variable INIT_MANAGER, which pulled in init-manager-systemd.inc:
# Use systemd for system initialization DISTRO_FEATURES_append = " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit" VIRTUAL-RUNTIME_init_manager ??= "systemd" VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units" VIRTUAL-RUNTIME_login_manager ??= "shadow-base"
INIT_MANAGER was added in 3.0, see: https://git.openembedded.org/openembedded-core/commit/?id=8d0b4704a526a48cd5e67df6 1b613424bbbdccde
i know, that's what i mentioned above. this doesn't quite seem to match this snippet from meta/lib/oeqa/selftest/cases/imagefeatures.py:
# Switch to systemd DISTRO_FEATURES += "systemd" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "" VIRTUAL-RUNTIME_syslog = "" VIRTUAL-RUNTIME_login_manager = "shadow-base" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
this is the 'old' (pre 3.0) method, and it can (and should) be replaced with INIT_MANAGER, i believe. i suspected as much, i just wanted to point out that those two snippets are not *exactly* equivalent so someone should make sure that INIT_MANAGER usage is precisely defined. rday
|
|
Re: inconsistencies with selecting systemd as init manager?

Nicolas Dechesne
On Thu, Apr 23, 2020 at 1:18 PM Robert P. J. Day < rpjday@...> wrote:
just noticed that, given that since YP 3.0 one could select systemd
as the init manager via the single variable INIT_MANAGER, which pulled
in init-manager-systemd.inc:
# Use systemd for system initialization
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
VIRTUAL-RUNTIME_init_manager ??= "systemd"
VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units"
VIRTUAL-RUNTIME_login_manager ??= "shadow-base"
INIT_MANAGER was added in 3.0, see:
this doesn't quite seem to match this snippet from
meta/lib/oeqa/selftest/cases/imagefeatures.py:
# Switch to systemd
DISTRO_FEATURES += "systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
VIRTUAL-RUNTIME_initscripts = ""
VIRTUAL-RUNTIME_syslog = ""
VIRTUAL-RUNTIME_login_manager = "shadow-base"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
this is the 'old' (pre 3.0) method, and it can (and should) be replaced with INIT_MANAGER, i believe.
not sure if that second snippet could be replaced with a simple
assignment to INIT_MANAGER or whether those two snippets are
effectively equivalent ... i'll let someone else make that call.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
|
|
inconsistencies with selecting systemd as init manager?
just noticed that, given that since YP 3.0 one could select systemd as the init manager via the single variable INIT_MANAGER, which pulled in init-manager-systemd.inc: # Use systemd for system initialization DISTRO_FEATURES_append = " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit" VIRTUAL-RUNTIME_init_manager ??= "systemd" VIRTUAL-RUNTIME_initscripts ??= "systemd-compat-units" VIRTUAL-RUNTIME_login_manager ??= "shadow-base" this doesn't quite seem to match this snippet from meta/lib/oeqa/selftest/cases/imagefeatures.py: # Switch to systemd DISTRO_FEATURES += "systemd" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "" VIRTUAL-RUNTIME_syslog = "" VIRTUAL-RUNTIME_login_manager = "shadow-base" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" not sure if that second snippet could be replaced with a simple assignment to INIT_MANAGER or whether those two snippets are effectively equivalent ... i'll let someone else make that call. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.caTwitter: http://twitter.com/rpjdayLinkedIn: http://ca.linkedin.com/in/rpjday========================================================================
|
|
Hi Guys,
I want to test Distro testing in my yocto build image. for that I need setup configurations and how can i check results and where i can get results. can anybody knows please suggest me .
|
|
perf-1.0 do complie issue
Hi Sir,
I am trying to build yocto image target qemuriscv64 using core-image-sato. But i am facing issue with this package how can i resolve this issue . can you please suggest me solution.
Thanks & Regards, Sateesh
|
|