Hi,
I've a custom Yocto layer and use that as TEMPLATECONF for building. My
custom layer also contains the image recipe based on pulsar-image (from
meta-ivi).
I'm using Yocto 2.5. The extensible sdk build fails at do_populate_sdk_ext
task for my image recipe.
$ bitbake -f -c populate_sdk_ext
Er
Hi Ulrich,
ok, I guess I miss-understand how that class works. I thought that I had to
add the customization on my own image recipe.
So the correct way is to write a 'customization recipe' and install via
IMAGE_INSTALL? Can you provide an example?
Thanks,
Gabriele
Il giorno mer 24 apr 2019 alle
catching up with all the YP stuff i've missed over the last while
and, in the BSP guide in the layers section:
https://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers
one reads:
"Some layers function as a layer to hold other BSP layers. These
layers are knows as "containe
Right, meta-intel isn't a container layer. It just has two MACHINES.
Ross
On Thu, 2 May 2019 at 13:54, Robert P. J. Day wrote:
>
>
> catching up with all the YP stuff i've missed over the last while
> and, in the BSP guide in the layers section:
>
> https://www.yoctoproject.org/docs/latest/bs
As meta-intel is no longer a container layer, use meta-xilinx as
an example instead.
Signed-off-by: Robert P. J. Day
---
diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml
index 0bb0b68ab..a53ff6bce 100644
--- a/documentation/bsp-guide/bsp.xml
+++ b/documentation/bsp
Apologies for cross posting but I wanted a wider audience to see this.
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 appropria
Hi,
The official ofono.inc recipe defines SYSTEMD_SERVICE_${PN} =
"ofono.service", but when I built the image, the system service does
not start ofono daemon automatically, I have to run the ofono daemon
manually. What I could be missing here? Here is the ofono recipes,
sorry if I need to ask ofon
On Thu, 25 Apr 2019, Richard Purdie wrote:
> On Thu, 2019-04-25 at 08:05 -0400, Robert P. J. Day wrote:
... snip ...
> > ASSUME_PROVIDED += "cmake-native"
>
> This is a bad idea as we patch cmake iirc.
... snip ...
>
> You would also have to do:
>
> HOSTTOOLS += "cmake"
>
> to allow cmake to
I got this response to my recent email:
Your message to mail...@yoctoproject.org couldn't be delivered.
mailman wasn't found at yoctoproject.org.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> As meta-intel is no longer a container layer, use meta-xilinx as
> an example instead.
I thought "meta-virtualization" was a container layer?
IMHO, a BSP should only deal with getting a MACHINE booted.
- armin
>
> Signed-off-by: Robert P. J. Day
>
Looks like it's dropping the service in ${sysconfdir}/init.d which resolves
to /etc/init.d. I'm not sure that systemd won't look into init.d for
services. The standard place to put them is ${D}/${systemd_system_unitdir},
which resolves to /lib/systemd/system.
Also, check the "SYSTEMD_AUTO_ENABLE_p
On 5/2/19 5:43 AM, Searles, Dan wrote:
>
> I got this response to my recent email:
>
>
>
> Your message to mail...@yoctoproject.org couldn't be delivered.
>
What mailing list did you send it to originally ?
- armin
>
> mailman wasn't found at yoctoproject.org.
>
>
>
>
--
_
The term "Container Layer" was put in the ref-manual by me to describe a
"meta-*" layer that had other "meta-*" layers (see
https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
and the term "Container Layer"). Maybe this was never a good term? I
don't know. Nobod
> Looks like it's dropping the service in ${sysconfdir}/init.d which
> resolves to /etc/init.d. I'm not sure that systemd won't look into
> init.d for services.
It doesn't.
> The standard place to put them is ${D}/${systemd_system_unitdir},
> which resolves to /lib/systemd/system.
Systemd's unit
On 5/2/19 10:45 AM, Scott Rifenbark wrote:
> The term "Container Layer" was put in the ref-manual by me to describe
> a "meta-*" layer that had other "meta-*" layers (see
> https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
> and the term "Container Layer"). Ma
Great, thanks!
On Thu, May 2, 2019 at 11:21 AM akuster wrote:
>
>
> On 5/2/19 10:45 AM, Scott Rifenbark wrote:
>
> The term "Container Layer" was put in the ref-manual by me to describe a
> "meta-*" layer that had other "meta-*" layers (see
> https://www.yoctoproject.org/docs/2.7/ref-manual/ref-
I apologize if I missed any communication on this mailing list but what
are the plans for a presence of YP at ELC NA in August in San Diego this
year?
Unfortunately, I missed the deadline for submitting a speaking proposal
("Yocto Project DevOps with Gitlab, Docker and AWS") for ELC. However,
much snipping ...
On Thu, 2 May 2019, Scott Rifenbark wrote:
> On Thu, May 2, 2019 at 10:21 AM akuster wrote:
>
>
> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> > As meta-intel is no longer a container layer, use meta-xilinx as
> > an example instead.
>
> I thought "m
On Thu, 2 May 2019, Scott Rifenbark wrote:
> Great, thanks!
>
> On Thu, May 2, 2019 at 11:21 AM akuster wrote:
>
> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> > As meta-intel is no longer a container layer, use meta-xilinx as
> > an example instead.
>
> I thought "meta-vi
On Thursday, May 02, 2019 8:15 PM, Henrik Lindblom wrote:
>>> FILES_${PN} += "${systemd_unitdir}"
>
> This line is redundant, AFAIK, since systemd.bbclass will handle
> packaging for you, assuming you install the service files that you
> advertise in SYSTEMD_SERVICE_${PN}. However, as I'm writing t
On Thursday, May 02, 2019 8:15 PM, Henrik Lindblom wrote:
>>> FILES_${PN} += "${systemd_unitdir}"
>
> This line is redundant, AFAIK, since systemd.bbclass will handle
> packaging for you, assuming you install the service files that you
> advertise in SYSTEMD_SERVICE_${PN}. However, as I'm writing
hi Rudolf,
+Andreea (Yocto Advocacy)
we are definitely planning to be at ELC, with a similar setup as with
past ELC : booth, demo, DevDay and BoF, well, at least !
cheers
nico
On Thu, May 2, 2019 at 9:31 PM Rudolf J Streif wrote:
>
> I apologize if I missed any communication on this mailing li
Hi Rudi,
That sounds super interesting. We do have a 6'x6' exhibit booth on the show
floor, and a DevDay on Tuesday, August 20.
Are you planning to show just the instrument cluster, or the whole gokart? If
the gokart, I would just need to check with LF and see if we are allowed to
have that on
Hi Rudi,
That's awesome! I will check with LF events to see if there are any issues with
showing that or restrictions with how people engage with it during the show.
Definitely in favor of showing the whole gokart.
Thanks!
Andreea
-Original Message-
From: Rudolf J Streif [mailto:rudolf
Hi Andrea,
Great. I can bring some wooden blocks to prop up the rear-end. People
could sit in it and spin the wheels.
:rjs
On 5/2/19 2:39 PM, Volosincu, Andreea S wrote:
Hi Rudi,
That's awesome! I will check with LF events to see if there are any issues with
showing that or restrictions wi
Hi,
I'm currently working on repackaging the 2016 Intel compiler and I am
stuck at the dependency resolution.
I am basing my recipe on the AUR PKGBUILD [1], which extracts the RPMs
from the parallel-studio-xe [2] archive and extracts the content of the
RPMs to get the binaries. I already hav
Why don't you use the layer that comes with the Intel compiler?
Ross
On Thu, 2 May 2019 at 23:15, wrote:
>
> Hi,
>
> I'm currently working on repackaging the 2016 Intel compiler and I am
> stuck at the dependency resolution.
>
> I am basing my recipe on the AUR PKGBUILD [1], which extracts the R
Yes, the image will be deployed on the CI to build our software. I
managed to just drop the files at some place, but it requires user input
to install the compiler.
Simon
On 03.05.2019 01:19, Burton, Ross wrote:
Do you mean you want to build packages to run icc on the target?
On Thu, 2 May 2
corosync 1.x have removed from meta-cgl, and use corosync under meta-networking.
corosync 2.x can replace corosync 1.x + openais (in meta-cgl),
so remove depend on openais
Signed-off-by: Armin Kuster
---
meta-cgl-common/recipes-cgl/cluster/cluster_3.2.0.bb | 4 ++--
1 file changed, 2 insertions
corosync 2.x can replace corosync 1.x + openais.
openais is no longer maintainted and shutdown.
https://github.com/corosync/openais/commit/f2bc4445a7c4ba5d17a218af855dc19d55ed2803
Signed-off-by: Armin Kuster
---
.../openais/files/build-cleanup-configure-ac.patch | 41 -
.../open
Signed-off-by: Armin Kuster
---
meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
index cd97fec..6ec68c4 10064
bug fix release.
Signed-off-by: Armin Kuster
---
.../libseccomp/{libseccomp_2.4.0.bb => libseccomp_2.4.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/libseccomp/{libseccomp_2.4.0.bb =>
libseccomp_2.4.1.bb} (96%)
diff --git a/recipes-security/libseccomp
Signed-off-by: Armin Kuster
---
recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg | 6 --
1 file changed, 6 deletions(-)
diff --git a/recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg
b/recipes-kernel/linux/linux-yocto-5.0/apparmor.cfg
index b5f9bb2..ae6cdcd 100644
--- a/recipes-kernel/linu
Hi,
Are there any Yocto recipes to support dual version control for
firmware image upgrade and boot?
The scenario is to make 2 partitions, one partition to install a work
version of image, say v1.0, another partition to install a development
version of image, say v1.1, the boot process should pic
Hi Gabriele,
On Thu, May 02 2019 at 13:25 +0200, Gabriele Zampieri
wrote:
> ok, I guess I miss-understand how that class works. I thought that I
> had to add the customization on my own image recipe.
> So the correct way is to write a 'customization recipe' and install
> via IMAGE_INSTALL? Can y
Hi,
I've been experimenting with mender a bit lately. Works great so far and it's
fully integrated into yocto:
https://mender.io/
There are a few other solutions available for Yocto:
https://wiki.yoctoproject.org/wiki/System_Update#Comparison
Regards,
Cyril
__
36 matches
Mail list logo
