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

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 -- ----- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3396 x700

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

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

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

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

I confirm - this line is not required (at least at Yocto 2.6). Best regards, Lukasz Zemla

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

as a followup, i would think that "meta-openembedded" is the canonical example of a container layer, no? rday -- ======================================================================== Robert

much snipping ... 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

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

Great, thanks!

On 5/2/19 10:45 AM, Scott Rifenbark wrote: in those terms above, yes its fine. thanks for clarifying. Armin

> 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

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

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 5:43 AM, Searles, Dan wrote: What mailing list did you send it to originally ? - armin

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

I thought "meta-virtualization" was a container layer? IMHO, a BSP should only deal with getting a MACHINE booted. - armin

... snip ... ... snip ... 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