Re: QA notification for completed autobuilder build (yocto-3.1.rc2)
Sangeeta Jain
Hi all,
toggle quoted messageShow quoted text
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-----
|
|||||||||||||||||||||
|
|||||||||||||||||||||
Re: Fw: Reducing rootfs size in yocto
On 2020-03-30 2:57 a.m., Mikko Rapeli wrote:
Hi,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 :) -- # Randy MacLeod # Wind River Linux
|
|||||||||||||||||||||
|
|||||||||||||||||||||
Re: imx-boot do_compile failing with custom distro
#yocto
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, -- ----- 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:
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:
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 theThere 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
|
|||||||||||||||||||||
|
|||||||||||||||||||||
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 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,
toggle quoted messageShow quoted text
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-----
|
|||||||||||||||||||||
|
|||||||||||||||||||||
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 theI 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.
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:
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 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:
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.
If you’re interested, this is quite easy to reproduce – these are my repro steps
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:
Planned upcoming dot releases:
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)
toggle quoted messageShow quoted text
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. --
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,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
On 2020-03-29 11:08 p.m., Raghu Icecraft Software Trainings wrote:
Hi,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:
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,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||
|