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
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
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
---
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
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
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 -
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
>
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").
> 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
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.
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.
>
>
>
>
--
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
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
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 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
Hi,
I need to partition the Flash storage to use dual versions of firmware
/ image, can it be defined in recipe?
Thank you.
Kind regards,
- jupiter
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
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
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
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
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
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
On Thu, Mar 28, 2019 at 6:36 AM Teemu K wrote:
>
> On Mon, Mar 18, 2019 at 7:21 AM Teemu K wrote:
> >
> > On Fri, Mar 15, 2019 at 2:17 AM akuster wrote:
> > >
> > >
> > >
> > > On 3/13/19 9:50 PM, Teemu K wrote:
> > >
> > > Hi,
> > >
> > > I noticed that when trying to build sdk on thud it
35 matches
Mail list logo
