Date   

Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is now running QA execution for YP build yocto-3.1.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. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Monday, April 13.

Thanks,
Sangeeta

-----Original Message-----
From: Richard Purdie <richard.purdie@...>
Sent: Wednesday, 8 April, 2020 9:21 PM
To: pokybuild@...; yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

On Wed, 2020-04-08 at 04:01 +0000, pokybuild@...
wrote:
A build flagged for QA (yocto-3.1.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2


Build hash information:

bitbake: 4618da2094189e4d814b7d65672cb65c86c0626a
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: bd539ea962ee285eb71053583e3c17fa166fc610
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 1795f30d8ab73d35710ca99064c51190dc84853e
poky: 5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478

There were two failures in this build due to collect-results failing. I fixed the
missing dependency on that autobuilder worker (there was already an open bug
but it wasn't fixed yet) and reran the collections scripts so the results were
added and handled.

Cheers,

Richard


Re: Fw: Reducing rootfs size in yocto

Randy MacLeod
 

On 2020-03-30 2:57 a.m., Mikko Rapeli wrote:
Hi,
Generic approaches for reducing yocto target image size where buildhistory
is an important source of information:
* review and minimize distro features, enable only what you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-distro
* review and minimize image recipe, install only those image features and packages
which you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-image
* review the needed binary packages: traverse the tree of dependencies what you need,
review every single recipe and change PACKAGECONFIG or build flags to remove
features which you do not need. This it may be possible to remove large set
of dependencies from images, e.g. language bindings, debug tools. In some cases
one just needs a single binary executable or shared library but it is bundled
in a larger binary package with more complex dependencies. For these cases
add a bbappend to custom layers to change the packaging to only include what
you need.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PACKAGECONFIG
* change compiler flags from default O2 to Os optimization. This can work for
some recipes which are not prerformance critical or to the whole build. Note
that many SW components break this in their own build scripts by adding
O2 or even O3 by default. Check from buildhistory that binary sizes go smaller
after switch from O2 to Os and review every important recipe which did not.
You may be able to save up to 15% in rootfs size this way, but all depends
on the details of SW components and image contents.
see poky/meta/conf/bitbake.conf
I've followed this for multiple products and found out that poky is nice to work with
but BSP layers add or depend on all kinds of extra things that products do not need.
Thus I have ended by BBMASK'ing away large parts of BSP layer recipes in distro
configs. This with multiple x86 and ARM BSP layers from various SoC vendors.
I've also seen this problem and was frustrated by it.

The BSP vendors/developers want to test the full feature set of the
hardware but they often don't bother stripping out packages after
confirming that everything works. This results in bloat that can
be a problem for some users.

Using BBMASK is a good coping mechanism! :)

It would also be good if BSP developers split the BSP into the
essential elements and extras. Where to draw the line between
two such categories can tricky. One could also have finer-grained
packagegroups but splitting things into essential and extras is
a good start.

In WR Linux, we have a setup tool that let's you add 'features'
This comes from a layer that improves ease of use for some people:

https://github.com/WindRiver-Labs/wr-template/blob/WRLINUX_10_19_BASE/README

and is always used in the WR Linux distro.

And as can be seen here:
https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_19_BASE/wrlinux-distro/templates/feature/bsp-extras

There is a generic BSP independent feature that you can add to
a setup:

feature/bsp-extras

Adds some useful tools defined by the BSP_EXTRAS_PACKAGES option
in the BSP layer.

To see the list of available tools, run the bitbake -e command in
a sourced terminal, and look for the BSP_EXTRAS_PACKAGES.

Maybe this description will help get BSP developers to agree on
doing something similar regardless of the 'setup/wr-template' layer.

Good luck and keep your BSPs minimal!

../Randy

Also, RTFM :)
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-a-tiny-system
Hope this helps,
-Mikko

--
# Randy MacLeod
# Wind River Linux


Re: imx-boot do_compile failing with custom distro #yocto

Rudolf J Streif
 

Hi Stefan,

I agree that it is odd that a recipe copies a file, in this case the bl31 bootloader image, from the deploy area to the recipe area. This bootloader binary is created by the imx-atf recipe. imx-atf is listed as a dependency for imx-boot which is the recipe that is failing in your build. Therefore I would expect imx-atf to run before imx-boot. However, a recipe's do_compile task does not depend on another recipe's do_deploy task but on the other recipe's do_install task. What likely happened is that imx-boot do_compile was started after imx-atf do_install completed but before imx-atf do_deploy has completed. For imx-boot to work correctly it should copy the files from imx-atf's staging area rather than the deploy directory.

I suggest that you try to run imx-atf alone to see if it builds and if the bl31 image is built and placed into the deploy directory. And then run your build again.

:rjs

On 4/8/20 7:41 AM, stefan.wenninger@... wrote:
Hi,
I have encountered a curious problem when trying to create my own poky-based distribution.
My distribution poky-mydist.conf in conf/distro/ of my own layer:
require conf/distro/poky.conf
DISTRO = "poky-mydist"
DISTRO_NAME = "Poky my dist (Custom Project Distro)"
DISTROOVERRIDES = "poky:poky-mydist"
 
DISTRO_FEATURES += "ppp"
This distro is basically identical to the base poky from poky.conf. I just added a feature to be able to verify that my distro is being used.

When I build core-image-base however, I get the following error:
ERROR: imx-boot-0.2-r0 do_compile: Function failed: do_compile (log file is located at /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295)
ERROR: Logfile of failure stored in: /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295
Log data follows:
| DEBUG: Executing shell function do_compile
| Copying DTB
| 8MQ/8MM boot binary build
| Copy ddr_firmware: lpddr4_pmu_train_1d_imem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| Copy ddr_firmware: lpddr4_pmu_train_1d_dmem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| Copy ddr_firmware: lpddr4_pmu_train_2d_imem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| Copy ddr_firmware: lpddr4_pmu_train_2d_dmem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| cp: cannot stat '/opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart/imx-boot-tools/bl31-imx8mq.bin': No such file or directory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295)
ERROR: Task (/opt/yocto-dev/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/imx-mkimage/imx-boot_0.2.bb:do_compile) failed with exit code '1'
By just switching my DISTRO to 'poky' in local.conf, it builds without error.

There are several things that surprise me about this error:
1. I find it quite strange that these ddr_firmwares are copied from the deploy directory to the working directory of imx-boot. I would expect that to be the other way around.
2. The file bl31-imx8mq.bin is not in the imx-boot-tools folder, even after a successful build with DISTRO='poky'. (Maybe it was there during build and was just removed afterwards?)

From my point of view it looks like the set of files that get put into imx-boot-tools/ is dependant on the DISTRO value? When using DISTRO='poky' the correct set is placed and copied. When using DISTRO='poky-mydist' the files that are placed into the folder are not the files that are supposed to be copied from there, hence the error.

Am I interpreting this situation correctly?
Is there an error in my poky-mydist distribution?
Is that something that needs to be fixed in the recipe for imx-boot? Or can I somehow configure poky-mydist.conf to be treated exactly like poky.conf?

Thanks in advance
Stefan 


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


imx-boot do_compile failing with custom distro #yocto

stefan.wenninger@...
 

Hi,
I have encountered a curious problem when trying to create my own poky-based distribution.
My distribution poky-mydist.conf in conf/distro/ of my own layer:
require conf/distro/poky.conf
DISTRO = "poky-mydist"
DISTRO_NAME = "Poky my dist (Custom Project Distro)"
DISTROOVERRIDES = "poky:poky-mydist"
 
DISTRO_FEATURES += "ppp"
This distro is basically identical to the base poky from poky.conf. I just added a feature to be able to verify that my distro is being used.

When I build core-image-base however, I get the following error:
ERROR: imx-boot-0.2-r0 do_compile: Function failed: do_compile (log file is located at /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295)
ERROR: Logfile of failure stored in: /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295
Log data follows:
| DEBUG: Executing shell function do_compile
| Copying DTB
| 8MQ/8MM boot binary build
| Copy ddr_firmware: lpddr4_pmu_train_1d_imem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| Copy ddr_firmware: lpddr4_pmu_train_1d_dmem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| Copy ddr_firmware: lpddr4_pmu_train_2d_imem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| Copy ddr_firmware: lpddr4_pmu_train_2d_dmem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M
| cp: cannot stat '/opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart/imx-boot-tools/bl31-imx8mq.bin': No such file or directory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295)
ERROR: Task (/opt/yocto-dev/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/imx-mkimage/imx-boot_0.2.bb:do_compile) failed with exit code '1'
By just switching my DISTRO to 'poky' in local.conf, it builds without error.

There are several things that surprise me about this error:
1. I find it quite strange that these ddr_firmwares are copied from the deploy directory to the working directory of imx-boot. I would expect that to be the other way around.
2. The file bl31-imx8mq.bin is not in the imx-boot-tools folder, even after a successful build with DISTRO='poky'. (Maybe it was there during build and was just removed afterwards?)

From my point of view it looks like the set of files that get put into imx-boot-tools/ is dependant on the DISTRO value? When using DISTRO='poky' the correct set is placed and copied. When using DISTRO='poky-mydist' the files that are placed into the folder are not the files that are supposed to be copied from there, hence the error.

Am I interpreting this situation correctly?
Is there an error in my poky-mydist distribution?
Is that something that needs to be fixed in the recipe for imx-boot? Or can I somehow configure poky-mydist.conf to be treated exactly like poky.conf?

Thanks in advance
Stefan 


Re: QA notification for completed autobuilder build (yocto-3.1.rc2)

Richard Purdie
 

On Wed, 2020-04-08 at 04:01 +0000, pokybuild@...
wrote:
A build flagged for QA (yocto-3.1.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2


Build hash information:

bitbake: 4618da2094189e4d814b7d65672cb65c86c0626a
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: bd539ea962ee285eb71053583e3c17fa166fc610
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 1795f30d8ab73d35710ca99064c51190dc84853e
poky: 5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478

There were two failures in this build due to collect-results failing. I
fixed the missing dependency on that autobuilder worker (there was
already an open bug but it wasn't fixed yet) and reran the collections
scripts so the results were added and handled.

Cheers,

Richard


SDL2 without X11 #debian #yocto #apt

Adrian
 

Hi,
I try use SDL2 without X11 only with kmsdrm on stm32mp1 device. but I get error:  "KMSDRM not available".

I try the same on Rpi3 and its works.

I see that there is no kmsdrm in pkg-config and there is no anywhere libdrm.pc, is it required ?.

Should I build SDL on device ? if yes, how can I found link to source to use "apt-get build-dep libsdl2"

Regards,
Adrian


Re: QA notification for completed autobuilder build (yocto-3.1.rc1)

Richard Purdie
 

On Wed, 2020-04-08 at 01:14 +0000, Jain, Sangeeta wrote:
Hi Richard,

Thanks for update on
https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1
Unfortunately, I didn't received any mail for 3.1.rc1 or rc2 build
notification.
Looks like automated mail has some issues.

I will now start the QA on
https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2/

Thanks,
Sangeeta


-----Original Message-----
From: yocto@... <yocto@...>
On Behalf
Of Richard Purdie
Sent: Wednesday, 8 April, 2020 5:05 AM
To: Poky Build User <pokybuild@...>;
yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>;
Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>;
akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: Re: [yocto] QA notification for completed autobuilder
build (yocto-
3.1.rc1)
Thanks.

For reference you can see you're included in the Cc: list above so I'm
not sure why you aren't getting email. I'll ask Michael to look into
that.

Cheers,

Richard


Shorten booting time

JH
 

Hi,

I am running Yocto built Linux on an ARM device, it takes about more
than 1 minutes to boot from NAND and kernel, any good strategy to
reduce the ARM device booting time? I can think of cutting down
unnecessary configures in kernel.

Thank you.

Kind regards,

- jh


Re: QA notification for completed autobuilder build (yocto-3.1.rc1)

Sangeeta Jain
 

Hi Richard,

Thanks for update on https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1
Unfortunately, I didn't received any mail for 3.1.rc1 or rc2 build notification.
Looks like automated mail has some issues.

I will now start the QA on https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2/

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Richard Purdie
Sent: Wednesday, 8 April, 2020 5:05 AM
To: Poky Build User <pokybuild@...>;
yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>; akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-
3.1.rc1)

On Mon, 2020-04-06 at 22:53 +0000, Poky Build User wrote:
A build flagged for QA (yocto-3.1.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1
I haven't see any "started QA" email about this yet.

We have had some issues with rc1 reported by people so given that and the
above, I'm going to abort rc1 and build rc2.

Cheers,

Richard


Re: QA notification for completed autobuilder build (yocto-3.1.rc1)

Richard Purdie
 

On Mon, 2020-04-06 at 22:53 +0000, Poky Build User wrote:
A build flagged for QA (yocto-3.1.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1
I haven't see any "started QA" email about this yet.

We have had some issues with rc1 reported by people so given that and
the above, I'm going to abort rc1 and build rc2.

Cheers,

Richard


Re: sstate causing stripped kernel vs symbols mismatch

Sean McKay
 

The kernel doesn’t have reproducible builds by default because of a handful of variables (including timestamps). If you rebuild, you get a different binary every time.
Those can be changed and overridden so that you get consistent binary output (see here: https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html) but that hasn’t been done on the linux-yocto recipe yet.

I assume that it’s planned because there are efforts going in to making things 100% reproducible for poky, but I don’t know what the status of everything is (although I know that the kernel at least isn’t reproducible as of 22.0.2)

 

Since this can theoretically happen to any package that doesn’t have a reproducible build process, it seemed worth asking the question globally too.

 

-Sean

 

 

From: yocto@... <yocto@...> On Behalf Of Alexander Kanavin
Sent: Tuesday, April 7, 2020 12:11 PM
To: McKay, Sean <sean.mckay@...>
Cc: yocto@...
Subject: Re: [yocto] sstate causing stripped kernel vs symbols mismatch

 

On Tue, 7 Apr 2020 at 21:03, Sean McKay <sean.mckay@...> wrote:

  If you’re interested, this is quite easy to reproduce – these are my repro steps

  • Check out a clean copy of zeus (22.0.2)
  • Add kernel-image to core-image-minimal in whatever fashion you choose (I just dumped it in the RDEPENDS for packagegroup-core-boot for testing)
  • bitbake core-image-minimal
  • bitbake -c clean core-image-minimal linux-yocto (or just wipe your whole build dir, since everything should come from sstate now)
  • Delete the sstate object(s) for linux-yocto’s deploy task.
  • bitbake core-image-minimal
  • Compare the BuildID hashes for the kernel in the two locations using file (you’ll need to use the kernel’s extract-vmlinux script to get it out of the bzImage)
    • file tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/boot/vmlinux-5.2.28-yocto-standard
    • ./tmp/work-shared/qemux86-64/kernel-source/scripts/extract-vmlinux tmp/deploy/images/qemux86-64/bzImage > vmlinux-deploy && file vmlinux-deploy

The kernel is still re-built from the same source, so why is this causing issues?

 

Alex


Re: sstate causing stripped kernel vs symbols mismatch

Alexander Kanavin
 

On Tue, 7 Apr 2020 at 21:03, Sean McKay <sean.mckay@...> wrote:
  If you’re interested, this is quite easy to reproduce – these are my repro steps
  • Check out a clean copy of zeus (22.0.2)
  • Add kernel-image to core-image-minimal in whatever fashion you choose (I just dumped it in the RDEPENDS for packagegroup-core-boot for testing)
  • bitbake core-image-minimal
  • bitbake -c clean core-image-minimal linux-yocto (or just wipe your whole build dir, since everything should come from sstate now)
  • Delete the sstate object(s) for linux-yocto’s deploy task.
  • bitbake core-image-minimal
  • Compare the BuildID hashes for the kernel in the two locations using file (you’ll need to use the kernel’s extract-vmlinux script to get it out of the bzImage)
    • file tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/boot/vmlinux-5.2.28-yocto-standard
    • ./tmp/work-shared/qemux86-64/kernel-source/scripts/extract-vmlinux tmp/deploy/images/qemux86-64/bzImage > vmlinux-deploy && file vmlinux-deploy
The kernel is still re-built from the same source, so why is this causing issues?

Alex


sstate causing stripped kernel vs symbols mismatch

Sean McKay
 

Hi all,

 

We’ve discovered that (quite frequently) the kernel that we deploy doesn’t match the unstripped one that we’re saving for debug symbols. I’ve traced the issue to a combination of an sstate miss for the kernel do_deploy step combined with an sstate hit for do_package_write_rpm. (side note: we know we have issues with sstate reuse/stamps including things they shouldn’t which is why we hit this so much. We’re working on that too)

 

The result is that when our debug rootfs is created (where we added the kernel symbols), it’s got the version of the kernel from the sstate cached rpm files, but since do_deploy had an sstate miss, the entire kernel gets rebuilt to satisfy that dependency chain. Since the kernel doesn’t have reproducible builds working, the resulting pair of kernels don’t match each other for debug purposes.

 

So, I have two questions to start:

  1. What is the recommended way to be getting debug symbols for the kernel, since do_deploy doesn’t seem to have a debug counterpart (which is why we originally just set things up to add the rpm to the generated debug rootfs)
  2. Does this seem like a bug that should be fixed? If so, what would be the recommended solution (more thoughts below)?

 

Even if there’s a task somewhere that does what I’m looking for, this seems like a bit of a bug. I generally feel like we want to be able to trust sstate, so the fact that forking dependencies that each generate their own sstate objects can be out of sync is a bit scary.

I’ve thought of several ways around this, but I can’t say I like any of them.

  • (extremely gross hack) Create a new task to use instead of do_deploy that depends on do_packagegroup_write_rpm. Unpack the restored (or built) RPMs and use those blobs to deploy the kernel and symbols to the image directory.
  • (gross hack with painful effects on build time) Disable sstate for do_package_write_rpm and do_deploy. Possibly replace with sstate logic for the kernel’s do_install step (side question – why doesn’t do_install generate sstate? It seems like it should be able to, since the point is to drop everything into the image directory)
  • (possibly better, but sounds hard) Change the sstate logic so that if anything downstream of a do_compile task needs to be rerun, everything downstream of it needs to be rerun and sstate reuse for that recipe is not allowed (basically all or nothing sstate). Maybe with a flag that’s allowed in the bitbake file to indicate that a recipe does have reproducible builds and that different pieces are allowed to come from sstate in that case.
  • (fix the symptoms but not the problem) Figure out how to get linux-yocto building in a reproducible fashion and pretend the problem doesn’t exist.

 

 

If you’re interested, this is quite easy to reproduce – these are my repro steps

  • Check out a clean copy of zeus (22.0.2)
  • Add kernel-image to core-image-minimal in whatever fashion you choose (I just dumped it in the RDEPENDS for packagegroup-core-boot for testing)
  • bitbake core-image-minimal
  • bitbake -c clean core-image-minimal linux-yocto (or just wipe your whole build dir, since everything should come from sstate now)
  • Delete the sstate object(s) for linux-yocto’s deploy task.
  • bitbake core-image-minimal
  • Compare the BuildID hashes for the kernel in the two locations using file (you’ll need to use the kernel’s extract-vmlinux script to get it out of the bzImage)
    • file tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/boot/vmlinux-5.2.28-yocto-standard
    • ./tmp/work-shared/qemux86-64/kernel-source/scripts/extract-vmlinux tmp/deploy/images/qemux86-64/bzImage > vmlinux-deploy && file vmlinux-deploy

 

Anyone have thoughts or suggestions?

 

Cheers!

-Sean McKay


Yocto Project Status WW14'20

Stephen Jolley
 

Current Dev Position: YP 3.1 M4 - RC built and in QA

Next Deadline: YP 3.1 release date  4/24/2020

 

Next Team Meetings:

 

Key Status/Updates:

 

YP 3.1 Milestone Dates:

  • YP 3.1 M4 built and is in QA
  • YP 3.1 M4 release date  4/24/2020

 

Planned upcoming dot releases:

  • YP 3.0.3 build date  5/4/2020
  • YP 3.0.3 release date 5/15/2020
  • YP 2.7.4 build date  5/18/2020
  • YP 2.7.4 release date 5/29/2020

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: initramfs with mdev: No match for argument: busybox-mdev

Mike Looijmans
 

My guess is that your busybox isn't configured to produce mdev. Run "bitbake -c menuconfig busybox" and enable it (and save the config fragment for later)

On 02-04-2020 12:08, y1dekel via lists.yoctoproject.org wrote:
I am new to yocto. I have read some messages on this forum which suggest ways to build an image with initramfs and mdev.
So far I have implemented all advises but I am getting this message:
ERROR: image-argus-tiny-initramfs-1.0-r0 do_rootfs: Could not invoke
dnf. Command
'/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/recipe-sysroot-native/usr/bin/dnf
-v --rpmverbosity=info -y -c
/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/rootfs/etc/dnf/dnf.conf
--setopt=reposdir=/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/rootfs/etc/yum.repos.d
--installroot=/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/rootfs
--setopt=logdir=/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/temp
--repofrompath=oe-repo,/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/oe-rootfs-repo
--nogpgcheck install base-passwd busybox busybox-mdev dropbear
initramfs-live-boot-tiny packagegroup-core-boot run-postinsts'
returned 1:
DNF version: 4.1.0
cachedir:
/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from
/home/ubuntu/yocto_warrior/argus-build/tmp/work/raspberrypi3-poky-linux-gnueabi/image-argus-tiny-initramfs/1.0-r0/oe-rootfs-repo
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Thu 02 Apr 2020 09:20:31 AM UTC.
Last metadata expiration check: 0:00:01 ago on Thu 02 Apr 2020
09:20:36 AM UTC.
No module defaults found
No match for argument: busybox-mdev
I have added an mdev include fragment as follows:
CONFIG_MDEV=y
CONFIG_FEATURE_MDEV_LOAD_FIRMWARE=y
PACKAGES =+ "${PN}-mdev"
INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd
${PN}-mdev ${PN}-hwclock"
INITSCRIPT_NAME_${PN}-mdev = "mdev"
INITSCRIPT_PARAMS_${PN}-mdev = "start 04 S ."
CONFFILES_${PN}-mdev = "${sysconfdir}/mdev.conf"
I also implemented a receipt for our image as follows:
VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
PACKAGE_INSTALL = "initramfs-live-boot-tiny packagegroup-core-boot
dropbear ${VIRTUAL-RUNTIME_base-utils}
${VIRTUAL-RUNTIME_dev_manager} base-passwd ${ROOTFS_BOOTSTRAP_INSTALL}"
...
Any idea what I might be missing here?
--
Mike Looijmans


Re: Novice question on makefile in yocto environment

Mike Looijmans
 

On 30-03-2020 05:08, Raghu Icecraft Software Trainings via Lists.Yoctoproject.Org wrote:
Hi,
  I have some general idea on makefile in C, C++ environment.
Related to my Yocto project having a very tough time in getting my makefile ready on shape after almost every development change.
Is there any specific Troubleshooting based guidance available some where ?
I have also tried looking for old posts in this group.
Please suggest if I have to post this question, somewhere else.
For anything more advanced than one or two C files, avoid handcrafting makefiles and use autotools or cmake.

A helloworld makefile that takes "helloworld.c" or "helloworld.cpp" and creates an executable can be as simple as this:


helloworld: helloworld.o


And that's it. Notice the total absence of compiler and linker invocations, your environment already knows how to do that. Adding more to this makefile will usually only make it worse...


Re: Novice question on makefile in yocto environment

Randy MacLeod
 

On 2020-03-29 11:08 p.m., Raghu Icecraft Software Trainings wrote:
Hi,
  I have some general idea on makefile in C, C++ environment.
Related to my Yocto project having a very tough time in getting my makefile ready on shape after almost every development change.
Is there any specific Troubleshooting based guidance available some where ?
I have also tried looking for old posts in this group.
Please suggest if I have to post this question, somewhere else.
Did anyone reply off list?

Did you have a look at using the SDK and tips in:

https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-adding-makefile-only-software


Also, here's a simple recipe example from the Wind River docs:
https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_CD/page/mmo1403548803429.html
you should be able to make that work with just oe-core/poky.

If you're still having trouble, post a example Makefile
for 'hello-world' and perhaps someone will help you out.

../Randy


--
# Randy MacLeod
# Wind River Linux


Re: Removing URL escapes from a Bitbake variable

Patrick Doyle <wpdster@...>
 

On Mon, Apr 6, 2020 at 3:34 PM Patrick Doyle <wpdster@...> wrote:

I have a recipe that looks something like this (I'm simplifying a bit here):

SRC_URI += "${EXTERNAL_URL}"

do_compile() {
do -something -with $(basename ${EXTERNAL_URL} .ext)
}

where EXTERNAL_URL is supplied in the environment when invoking
Bitbake (and is whitelisted in the environment).

The problem is, if that URL has HTTP escapes in it, they get decoded
by the fetcher, and the file in ${WORKDIR} no longer looks like
$(basename ${EXTERNAL_URL}).
Never mind. I found it. I did something like:

EXTERNAL_FILE="${@bb.fetch.decodeurl(d.getVar('EXTERNAL_URL',True))[2]}"
do_compile() {
do -something-with $(basename ${EXTERNAL_URL})
}

I would still be happy to learn of a better way to have done this.

--wpd


Removing URL escapes from a Bitbake variable

Patrick Doyle <wpdster@...>
 

I have a recipe that looks something like this (I'm simplifying a bit here):

SRC_URI += "${EXTERNAL_URL}"

do_compile() {
do -something -with $(basename ${EXTERNAL_URL} .ext)
}

where EXTERNAL_URL is supplied in the environment when invoking
Bitbake (and is whitelisted in the environment).

The problem is, if that URL has HTTP escapes in it, they get decoded
by the fetcher, and the file in ${WORKDIR} no longer looks like
$(basename ${EXTERNAL_URL}).

Is there any way to invoke a URL decoder on a variable within bitbake?
Is there any way to determine what the filename was of a file that was
downloaded?
Is there any better way to do this?

Thanks for any tips you can provide.

--wpd


M+ & H bugs with Milestone Movements WW14

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW13 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13023

Switch to memory resident bitbake by default in 3.2

richard.purdie@...

richard.purdie@...

3.99

3.2

 

13463

test linux-yocto-rt kernels too

richard.purdie@...

richard.purdie@...

3.1

3.1 M4

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 

8281 - 8300 of 57363