Re: [yocto] CPU Load
On 29.03.2018 04:24, Andre McCurdy wrote: On Tue, Mar 27, 2018 at 4:44 AM, Ryan Meulenkamp wrote: Hi y'all, I have some questions about CPU load and performance, but first some background information. We have small embedded system running an openembedded classic (Angström) distro. Now to get ourselves up-to-date we started working on a new iteration of the OS based on openembedded core and Yocto. It is nearly finished now, if it weren't for one problem: The CPU load (/proc/loadavg) of the core/yocto based OS is more than double that of the classic/Angström OS. So the way I see it this could be caused by a number of factors: - loadavg's calculation changed - certain newer versions of applications run heavier - The kernel itself is heavier (we upgraded from 2.6.35.14+ to 4.9.28+) - Possibly caused by some configs - ... My question: is there something that changed since OE-classic that you know could be the cause of this? If not, how would I go about finding the cause? I don't think the top command is sufficient for this, because it's precision is such that many processes' CPU usage just become 0%. You don't say what the CPU doubled from or too. 1% to 2%, or 50% to 100% ? Unless the absolute increase is very small, you can probably ignore the processes which top reports as 0%. Does the new build have any significant processes running which weren't there in the old build? Or is it the same basic set of apps running in each? Changes in really small loads could change even due to differences in kernel process accounting. For example if timer granularity has changed. IIRC, for Meltdown/Spectre mitigations, there have been changes in use of TSC for timing (depending on which CPU model and microcode level is being used). So it is good to at least check which clock source is being used by kernel in each case. Because the accounting values are at least rounded to the timer granularity. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] samhain-server: do not extend to native
From: Jackie Huang
No packages depend on samhain-server-native and it doesn't
make sense to extend a server package to native, so remove
the BBCLASSEXTEND.
Signed-off-by: Jackie Huang
---
recipes-security/samhain/samhain-server_4.2.2.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/recipes-security/samhain/samhain-server_4.2.2.bb
b/recipes-security/samhain/samhain-server_4.2.2.bb
index 67f1ec5..9341d44 100644
--- a/recipes-security/samhain/samhain-server_4.2.2.bb
+++ b/recipes-security/samhain/samhain-server_4.2.2.bb
@@ -18,4 +18,3 @@ do_install_append() {
}
RDEPENDS_${PN} += "gmp bash perl"
-BBCLASSEXTEND = "native"
--
2.11.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CPU Load
On Tue, Mar 27, 2018 at 4:44 AM, Ryan Meulenkamp wrote: > Hi y'all, > > I have some questions about CPU load and performance, but first some > background information. > > We have small embedded system running an openembedded classic (Angström) > distro. Now to get ourselves up-to-date we started working on a new > iteration of the OS based on openembedded core and Yocto. It is nearly > finished now, if it weren't for one problem: The CPU load (/proc/loadavg) of > the core/yocto based OS is more than double that of the classic/Angström OS. > > So the way I see it this could be caused by a number of factors: > > - loadavg's calculation changed > - certain newer versions of applications run heavier > - The kernel itself is heavier (we upgraded from 2.6.35.14+ to 4.9.28+) > - Possibly caused by some configs > - ... > > My question: is there something that changed since OE-classic that you know > could be the cause of this? If not, how would I go about finding the cause? > I don't think the top command is sufficient for this, because it's precision > is such that many processes' CPU usage just become 0%. You don't say what the CPU doubled from or too. 1% to 2%, or 50% to 100% ? Unless the absolute increase is very small, you can probably ignore the processes which top reports as 0%. Does the new build have any significant processes running which weren't there in the old build? Or is it the same basic set of apps running in each? > Also, both top and > htop cause huge cpu loads themselves. > > Any tips and tricks would be welcome! > > Thanks in advance! > > Ryan > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] defconfig file (or fragment files) not used
On 3/28/18 9:27 AM, Vincent Daanen wrote:
Hi,
I want to add CAN driver support to the kernel. Here is the procedure I
followed:
1. Generate a .config file
2. Copy it to meta-myWork/recipes-kernel/linux/files/defconfig
3. Update it: set at the end the config to enable CAN as follows
# CAN Bus
CONFIG_NET=y
CONFIG_CAN=y
CONFIG_CAN_RAW=y
CONFIG_CAN_BCM=y
CONFIG_CAN_GW=y
#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=y
# CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=y
# CONFIG_CAN_CALC_BITTIMING is not set
# CONFIG_CAN_LEDS is not set
# CONFIG_CAN_SJA1000 is not set
4. Update the linux-yocto_%.bbappend file as follows
SUMMARY = "Recipe to configure kernel as required"
LICENSE = "CLOSED"
inherit kernel-yocto
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += file://defconfig
5. Request rebuilt:
bitbake linux-yocto-rt -c cleansstate
bitbake -k linux-yocto-rt
Once the image started (with qemu), I check if the CAN is enabled (using
zcat /proc/config.gz | grep CAN) and I always get “CAN not set”
I also tried using fragment and I got the same result ☹
According the user manual, it seems to me I’m doing the right think!
Does someone know why my defconfig file is not taken into account ?
If you are using linux-yocto for your kernel provider then I wouldr
recommend that you look into developer manual.
you should look into using config fragments to modify the needed options
e.g. see
https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html#changing-the-configuration
Thanks
Vincent
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] python-fcntl missing in rocko?
Indeed, I seem to have gotten lucky by having it included without an explicit RDEPENDS/DEPENDS line for it. I've added it manually and now it's included :) Thanks. Giordon On Tue, Mar 27, 2018 at 1:32 PM Burton, Ross wrote: > python-core is just "an arbitrary subset of the python libraries", > you'd do better by including python-modules in your image which is all > of Python. > > Or use oe-pkgdata-util to search what package contains the fcntl module. > > Ross > > On 27 March 2018 at 17:50, Giordon Stark wrote: > > Hi all, > > > > When I switched from pyro to rocko, using `python-core` -- I'm noticing > that > > the fcntl module in python2 is missing. Is there a recipe to add to get > it > > back? > > > > Thanks, > > > > Giordon > > -- > > Giordon Stark > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > -- Giordon Stark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS is ignored when building rootfs
All,
I figured out and solved my issue.
In fact the trouble was not due to the RDEPENDS value, but only to the fact
that the recipe name (folder and bb file) contained one upper case later in
their names.
It seems that to avoid any issue, this is important to not use upper case
letter in recipe folder and file names.
Thanks.
Raphaël.
- Mail original -
De: rtil...@free.fr
À: "Ross Burton"
Cc: yocto@yoctoproject.org
Envoyé: Mercredi 28 Mars 2018 18:17:12
Objet: Re: [yocto] RDEPENDS is ignored when building rootfs
Hello Ross,
Thanks for your quick reply, but I have already tried your suggests:
Without "RDEPENDS", libncurses.is is not in the rootFs,
With "REDEPENDS=ncurses-libncurses", is not in the rootFs also.
I'm sure that the library is not called from a dlopen. The only way to make to
work is to add "ncurses-libform" to the "local.conf" file.
I've spent the whole day to try to understand this issue, and I'm stuck and
surprised that a so basic example does not work as it should.
As a reminder:
- I try to add a very basic recipe to a core-minimal-image
- For the beaglebone.
If you have any others suggestions, feel free.
Raphaël.
- Mail original -
De: "Ross Burton"
À: "Raphaël TILLET"
Cc: yocto@yoctoproject.org
Envoyé: Mercredi 28 Mars 2018 17:57:17
Objet: Re: [yocto] RDEPENDS is ignored when building rootfs
On 28 March 2018 at 16:00, Raphaël TILLET wrote:
> I’m using « Pyro », and have built a very simple recipe. The build program
> Inside the recipe needs « libncurses.so » at run time, so I have added to my
> recipe the following :
>
> DEPENDS_{PN} = « ncurses »
> RDEPENDS_${PN}= « ncurses-libform »
>
>
>
> The build is ok, but my final RootFs does not contain the expected «
> libncurses.so » Library.
>
>
>
> The only way to force the build to include « libncurses.so » in the rootfs
> is to add « ncurses-libform » to my « IMAGE_INSTALL » in « my local.conf »
> file, and normally I should not have to do this…..
If your application links to libncurses normally then you won't need
to do RDEPENDS at all, because the dependency will be added
automatically.
libncurses.so.5 is actually in ncurses-libncurses, so that is what you
should add to RDEPENDS if your application dlopen()s ncurses instead
of linking.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] defconfig file (or fragment files) not used
Hi,
I want to add CAN driver support to the kernel. Here is the procedure I
followed:
1. Generate a .config file
2. Copy it to meta-myWork/recipes-kernel/linux/files/defconfig
3. Update it: set at the end the config to enable CAN as follows
# CAN Bus
CONFIG_NET=y
CONFIG_CAN=y
CONFIG_CAN_RAW=y
CONFIG_CAN_BCM=y
CONFIG_CAN_GW=y
#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=y
# CONFIG_CAN_SLCAN is not set
CONFIG_CAN_DEV=y
# CONFIG_CAN_CALC_BITTIMING is not set
# CONFIG_CAN_LEDS is not set
# CONFIG_CAN_SJA1000 is not set
1. Update the linux-yocto_%.bbappend file as follows
SUMMARY = "Recipe to configure kernel as required"
LICENSE = "CLOSED"
inherit kernel-yocto
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += file://defconfig
1. Request rebuilt:
bitbake linux-yocto-rt -c cleansstate
bitbake -k linux-yocto-rt
Once the image started (with qemu), I check if the CAN is enabled (using zcat
/proc/config.gz | grep CAN) and I always get “CAN not set”
I also tried using fragment and I got the same result ☹
According the user manual, it seems to me I’m doing the right think!
Does someone know why my defconfig file is not taken into account ?
Thanks
Vincent
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS is ignored when building rootfs
Hello Ross,
Thanks for your quick reply, but I have already tried your suggests:
Without "RDEPENDS", libncurses.is is not in the rootFs,
With "REDEPENDS=ncurses-libncurses", is not in the rootFs also.
I'm sure that the library is not called from a dlopen. The only way to make to
work is to add "ncurses-libform" to the "local.conf" file.
I've spent the whole day to try to understand this issue, and I'm stuck and
surprised that a so basic example does not work as it should.
As a reminder:
- I try to add a very basic recipe to a core-minimal-image
- For the beaglebone.
If you have any others suggestions, feel free.
Raphaël.
- Mail original -
De: "Ross Burton"
À: "Raphaël TILLET"
Cc: yocto@yoctoproject.org
Envoyé: Mercredi 28 Mars 2018 17:57:17
Objet: Re: [yocto] RDEPENDS is ignored when building rootfs
On 28 March 2018 at 16:00, Raphaël TILLET wrote:
> I’m using « Pyro », and have built a very simple recipe. The build program
> Inside the recipe needs « libncurses.so » at run time, so I have added to my
> recipe the following :
>
> DEPENDS_{PN} = « ncurses »
> RDEPENDS_${PN}= « ncurses-libform »
>
>
>
> The build is ok, but my final RootFs does not contain the expected «
> libncurses.so » Library.
>
>
>
> The only way to force the build to include « libncurses.so » in the rootfs
> is to add « ncurses-libform » to my « IMAGE_INSTALL » in « my local.conf »
> file, and normally I should not have to do this…..
If your application links to libncurses normally then you won't need
to do RDEPENDS at all, because the dependency will be added
automatically.
libncurses.so.5 is actually in ncurses-libncurses, so that is what you
should add to RDEPENDS if your application dlopen()s ncurses instead
of linking.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RDEPENDS is ignored when building rootfs
On 28 March 2018 at 16:00, Raphaël TILLET wrote:
> I’m using « Pyro », and have built a very simple recipe. The build program
> Inside the recipe needs « libncurses.so » at run time, so I have added to my
> recipe the following :
>
> DEPENDS_{PN} = « ncurses »
> RDEPENDS_${PN}= « ncurses-libform »
>
>
>
> The build is ok, but my final RootFs does not contain the expected «
> libncurses.so » Library.
>
>
>
> The only way to force the build to include « libncurses.so » in the rootfs
> is to add « ncurses-libform » to my « IMAGE_INSTALL » in « my local.conf »
> file, and normally I should not have to do this…..
If your application links to libncurses normally then you won't need
to do RDEPENDS at all, because the dependency will be added
automatically.
libncurses.so.5 is actually in ncurses-libncurses, so that is what you
should add to RDEPENDS if your application dlopen()s ncurses instead
of linking.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] RDEPENDS is ignored when building rootfs
Hi,
I’m using « Pyro », and have built a very simple recipe. The build program
Inside the recipe needs « libncurses.so » at run time, so I have added to my
recipe the following :
- DEPENDS_{PN} = « ncurses »
- RDEPENDS_${PN}= « ncurses-libform »
The build is ok, but my final RootFs does not contain the expected «
libncurses.so » Library.
The only way to force the build to include « libncurses.so » in the rootfs is
to add « ncurses-libform » to my « IMAGE_INSTALL » in « my local.conf » file,
and normally I should not have to do this…..
I’ve search the web, and the RDEPENDS should be the right method, and I did not
find an explanation of such behavior.
Any idea or suggestion ?
Thanks for your feedback or advice.
Raphaël.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
On Wed, Mar 28, 2018 at 2:57 PM, Andrei Gherzan wrote: > Hi guys, > > On Wed, Mar 28, 2018 at 2:40 PM, Paul Barker > wrote: > >> On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher >> wrote: >> > Hi, >> > >> > Thanks I will do that. But I have other layers that depend on the rocko >> of >> > meta-raspberrypi so I believe I will have to use the rocko at some >> point but >> > for testing I will try Morty. What is the reason for using Morty do you >> > know? Is rocko unstable? >> > >> >> Yea, we need to get this fixed in rocko. My test device for >> raspberrypi3 is a Model B v1.2, not a B+ so you may have to help us >> out with testing here. >> >> Could you try out core-image-base built from master with just the >> required layers? If that works then a kernel/firmware backport is >> likely what's needed. >> >> > Today I will have 3b+ support PR to master. Afterwards we can start > backporting things as needed. I'm currently only interested in rocko but if > other people are willing to do it, we can PR stuff in older versions too. > > https://github.com/agherzan/meta-raspberrypi/pull/215 I tested this PR using rocko + meta-rpi master on rpi3b and rpi3b+. Boots ok, wifi connectivity tested with NM and bluetooth pair with bluetoothctl. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
Hi, I can help out on testing if needed. I will try and do a clean build only using the layers required. BR Mans Zigher 2018-03-28 15:40 GMT+02:00 Paul Barker : > On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher > wrote: > > Hi, > > > > Thanks I will do that. But I have other layers that depend on the rocko > of > > meta-raspberrypi so I believe I will have to use the rocko at some point > but > > for testing I will try Morty. What is the reason for using Morty do you > > know? Is rocko unstable? > > > > Yea, we need to get this fixed in rocko. My test device for > raspberrypi3 is a Model B v1.2, not a B+ so you may have to help us > out with testing here. > > Could you try out core-image-base built from master with just the > required layers? If that works then a kernel/firmware backport is > likely what's needed. > > > BR > > Mans Zigher > > > > 2018-03-28 14:38 GMT+02:00 Sherif Omran : > >> > >> Please use Morty, it works fine. > >> > >> On Wed, Mar 28, 2018 at 11:41 AM, Måns Zigher > >> wrote: > >>> > >>> Hi, > >>> > >>> I am using the meta-raspberrypi layer in my build currently on the > rocko > >>> branch. When powering on the rpi3 Model B+ the power led turns red > then when > >>> the green led is turned on the red is turned off and nothing is > booting the > >>> green continues to flash sporadically. My build works fine on rpi 3 > but not > >>> on Model B+. When running raspbian on Model 3 it works fine so it is > not a > >>> power supply issue nor an sdcard issue. Right now I cannot use the > master > >>> branch of meta-raspberrypi because of some patch issues but is the > rocko > >>> branch not supporting rpi 3 on model B+? > >>> > >>> BR > >>> Mans Zigher > >>> > >>> -- > >>> ___ > >>> yocto mailing list > >>> yocto@yoctoproject.org > >>> https://lists.yoctoproject.org/listinfo/yocto > >>> > >> > > > > > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > > > > -- > Paul Barker > Togán Labs Ltd > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
On Wed, Mar 28, 2018 at 1:38 PM, Sherif Omran wrote: > Please use Morty, it works fine. > I don't think that is true though. It needs newer firmware. Not even master has it. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
Hi guys, On Wed, Mar 28, 2018 at 2:40 PM, Paul Barker wrote: > On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher > wrote: > > Hi, > > > > Thanks I will do that. But I have other layers that depend on the rocko > of > > meta-raspberrypi so I believe I will have to use the rocko at some point > but > > for testing I will try Morty. What is the reason for using Morty do you > > know? Is rocko unstable? > > > > Yea, we need to get this fixed in rocko. My test device for > raspberrypi3 is a Model B v1.2, not a B+ so you may have to help us > out with testing here. > > Could you try out core-image-base built from master with just the > required layers? If that works then a kernel/firmware backport is > likely what's needed. > > Today I will have 3b+ support PR to master. Afterwards we can start backporting things as needed. I'm currently only interested in rocko but if other people are willing to do it, we can PR stuff in older versions too. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ssh-copy-id is part of which package?
Hello Anuj, This is very correct. Thank you for the answer. Anyway, I have complicated configuration, so YOCTO copy-ssh-id does not work from client to server, but vice versa is very OK. In this case, server is VM, and client DUT hardware, in between there is transparent host. Host and VM are working via ports forwarding (unidirectionally from host to VM). I need to dive more into this problem, but all ingredients are there for now. Zoran ___ On Wed, Mar 28, 2018 at 1:30 PM, Anuj Mittal wrote: > Hi Zoran, > > On 03/28/2018 07:18 PM, Zoran Stojsavljevic wrote: >> Hello to all, >> >> Seems, that command: >> IMAGE_INSTALL_append = " openssh" >> >> Does install ssh, sshd, but not a ssh-copy-id?! >> >> Strange... ssh-copy-id should be part of the openssh!? >> >> http://lists.openembedded.org/pipermail/openembedded-commits/2015-January/170233.html >> >> root@beaglebone:/root# which ssh-copy-id >> root@beaglebone:/root# which ssh >> /usr/bin/ssh >> root@beaglebone:/root# which sshd >> /usr/sbin/sshd >> root@beaglebone:/root# > > You can try: > > oe-pkgdata-util find-path "/*ssh-copy-id" > > which gives me: > > openssh-misc: /usr/bin/ssh-copy-id -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher wrote: > Hi, > > Thanks I will do that. But I have other layers that depend on the rocko of > meta-raspberrypi so I believe I will have to use the rocko at some point but > for testing I will try Morty. What is the reason for using Morty do you > know? Is rocko unstable? > Yea, we need to get this fixed in rocko. My test device for raspberrypi3 is a Model B v1.2, not a B+ so you may have to help us out with testing here. Could you try out core-image-base built from master with just the required layers? If that works then a kernel/firmware backport is likely what's needed. > BR > Mans Zigher > > 2018-03-28 14:38 GMT+02:00 Sherif Omran : >> >> Please use Morty, it works fine. >> >> On Wed, Mar 28, 2018 at 11:41 AM, Måns Zigher >> wrote: >>> >>> Hi, >>> >>> I am using the meta-raspberrypi layer in my build currently on the rocko >>> branch. When powering on the rpi3 Model B+ the power led turns red then when >>> the green led is turned on the red is turned off and nothing is booting the >>> green continues to flash sporadically. My build works fine on rpi 3 but not >>> on Model B+. When running raspbian on Model 3 it works fine so it is not a >>> power supply issue nor an sdcard issue. Right now I cannot use the master >>> branch of meta-raspberrypi because of some patch issues but is the rocko >>> branch not supporting rpi 3 on model B+? >>> >>> BR >>> Mans Zigher >>> >>> -- >>> ___ >>> yocto mailing list >>> yocto@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/yocto >>> >> > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- Paul Barker Togán Labs Ltd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
Hi, Thanks I will do that. But I have other layers that depend on the rocko of meta-raspberrypi so I believe I will have to use the rocko at some point but for testing I will try Morty. What is the reason for using Morty do you know? Is rocko unstable? BR Mans Zigher 2018-03-28 14:38 GMT+02:00 Sherif Omran : > Please use Morty, it works fine. > > On Wed, Mar 28, 2018 at 11:41 AM, Måns Zigher > wrote: > >> Hi, >> >> I am using the meta-raspberrypi layer in my build currently on the rocko >> branch. When powering on the rpi3 Model B+ the power led turns red then >> when the green led is turned on the red is turned off and nothing is >> booting the green continues to flash sporadically. My build works fine on >> rpi 3 but not on Model B+. When running raspbian on Model 3 it works fine >> so it is not a power supply issue nor an sdcard issue. Right now I cannot >> use the master branch of meta-raspberrypi because of some patch issues but >> is the rocko branch not supporting rpi 3 on model B+? >> >> BR >> Mans Zigher >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
Please use Morty, it works fine. On Wed, Mar 28, 2018 at 11:41 AM, Måns Zigher wrote: > Hi, > > I am using the meta-raspberrypi layer in my build currently on the rocko > branch. When powering on the rpi3 Model B+ the power led turns red then > when the green led is turned on the red is turned off and nothing is > booting the green continues to flash sporadically. My build works fine on > rpi 3 but not on Model B+. When running raspbian on Model 3 it works fine > so it is not a power supply issue nor an sdcard issue. Right now I cannot > use the master branch of meta-raspberrypi because of some patch issues but > is the rocko branch not supporting rpi 3 on model B+? > > BR > Mans Zigher > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Bitbake problems recognizing the latest version of a repo
Hello, Right now it's still a mystery for me when bitbake builds the latest version of a repository and why. I make changes in my code and whether I commit them or not, sometimes bitbake builds a package with the recent version, sometimes with an old version. So my strategy is doing mock changes (adding whitespaces, "enhencing" documentation) and adding signed commits as well as forcing a PR in the recipe and re-running bitbake until it works somehow (I heard the bitbake prefers the signed commits somehow could not verify this yet). Hence, I would like to know what I have to do to build only the latest version of a repository... 1. When it's local on my computer (with EXTERNALSRC_BUILD_pn- = "/home/some/local/location/" in local.conf), 2. When I build from a github or any remote repository. Thanks and Best Regards, Jakob -- Jakob Hasse Software Developement E: jakob.ha...@smart-home-technology.ch T: +41 44 552 02 66 Smart Home Technology GmbH www.smart-home-technology.ch -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ssh-copy-id is part of which package?
Hi Zoran, On 03/28/2018 07:18 PM, Zoran Stojsavljevic wrote: > Hello to all, > > Seems, that command: > IMAGE_INSTALL_append = " openssh" > > Does install ssh, sshd, but not a ssh-copy-id?! > > Strange... ssh-copy-id should be part of the openssh!? > > http://lists.openembedded.org/pipermail/openembedded-commits/2015-January/170233.html > > root@beaglebone:/root# which ssh-copy-id > root@beaglebone:/root# which ssh > /usr/bin/ssh > root@beaglebone:/root# which sshd > /usr/sbin/sshd > root@beaglebone:/root# You can try: oe-pkgdata-util find-path "/*ssh-copy-id" which gives me: openssh-misc: /usr/bin/ssh-copy-id -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ssh-copy-id is part of which package?
Hello to all, Seems, that command: IMAGE_INSTALL_append = " openssh" Does install ssh, sshd, but not a ssh-copy-id?! Strange... ssh-copy-id should be part of the openssh!? http://lists.openembedded.org/pipermail/openembedded-commits/2015-January/170233.html root@beaglebone:/root# which ssh-copy-id root@beaglebone:/root# which ssh /usr/bin/ssh root@beaglebone:/root# which sshd /usr/sbin/sshd root@beaglebone:/root# Thank you, Zoran -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to add libsrtp and libsrtp-staticdev to sdk
On 28 March 2018 at 11:56, Mostafa Farzane wrote: > -- ERROR: jrtplib-3.11.1-r0 do_populate_sysroot: QA Issue: jrtplib.pc failed > sanity test (tmpdir) in path > /opt/yocto/toradex-morty/build-intercom/tmp-glibc/work/armv7at2hf-neon-angstrom-linux > gnueabi/jrtplib/3.11.1-r0/sysroot-destdir/usr/lib/pkgconfig [pkgconfig] > -- ERROR: jrtplib-3.11.1-r0 do_populate_sysroot: QA staging was broken by > the package built above The problem is that the jrtplib.pc file contains the build path, which is broken. You'll have to look at the build system and understand how that happens, and fix it. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake failure:
Thanks, I'll look into it. For yocto-2.5 M3 rc1 they have given as bitbake -c fetchall core-image-sato That means it is a failure. On Tue, Mar 27, 2018, 7:52 PM Joshua Watt wrote: > On Tue, 2018-03-27 at 09:19 +, pawanKumar wrote: > > Thanks for your tip. > Can I use capital c in place of small c. > > > Not quite sure what you mean. If you are trying to do: > > bitbake -C fetchall core-image-sato > > that doesn't work anymore AFAIK. I don't think there is currently a way to > do a "force invalidate" (e.g. -f) with --runall, although TBH I'm not sure > if 'bitbake -C fetchall' did that anyway. Perhaps someone more familiar > with the recursive dependencies can chime in. > > However, I recently ran into a case where having -f apply to --runall was > useful, so I have a patch in my contrib tree to add support for it. If > that's what you're trying to do, I'm curious what the use case is? I > haven't pushed the patch to the mailing list because I'm not sure if my use > is actually valid. > > > On Fri, Mar 23, 2018, 9:20 PM Joshua Watt wrote: > > On Fri, 2018-03-23 at 07:31 +, pawanKumar wrote: > > Hi team, > When I tried to run (bitbate -c fetchall) it is giving error as > "target do_fetchall is not found for image core-image-sato". > How to over come this error. > > > I believe fetchall was superseded by --runall. Try: > > bitbake --runall fetch core-image-sato > > > Regards > Pavan. > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [matchbox-wm][PATCH v2] configure.ac: add lib math for composite enabled builds
Pushed, thanks. Ross On 27 March 2018 at 08:06, Awais Belal wrote: > The composite enabled builds require lib math to be > present on the linker command line otherwise we get > ld: composite-engine.o: undefined reference to symbol 'exp@@GLIBC_2.2.5' > during compilation. > > Signed-off-by: Awais Belal > --- > configure.ac | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure.ac b/configure.ac > index dce82cc..a3e384f 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -248,6 +248,7 @@ dnl -- Composite > --- > if test x$enable_composite != xno; then >PKG_CHECK_MODULES(COMPO, xcomposite xfixes xdamage xrender, , >AC_MSG_ERROR([*** Required Composite Librays not > installed ***])) > + COMPO_LIBS="$COMPO_LIBS -lm" > >AC_DEFINE(USE_COMPOSITE, [1], [use bleeding enge composite code]) > > -- > 2.7.4 > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting
Hi, I am using the meta-raspberrypi layer in my build currently on the rocko branch. When powering on the rpi3 Model B+ the power led turns red then when the green led is turned on the red is turned off and nothing is booting the green continues to flash sporadically. My build works fine on rpi 3 but not on Model B+. When running raspbian on Model 3 it works fine so it is not a power supply issue nor an sdcard issue. Right now I cannot use the master branch of meta-raspberrypi because of some patch issues but is the rocko branch not supporting rpi 3 on model B+? BR Mans Zigher -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 2/2] audit: fix pkgconfigdir
Hi,
On 03/28/2018 02:55 PM, Kai Kang wrote:
> Because 'libdir' is set with ${base_libdir} in recipe file of audit,
> package config files(.pc) are installed to ${base_libdir}/pkgconfig that
> variable pkgconfigdir is set with ${libdir}/pkgconfig in makefile.
>
> Set pkgconfigdir directly to install .pc files to right directory.
>
> Signed-off-by: Kai Kang
> ---
> recipes-security/audit/audit_2.7.6.bb | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/recipes-security/audit/audit_2.7.6.bb
> b/recipes-security/audit/audit_2.7.6.bb
> index 5bfda7b..33b49c9 100644
> --- a/recipes-security/audit/audit_2.7.6.bb
> +++ b/recipes-security/audit/audit_2.7.6.bb
> @@ -45,6 +45,7 @@ EXTRA_OEMAKE += "PYLIBVER='python${PYTHON_BASEVERSION}' \
> PYINC='${STAGING_INCDIR}/$(PYLIBVER)' \
> pyexecdir=${libdir}/python${PYTHON_BASEVERSION}/site-packages \
> STDINC='${STAGING_INCDIR}' \
> + pkgconfigdir=${libdir}/pkgconfig \
> "
>
> SUMMARY_audispd-plugins = "Plugins for the audit event dispatcher"
> @@ -64,7 +65,7 @@ FILES_audispd-plugins +=
> "${sysconfdir}/audisp/audisp-remote.conf \
> "
> FILES_${PN}-dbg += "${libdir}/python${PYTHON_BASEVERSION}/*/.debug"
> FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}"
> -FILES_${PN}-dev += "${base_libdir}/*.so ${base_libdir}/*.la
> ${base_libdir}/pkgconfig/*"
> +FILES_${PN}-dev += "${base_libdir}/*.so ${base_libdir}/*.la"
Aren't these already part of FILES_${PN}-dev in bitbake.conf in oe-core?
Thanks,
Anuj
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 0/2] Fix systemd configure error when enable audit
On 2018年03月28日 14:55, Kai Kang wrote: Test with configure in local.conf DISTRO_FEATURES_append = " selinux systemd" Kai Kang (2): enable-audit.bbclass: remove implement of packageconfig audit audit: fix pkgconfigdir classes/enable-audit.bbclass | 1 - recipes-security/audit/audit_2.7.6.bb | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) Forgot layer info meta-selinux in the title. -- Regards, Neil | Kai Kang -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
