Date   

Re: Yocto Project @ ELC NA 2019

Volosincu, Andreea S
 

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.streif@ibeeto.com]
Sent: Thursday, May 2, 2019 2:36 PM
To: Volosincu, Andreea S <andreea.volosincu@windriver.com>; Nicolas Dechesne <nicolas.dechesne@linaro.org>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

Hi Andrea,

I was intending to bring the whole gokart. It's more fun to see the speedometer go up when you push down on the pedal and the regen to kick in when letting go etc. Everybody has seen hundreds of instrument cluster demos (at least when you work for the automotive industry). It might be a crowd catcher too (at least that's what I figured when I was at CES this year; a booth with a vehicle had many spectators :).

Please see early picture (without cluster) attached.

:rjs

On 5/2/19 2:17 PM, Volosincu, Andreea S wrote:
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 the show floor. It's certainly a new thing we haven't tried or had before.

Thanks!
Andreea

-----Original Message-----
From: Nicolas Dechesne [mailto:nicolas.dechesne@linaro.org]
Sent: Thursday, May 2, 2019 1:17 PM
To: Rudolf J Streif <rudolf.streif@ibeeto.com>; Volosincu, Andreea S
<andreea.volosincu@windriver.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

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 <rudolf.streif@ibeeto.com> wrote:
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, if YP is planning on a presence at ELC I'd be happy to
support it as I, conveniently, live in San Diego. If there is a YP
exhibition I might be able to bring my little hobby project, an
electric gokart with YP-based instrument cluster (it's a full-size
kart with 13 kW AC motor and a LiFePo battery pack producing up to 25
kW peak power output going up to
45 mph (electronically limited)).

Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: Yocto Project @ ELC NA 2019

Rudolf J Streif
 

Hi Andrea,

I was intending to bring the whole gokart. It's more fun to see the speedometer go up when you push down on the pedal and the regen to kick in when letting go etc. Everybody has seen hundreds of instrument cluster demos (at least when you work for the automotive industry). It might be a crowd catcher too (at least that's what I figured when I was at CES this year; a booth with a vehicle had many spectators :).

Please see early picture (without cluster) attached.

:rjs

On 5/2/19 2:17 PM, Volosincu, Andreea S wrote:
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 the show floor. It's certainly a new thing we haven't tried or had before.

Thanks!
Andreea

-----Original Message-----
From: Nicolas Dechesne [mailto:nicolas.dechesne@linaro.org]
Sent: Thursday, May 2, 2019 1:17 PM
To: Rudolf J Streif <rudolf.streif@ibeeto.com>; Volosincu, Andreea S <andreea.volosincu@windriver.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

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 <rudolf.streif@ibeeto.com> wrote:
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, if YP is planning on a presence at ELC I'd be happy to
support it as I, conveniently, live in San Diego. If there is a YP
exhibition I might be able to bring my little hobby project, an
electric gokart with YP-based instrument cluster (it's a full-size
kart with 13 kW AC motor and a LiFePo battery pack producing up to 25
kW peak power output going up to
45 mph (electronically limited)).

Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: Yocto Project @ ELC NA 2019

Volosincu, Andreea S
 

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 the show floor. It's certainly a new thing we haven't tried or had before.

Thanks!
Andreea

-----Original Message-----
From: Nicolas Dechesne [mailto:nicolas.dechesne@linaro.org]
Sent: Thursday, May 2, 2019 1:17 PM
To: Rudolf J Streif <rudolf.streif@ibeeto.com>; Volosincu, Andreea S <andreea.volosincu@windriver.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] Yocto Project @ ELC NA 2019

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 <rudolf.streif@ibeeto.com> wrote:

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, if YP is planning on a presence at ELC I'd be happy to
support it as I, conveniently, live in San Diego. If there is a YP
exhibition I might be able to bring my little hobby project, an
electric gokart with YP-based instrument cluster (it's a full-size
kart with 13 kW AC motor and a LiFePo battery pack producing up to 25
kW peak power output going up to
45 mph (electronically limited)).

Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: Yocto Project @ ELC NA 2019

Nicolas Dechesne
 

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 <rudolf.streif@ibeeto.com> wrote:

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,
if YP is planning on a presence at ELC I'd be happy to support it as I,
conveniently, live in San Diego. If there is a YP exhibition I might be
able to bring my little hobby project, an electric gokart with YP-based
instrument cluster (it's a full-size kart with 13 kW AC motor and a
LiFePo battery pack producing up to 25 kW peak power output going up to
45 mph (electronically limited)).

Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: System service

Lukasz Zemla <Lukasz.Zemla@...>
 

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 this from
memory, I recommend you skim through the class definition and check
for further details there.
I confirm - this line is not required (at least at Yocto 2.6).

Best regards,
Lukasz Zemla


Re: [EXTERNAL] Re: System service

Lukasz Zemla <Lukasz.Zemla@...>
 

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 this from
memory, I recommend you skim through the class definition and check
for further details there.
I confirm - this line is not required (at least at Yocto 2.6).

Best regards,
Lukasz Zemla

***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed.  If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***


Re: [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Robert P. J. Day
 

On Thu, 2 May 2019, Scott Rifenbark wrote:

Great, thanks!

On Thu, May 2, 2019 at 11:21 AM akuster <akuster@mvista.com> 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-virtualization" was a container layer?
as a followup, i would think that "meta-openembedded" is the
canonical example of a container layer, no?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Robert P. J. Day
 

much snipping ...

On Thu, 2 May 2019, Scott Rifenbark wrote:

On Thu, May 2, 2019 at 10:21 AM akuster <akuster@mvista.com> 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-virtualization" was a container layer?
uh, i'm looking at meta-virtualization right now:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/

and that looks like a regular BSP layer, not a container layer. am i
misunderstanding some fundamental point here?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Yocto Project @ ELC NA 2019

Rudolf J Streif
 

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, if YP is planning on a presence at ELC I'd be happy to support it as I, conveniently, live in San Diego. If there is a YP exhibition I might be able to bring my little hobby project, an electric gokart with YP-based instrument cluster (it's a full-size kart with 13 kW AC motor and a LiFePo battery pack producing up to 25 kW peak power output going up to 45 mph (electronically limited)).

Cheers,
Rudi

--
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700


Re: [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Scott Rifenbark <srifenbark@...>
 

Great, thanks!

On Thu, May 2, 2019 at 11:21 AM akuster <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-manual.html#term-container-layer and the term "Container Layer").  Maybe this was never a good term?  I don't know.  Nobody has said anything about that term for many releases. 

The problem Robert points out needs to be fixed in the BSP manual as "meta-intel" is not longer qualifying by my definition.  I can fix that. 

Is "Container Layer" ok as I have defined it?
in those terms above, yes its fine.

thanks for clarifying.

Armin

Thanks,
Scott

On Thu, May 2, 2019 at 10:21 AM akuster <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-virtualization" was a container layer?

IMHO, a BSP should only deal with getting a MACHINE booted.

- armin
>
> Signed-off-by: Robert P. J. Day <rpjday@...>
>
> ---
>
> 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-guide/bsp.xml
> @@ -146,18 +146,15 @@
>
>      <para>
>          Some layers function as a layer to hold other BSP layers.
> -        These layers are knows as
> +        These layers are known as
>          "<ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>container layers</ulink>".
>          An example of this type of layer is the
> -        <filename>meta-intel</filename> layer.
> -        This layer contains BSP layers for the Intel-core2-32
> -        <trademark class='registered'>Intel</trademark> Common Core
> -        (Intel-core2-32) and the Intel-corei7-64
> -        <trademark class='registered'>Intel</trademark> Common Core
> -        (Intel-corei7-64).
> -        the <filename>meta-intel</filename> layer also contains
> -        the <filename>common/</filename> directory, which contains
> -        common content across those layers.
> +        <filename>meta-xilinx</filename> layer.
> +        This container layer contains some basic top-level information,
> +        as well as three actual Xilinx-related BSP layers,
> +        <filename>meta-xilinx-bsp</filename>,
> +        <filename>meta-xilinx-contrib</filename>, and
> +        <filename>meta-xilinx-standalone</filename>.
>      </para>
>
>      <para>
>

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Armin Kuster
 



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").  Maybe this was never a good term?  I don't know.  Nobody has said anything about that term for many releases. 

The problem Robert points out needs to be fixed in the BSP manual as "meta-intel" is not longer qualifying by my definition.  I can fix that. 

Is "Container Layer" ok as I have defined it?
in those terms above, yes its fine.

thanks for clarifying.

Armin

Thanks,
Scott

On Thu, May 2, 2019 at 10:21 AM akuster <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-virtualization" was a container layer?

IMHO, a BSP should only deal with getting a MACHINE booted.

- armin
>
> Signed-off-by: Robert P. J. Day <rpjday@...>
>
> ---
>
> 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-guide/bsp.xml
> @@ -146,18 +146,15 @@
>
>      <para>
>          Some layers function as a layer to hold other BSP layers.
> -        These layers are knows as
> +        These layers are known as
>          "<ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>container layers</ulink>".
>          An example of this type of layer is the
> -        <filename>meta-intel</filename> layer.
> -        This layer contains BSP layers for the Intel-core2-32
> -        <trademark class='registered'>Intel</trademark> Common Core
> -        (Intel-core2-32) and the Intel-corei7-64
> -        <trademark class='registered'>Intel</trademark> Common Core
> -        (Intel-corei7-64).
> -        the <filename>meta-intel</filename> layer also contains
> -        the <filename>common/</filename> directory, which contains
> -        common content across those layers.
> +        <filename>meta-xilinx</filename> layer.
> +        This container layer contains some basic top-level information,
> +        as well as three actual Xilinx-related BSP layers,
> +        <filename>meta-xilinx-bsp</filename>,
> +        <filename>meta-xilinx-contrib</filename>, and
> +        <filename>meta-xilinx-standalone</filename>.
>      </para>
>
>      <para>
>

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: System service

Henrik Lindblom <henriklindblomster@...>
 

> 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 search path is documented in


but the ones I've personally used most are /usr/lib/systemd/user and
/etc/systemd/system. These are a personal preference more than
anything else.

>> do_install_append() {
>>   install -d ${D}${sysconfdir}/init.d/
>>   install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
>> }

do_install() seems to be installing only non-systemd ofono shell
script in.

>> 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 this from
memory, I recommend you skim through the class definition and check
for further details there.

Cheers,
Henrik


On Thu, May 2, 2019 at 8:28 PM Timothy Froehlich <tfroehlich@...> wrote:
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_pn-ofono" variable for that recipe. The systemd class sets it to "enable" by default, but something else could be overriding it and setting it to "disable".  Alternatively, confirm that the service isn't actually starting up and failing. It may be that you're restarting it once the system is fully booted and everything ofono needs is now ready.

On Thu, May 2, 2019 at 7:55 AM JH <jupiter.hce@...> wrote:
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 ofono mailing list.

$ cat ofono.inc
HOMEPAGE = "http://www.ofono.org"
SUMMARY  = "open source telephony"
DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
oFono supports speaking to telephony devices through specific drivers,
or with generic AT commands."
LICENSE  = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \

file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"

inherit autotools pkgconfig update-rc.d systemd bluetooth
gobject-introspection-data

DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info"

INITSCRIPT_NAME = "ofono"
INITSCRIPT_PARAMS = "defaults 22"

PACKAGECONFIG ??= "\
    ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
    "
PACKAGECONFIG[systemd] =
"--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"

EXTRA_OECONF += "--enable-test"

SYSTEMD_SERVICE_${PN} = "ofono.service"

do_install_append() {
  install -d ${D}${sysconfdir}/init.d/
  install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
}

PACKAGES =+ "${PN}-tests"

RDEPENDS_${PN} += "dbus"
RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"

FILES_${PN} += "${systemd_unitdir}"
FILES_${PN}-tests = "${libdir}/${BPN}/test"
RDEPENDS_${PN}-tests = "python3 python3-dbus"
RDEPENDS_${PN}-tests += "${@bb.utils.contains('GI_DATA_ENABLED',
'True', 'python3-pygobject', '', d)}"

Thank you.

- jupiter
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


--
Tim Froehlich
Embedded Linux Engineer
215-218-8955
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Dependencies with third party binaries

simon.zeni@...
 

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 have the RPMs extracted from the tarball and stored in a git repo. Not the ideal solution, but good enough for now.

The `bitbake` command for the recipe is passing after disabling a couple of QA errors (too much for my taste), but the recipe for the `core-image` fails at the dependency
resolution. From what I understand, all of the binaries inside of the `FILES_${PN}` are checked, and one (or more) fails at the dependency check with the following message :

```
Error:
Problem: conflicting requests
- nothing provides ld-linux-k1om.so.2()(64bit) needed by icc-2016+1-r0.corei7_64
```

This shared library seems to be Intel related but I cannot find it in all of the RPMs contained in the initial tarball. It is also not needed to run the compiler, I was able to execute the `icc` and `icpc` (the c++ compiler) binaries from the devshell.

I know this is wrong and against every yocto principles, but is there a way to skip the dependenciey resolution for a specific recipe ? Or is there a recipe made by Intel that I missed ?
I'm also open to any suggestions on how to tackle this task.

Here's my recipe so far :

```
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

DEPENDS += "libarchive-native"

SRC_URI = # omitted

PV = "2016-1"
SRCREV = "${AUTOREV}"

S = "${WORKDIR}/git"

extract_rpms() {
for rpm_file in ${S}/$1; do
bsdtar -xf ${rpm_file} -C $2
done
}

# Skip the unwanted steps
do_configure[noexec] = "1"
do_compile[noexec] = "1"

do_install () {
extract_rpms 'intel-icc*.rpm' ${D}
extract_rpms 'intel-comp*.rpm' ${D}
extract_rpms 'intel-ccomp*.rpm' ${D}
extract_rpms 'intel-openmp*.rpm' ${D}
}

do_package_qa[noexec] = "1"

ALLOW_EMPTY_${PN} = "1"

FILES_SOLIBSDEV = ""
FILES_${PN} += "/opt/intel/*"

INSANE_SKIP_${PN} += "already-stripped ldflags arch staticdev file-rdeps build-deps"

INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INHIBIT_PACKAGE_STRIP = "1"

```

Thanks,

Simon Zeni

[1]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-studio-xe&id=d4e2871a3bf698c3a5f58ee2201df53fe7f5dce7
[2]: http://registrationcenter-download.intel.com/akdlm/irc_nas/8365/parallel_studio_xe_2016_update1.tgz


Re: [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Scott Rifenbark <srifenbark@...>
 

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.  Nobody has said anything about that term for many releases. 

The problem Robert points out needs to be fixed in the BSP manual as "meta-intel" is not longer qualifying by my definition.  I can fix that. 

Is "Container Layer" ok as I have defined it?

Thanks,
Scott


On Thu, May 2, 2019 at 10:21 AM akuster <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-virtualization" was a container layer?

IMHO, a BSP should only deal with getting a MACHINE booted.

- armin
>
> Signed-off-by: Robert P. J. Day <rpjday@...>
>
> ---
>
> 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-guide/bsp.xml
> @@ -146,18 +146,15 @@
>
>      <para>
>          Some layers function as a layer to hold other BSP layers.
> -        These layers are knows as
> +        These layers are known as
>          "<ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>container layers</ulink>".
>          An example of this type of layer is the
> -        <filename>meta-intel</filename> layer.
> -        This layer contains BSP layers for the Intel-core2-32
> -        <trademark class='registered'>Intel</trademark> Common Core
> -        (Intel-core2-32) and the Intel-corei7-64
> -        <trademark class='registered'>Intel</trademark> Common Core
> -        (Intel-corei7-64).
> -        the <filename>meta-intel</filename> layer also contains
> -        the <filename>common/</filename> directory, which contains
> -        common content across those layers.
> +        <filename>meta-xilinx</filename> layer.
> +        This container layer contains some basic top-level information,
> +        as well as three actual Xilinx-related BSP layers,
> +        <filename>meta-xilinx-bsp</filename>,
> +        <filename>meta-xilinx-contrib</filename>, and
> +        <filename>meta-xilinx-standalone</filename>.
>      </para>
>
>      <para>
>

--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: mailman not found

Armin Kuster
 



On 5/2/19 5:43 AM, Searles, Dan wrote:

I got this response to my recent email:

 

Your message to mailman@... couldn't be delivered.


What mailing list did you send it to originally ?

- armin

mailman wasn't found at yoctoproject.org.

 




Re: System service

Tim Froehlich
 

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_pn-ofono" variable for that recipe. The systemd class sets it to "enable" by default, but something else could be overriding it and setting it to "disable".  Alternatively, confirm that the service isn't actually starting up and failing. It may be that you're restarting it once the system is fully booted and everything ofono needs is now ready.


On Thu, May 2, 2019 at 7:55 AM JH <jupiter.hce@...> wrote:
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 ofono mailing list.

$ cat ofono.inc
HOMEPAGE = "http://www.ofono.org"
SUMMARY  = "open source telephony"
DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
oFono supports speaking to telephony devices through specific drivers,
or with generic AT commands."
LICENSE  = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \

file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"

inherit autotools pkgconfig update-rc.d systemd bluetooth
gobject-introspection-data

DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info"

INITSCRIPT_NAME = "ofono"
INITSCRIPT_PARAMS = "defaults 22"

PACKAGECONFIG ??= "\
    ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
    "
PACKAGECONFIG[systemd] =
"--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"

EXTRA_OECONF += "--enable-test"

SYSTEMD_SERVICE_${PN} = "ofono.service"

do_install_append() {
  install -d ${D}${sysconfdir}/init.d/
  install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
}

PACKAGES =+ "${PN}-tests"

RDEPENDS_${PN} += "dbus"
RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"

FILES_${PN} += "${systemd_unitdir}"
FILES_${PN}-tests = "${libdir}/${BPN}/test"
RDEPENDS_${PN}-tests = "python3 python3-dbus"
RDEPENDS_${PN}-tests += "${@bb.utils.contains('GI_DATA_ENABLED',
'True', 'python3-pygobject', '', d)}"

Thank you.

- jupiter
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


--
Tim Froehlich
Embedded Linux Engineer
215-218-8955


Re: [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

Armin Kuster
 

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 <rpjday@crashcourse.ca>

---

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-guide/bsp.xml
@@ -146,18 +146,15 @@

<para>
Some layers function as a layer to hold other BSP layers.
- These layers are knows as
+ These layers are known as
"<ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>container layers</ulink>".
An example of this type of layer is the
- <filename>meta-intel</filename> layer.
- This layer contains BSP layers for the Intel-core2-32
- <trademark class='registered'>Intel</trademark> Common Core
- (Intel-core2-32) and the Intel-corei7-64
- <trademark class='registered'>Intel</trademark> Common Core
- (Intel-corei7-64).
- the <filename>meta-intel</filename> layer also contains
- the <filename>common/</filename> directory, which contains
- common content across those layers.
+ <filename>meta-xilinx</filename> layer.
+ This container layer contains some basic top-level information,
+ as well as three actual Xilinx-related BSP layers,
+ <filename>meta-xilinx-bsp</filename>,
+ <filename>meta-xilinx-contrib</filename>, and
+ <filename>meta-xilinx-standalone</filename>.
</para>

<para>


Re: ASSUME_PROVIDED, cmake-native and why cmake is subsequently not found?

Robert P. J. Day
 

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 be visible from the host system. Its a host
contamination protection mechanisn that has been there since pyro.
just to summarize, if one wanted to (perhaps injudiciously) take
advantage of host tools, that requires:

1) ASSUME_PROVIDED to specify the native package that no longer needs
to be built, and

2) HOSTTOOLS to identify the binary (or binaries) that can be picked
up from the host

i can see an obvious example here:

https://patchwork.openembedded.org/patch/140375/

but if this is the case, then it seems that the YP reference manual
should be clarified to explain the association between these
variables. for example, the current ref manual reads:

ASSUME_PROVIDED

Lists recipe names (PN values) BitBake does not attempt to build.
Instead, BitBake assumes these recipes have already been built.

In OpenEmbedded-Core, ASSUME_PROVIDED mostly specifies native
tools that should not be built. An example is git-native, which when
specified, allows for the Git binary from the host to be used rather
than building git-native.

reading that, a reader would not realize the necessity(?) of setting
HOSTTOOLS, yes?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


System service

JH
 

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 ofono mailing list.

$ cat ofono.inc
HOMEPAGE = "http://www.ofono.org"
SUMMARY = "open source telephony"
DESCRIPTION = "oFono is a stack for mobile telephony devices on Linux.
oFono supports speaking to telephony devices through specific drivers,
or with generic AT commands."
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \

file://src/ofono.h;beginline=1;endline=20;md5=3ce17d5978ef3445def265b98899c2ee"

inherit autotools pkgconfig update-rc.d systemd bluetooth
gobject-introspection-data

DEPENDS = "dbus glib-2.0 udev mobile-broadband-provider-info"

INITSCRIPT_NAME = "ofono"
INITSCRIPT_PARAMS = "defaults 22"

PACKAGECONFIG ??= "\
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
"
PACKAGECONFIG[systemd] =
"--with-systemdunitdir=${systemd_unitdir}/system/,--with-systemdunitdir="
PACKAGECONFIG[bluez] = "--enable-bluetooth, --disable-bluetooth, ${BLUEZ}"

EXTRA_OECONF += "--enable-test"

SYSTEMD_SERVICE_${PN} = "ofono.service"

do_install_append() {
install -d ${D}${sysconfdir}/init.d/
install -m 0755 ${WORKDIR}/ofono ${D}${sysconfdir}/init.d/ofono
}

PACKAGES =+ "${PN}-tests"

RDEPENDS_${PN} += "dbus"
RRECOMMENDS_${PN} += "kernel-module-tun mobile-broadband-provider-info"

FILES_${PN} += "${systemd_unitdir}"
FILES_${PN}-tests = "${libdir}/${BPN}/test"
RDEPENDS_${PN}-tests = "python3 python3-dbus"
RDEPENDS_${PN}-tests += "${@bb.utils.contains('GI_DATA_ENABLED',
'True', 'python3-pygobject', '', d)}"

Thank you.

- jupiter


Newcomer bugs

Richard Purdie
 

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 appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

The idea is these bugs should be straight forward for a person to help
work on who doesn't have deep experience with the project.

If anyone can help, please take ownership of the bug and send patches!

If anyone needs help/advice there are people on irc who can likely do
so, or some of the more experienced contributors will likely be happy
to help too.

Also, if there are people interested in helping mentor newcomers and
help develop newcomer suited bugs, please talk to me about it as we
could definitely do with help there.

Other roles where we could do with particular help are toaster
development, website improvements/maintenance, QA framework
documentation/development + testcases and our CI testing along with the
usual other things but these are not really suited to newcomers.

Cheers,

Richard

10461 - 10480 of 55440