This is the current RDEPENDS setting in kernel-devsrc.bb recipe:
RDEPENDS_${PN} = "bc python flex bison ${TCLIBC}-utils"
# 4.15+ needs these next two RDEPENDS
RDEPENDS_${PN} += "openssl-dev util-linux"
# and x86 needs a bit more for 4.15+
RDEPENDS_${PN} += "${@bb.utils.contains('ARCH', 'x86', 'el
ollected errors:
* check_data_file_clashes: Package suricata wants to install file
.../1.0-r0/rootfs/var/run
But that file is already provided by package * base-files
Signed-off-by: Armin Kuster
---
recipes-security/suricata/suricata_4.0.5.bb | 6 +-
1 file changed, 5 insertions(+
On Thu, Oct 18, 2018 at 2:10 PM Zolee K wrote:
>
> Hehttp://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-daemons/proftpd/proftpd_1.3.6.bb?h=master#n99llo,
>
> I'm very new to the Yocto Project and I got a Barix module that is to be
> developped with Yocto.
> I managed to i
Thank you
Il gio 18 ott 2018, 22:48 Sinan Kaya ha scritto:
> On 10/18/2018 3:08 PM, Joe MacDonald wrote:
> >> Sorry, I thought it had been created. I'm going to be traveling the
> >> next few days to ELC-E, but I will try to get to it if someone else
> >> does not first.
> > Yeah, Mark and I ar
Hello,
I'm very new to the Yocto Project and I got a Barix module that is to be
developped with Yocto.
I managed to insert the desired programs into the linux image (nano, rsync,
mc, proftpd, vlc) by modifying a recipe file but now I'd like to make some
changes. I thought I would start with modify
> Paul Eggleton wrote on 10/18/2018
12:30:07 PM:
>
> I think we would *like* this to be possible, from what I can tell I
think the
> issue is that the copies of the library in the sysroots of other
dependent
> recipes aren't being updated. The eSDK (and devtool) were originally
written
> wh
On 10/18/2018 3:08 PM, Joe MacDonald wrote:
Sorry, I thought it had been created. I'm going to be traveling the
next few days to ELC-E, but I will try to get to it if someone else
does not first.
Yeah, Mark and I are both going to be at ELC-E this week, we'll get it
sorted out.
thanks.
--
___
[Re: [yocto] [selinux] sumo compilation] On 18.10.18 (Thu 11:00) Mark Hatle
wrote:
> On 10/18/18 9:49 AM, Sinan Kaya wrote:
> > CC'ing the selinux maintainers:
> >
> > I was told that using the master branch and reverting the e2fs change
> > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinu
> Alexander Kanavin wrote on 10/18/2018 11:30:17
AM:
>
> I don’t think esdk is designed for this kind of ‘full stack’
> development. You can go back to working directly with yocto layers,
> and skip the esdk altogether. Devtool will work exactly same (minus
> the sdk specific commands).
>
> A
I think we would *like* this to be possible, from what I can tell I think the
issue is that the copies of the library in the sysroots of other dependent
recipes aren't being updated. The eSDK (and devtool) were originally written
when there weren't recipe-specific sysroots, and this stuff was a
I don’t think esdk is designed for this kind of ‘full stack’ development. You
can go back to working directly with yocto layers, and skip the esdk
altogether. Devtool will work exactly same (minus the sdk specific commands).
Alex
> On 18 Oct 2018, at 19.37, aaron_wri...@selinc.com wrote:
>
> M
My team recently started using the eSDK for day-to-day development.
Previously, they were using the bitbake command to build, which works, but
has overhead. Yesterday three different people came up to me a question
about workflow with the eSDK, and they all had to do with dependent
recipes in t
Hi Guys,
I got the following conflicting requests error while building SDK
I am using sumo branch , and generic core-intel-i7-64 machine configuration.
Running the following command: bitbake -c populate_sdk core-image-minimal
Fails at the last step with the following error.
ERROR: core-image-m
Thanks Steve,
We'll give it a try.
On 10/18/2018 11:46 AM, Steve Scott wrote:
You may also need
PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-standard"
in local.conf.
-steve
-Original Message-
From: Sinan Kaya [mailto:ok...@kernel.org]
Sent: Thursday, October 18, 2018 8:06 A
On 10/18/18 9:49 AM, Sinan Kaya wrote:
> CC'ing the selinux maintainers:
>
> I was told that using the master branch and reverting the e2fs change
> (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151)
>
> works on sumo.
>
> Stefano's sugg
Always send the Build Configuration that bitbake prints on top of
build. So someone can get some additional information about your build
to help you better.
On Thu, Oct 18, 2018 at 1:03 AM Dhanush K.S wrote:
>
> Hello Yocto,
>
> I'm currently building an image with the busybox_1.23.2.bb recipe inc
You may also need
PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-standard"
in local.conf.
-steve
> -Original Message-
> From: Sinan Kaya [mailto:ok...@kernel.org]
> Sent: Thursday, October 18, 2018 8:06 AM
> To: ssc...@san.rr.com; 'Stefano Cappa'
> Cc: yocto@yoctoproject.org
> Su
Wrong mailing list. Use meta-virtualization for these patches.
I'm cross posting this there, for the archives.
I've grabbed and merged this change (but could easily have missed
it, since it was the wrong list and I wasn't directly copied).
Bruce
On 10/15/18 9:45 PM, kai.k...@windriver.com wrot
Sorry for confusing names, not enough coffee yet...
I was trying to say that Steve's suggestion to use
PREFERRED_VERSION_refpolicy-standard = "2.20170204"
didn't work on sumo branch.
On 10/18/2018 10:49 AM, Sinan Kaya wrote:
CC'ing the selinux maintainers:
I was told that using the master br
CC'ing the selinux maintainers:
I was told that using the master branch and reverting the e2fs change
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78eca8242ea5397c4dc0654d62244453b4260151)
works on sumo.
Stefano's suggestion unfortunately didn't work.
Maybe, it is time t
I did not try it on sumo.
From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
Sent: Wednesday, October 17, 2018 11:15 PM
To: ssc...@san.rr.com
Cc: Sinan Kaya ; yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation
Exactly the same issue since September.
Here is
Hello Kosta,
> I suggest trying other reference image.
> For example, core-image-minimal.
As said, I have tried instead core-image-base ==>> core-image-minimal
one on the target platform, which is BBB. To my surprise it is in
there (in the minimal initramfs)!
Since the eth0 IP address upon sumo
>I suspect the proper solution is to treat the -e output as shell-like
>From the bitbake/lib/bb/data.py:
"""Emits all items in the data store in a format such that it can be
sourced by a shell."""
so if you say it's shell-like, not shell, shouldn't we replace that to
"""Emits all items in the data
Well, as you've discovered, bitbake variables can have names that are
invalid in shell. I suspect the proper solution is to treat the -e
output as shell-like, and parse it with a proper parser.
Ross
On Thu, 18 Oct 2018 at 09:56, Tomasz Dziendzielski
wrote:
>
> So what is the proper solution?
>
>
So what is the proper solution?
Best regards,
Tomasz Dziendzielski
wt., 16 paź 2018 o 16:00 Tomasz Dziendzielski <
tomasz.dziendziel...@gmail.com> napisał(a):
> Yes, I want to source the data files. I'm trying to adapt devtool the way
> it's creating the workspace, then I'm sourcing a script wit
Hello Yocto,
I'm currently building an image with the busybox_1.23.2.bb recipe included,
using Yocto Sumo 2.5 with the Bitbake version 1.37.0. It is running on a
CentOS host building images for the target ARM cortexa8. This busybox
recipe is placed in another custom layer. Though this recipe compi
From: Changqing Li
Fix below problem:
MACHINE=intel-x86-64
SDKMACHINE = "i686-mingw32"
bitbake freetype
do_compile failed with below error:
x86_64-wrs-linux-libtool: compile: x86_64-wrs-linux-windres
--include-dir=work/corei7-64-wrs-linux/freetype/2.9.1-r0/recipe-sysroot/usr/include
/work/corei
27 matches
Mail list logo
