Re: [yocto] #apt #linux #yocto #raspberrypi., apt, gcc, sudo not present

Hi Siddhartha, Caveat: This is generally what I've done, and not specific to any rpi or rhel setup If you run `bitbake -e core-image-base | grep "^IMAGE_FEATURES" you'll be able to see what was configured. You can also filter *_FEATURES to get a better idea of what went on in terms of machi

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

On 5/27/20 6:42 PM, Michael Halstead wrote: > I've rebuilt the fancyindex module and enabled it. The full filenames > are displayed now. The module is disabled automatically when new > versions of EPEL are released. Hopefully the change in html output > doesn't break any script you've started wri

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

Hello All, Intel and WR YP QA is planning for QA execution for YP build yocto-2.7.4.rc2. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. N

Re: [yocto] overwrite LAYERSERIES_COMPAT_ for different layer

On Mon, May 25, 2020 at 03:28:52PM +0200, Quentin Schulz wrote: > On Mon, May 25, 2020 at 03:10:39PM +0200, Martin Jansa wrote: > > You can add a layer which will set LAYERSERIES_COMPAT for another layer, > > but it needs to be parsed before the layer you want to change, e.g.: > > https://github.co

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

I've rebuilt the fancyindex module and enabled it. The full filenames are displayed now. The module is disabled automatically when new versions of EPEL are released. Hopefully the change in html output doesn't break any script you've started writing. I found and closed a few old

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

On 5/27/20 4:48 PM, Richard Purdie wrote: > Hi Bill, > > On Wed, 2020-05-27 at 12:31 +, Mills, William wrote: >> In a script, how would I download all the files in this dir: >> >> https://autobuilder.yocto.io/pub/releases/yocto-2.7.4.rc2/machines/beaglebone-yocto/ >> >> I see no global md5su

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

Hi Bill, On Wed, 2020-05-27 at 12:31 +, Mills, William wrote: > In a script, how would I download all the files in this dir: > > https://autobuilder.yocto.io/pub/releases/yocto-2.7.4.rc2/machines/beaglebone-yocto/ > > I see no global md5sum (or sha256sum etc) file in the tree anywhere. > >

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

On 5/27/20 5:31 AM, Mills, William wrote: > In a script, how would I download all the files in this dir: > > https://autobuilder.yocto.io/pub/releases/yocto-2.7.4.rc2/machines/beaglebone-yocto/ > > I see no global md5sum (or sha256sum etc) file in the tree anywhere. > > The names are cut off in t

Re: [yocto] what to expect from distributed sstate cache?

We're sharing the sstate-cache on plain Ubuntu LTS machines, all installed from wherever, and no issues with low hitrates. Even if the build server was running something like ubuntu 14 and "my" machine running 16, the hit rate would still be pretty good, it would only rebuild the "native" stuf

Re: [yocto] [OE-core] OpenEmbedded Happy Hour

Just a reminder this happens later "today". As always consult: https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+27&iso=20200527T21&p1=%3A&ah=1 for the local day and time. Philip On 5/15/20 11:56 AM, Philip Balister wrote: > I've made a wiki page to track the

Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

In a script, how would I download all the files in this dir: https://autobuilder.yocto.io/pub/releases/yocto-2.7.4.rc2/machines/beaglebone-yocto/ I see no global md5sum (or sha256sum etc) file in the tree anywhere. The names are cut off in the default html list format so screen scrapping won't

[yocto] QA notification for completed autobuilder build (yocto-2.7.4.rc2)

A build flagged for QA (yocto-2.7.4.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-2.7.4.rc2 Build hash information: bitbake: 7f7126211170439ac1d7d72e980786ce0edb7bb7 meta-gplv2: d5d9fc9a4bbd365d6cd6fe4d6a8558f7115c17da meta-in

Re: [yocto] what to expect from distributed sstate cache?

Thanks will have a look at that script. Den ons 27 maj 2020 kl 13:41 skrev Martin Jansa : > > There is no limitation like that, but it's quite easy to break that, you > mentioned some ugly BSP before, I wouldn't be surprised if it's broken there. > > What worked well for me over the years is usin

Re: [yocto] what to expect from distributed sstate cache?

There is no limitation like that, but it's quite easy to break that, you mentioned some ugly BSP before, I wouldn't be surprised if it's broken there. What worked well for me over the years is using this script: openembedded-core/scripts/sstate-diff-machines.sh on jenkins which produces the sstate

Re: [yocto] #apt #linux #yocto #raspberrypi., apt, gcc, sudo not present

On Wed, May 27, 2020 at 8:06 PM Siddhartha V wrote: > Hello, > > I built the image for Raspberrypi3B+ board. But when boot the board gcc, > apt, sudo were not there. Actually only the poweron and poweroff and few > basic commnds like, ls, mkdir, whoami were working. May I konw what wrong I > di

[yocto] #apt #linux #yocto #raspberrypi., apt, gcc, sudo not present

Hello, I built the image for Raspberrypi3B+ board. But when boot the board gcc, apt, sudo were not there. Actually only the poweron and poweroff and few basic commnds like, ls, mkdir, whoami were working. May I konw what wrong I did while building please. I am using yocto warrior. I used *" bi

Re: [yocto] what to expect from distributed sstate cache?

Hi, Thanks for the input. Regarding docker we are building the docker image and we are using the same image for all nodes so should they not be identical when the nodes start the containers? Thanks, Den ons 27 maj 2020 kl 11:16 skrev : > > Hi, > > On Wed, May 27, 2020 at 10:58:55AM +0200, Mans Z

Re: [yocto] what to expect from distributed sstate cache?

Hi, On Wed, May 27, 2020 at 10:58:55AM +0200, Mans Zigher wrote: > This is maybe more related to bitbake but I start by posting it here. > I am for the first time trying to make use of a distributed sstate > cache but I am getting some unexpected results and wanted to hear if > my expectations are

Re: [yocto] what to expect from distributed sstate cache?

The recommended set up is to use r/w NFS between build machines, so they all contribute to the cache directly. And yes, if the inputs to the task are identical, then there should a cache hit. If you are getting cache misses where you are expecting a cache hit, then bitbake-diffsigs/bitbake-dumpsig

[yocto] what to expect from distributed sstate cache?

Hi, This is maybe more related to bitbake but I start by posting it here. I am for the first time trying to make use of a distributed sstate cache but I am getting some unexpected results and wanted to hear if my expectations are wrong. Everything works as expected when a build node is using a sst

[yocto] about when poky check sstate_cache #yocto

I read the codes about sstate_cache. Let me briefly talk about how it work . I am not sure if it is right. Example,we have setscene tasks A_setsscene, B_setcene. and Task C ,D are not setscene task. After we bitbake something, runqueue started,and it check A , B to see if the sstate_caache exists