On Wed, 2023-08-23 at 14:47 +0300, Mikko Rapeli wrote: > On Wed, Aug 23, 2023 at 11:49:39AM +0100, Richard Purdie wrote: > > On Wed, 2023-08-23 at 12:47 +0300, Mikko Rapeli wrote: > > > On Wed, Aug 23, 2023 at 10:06:41AM +0100, Richard Purdie wrote: > > > > On Wed, 2023-08-23 at 10:31 +0300, Mikko Rapeli wrote: > > > > > Hi, > > > > > > > > > > On Tue, Aug 22, 2023 at 11:25:58PM -0700, Khem Raj wrote: > > > > > > will this work when running multiple instances of qemu ? > > > > > > e.g. try bitbake core-image-ptest-all > > > > > > > > > > I was not aware of core-image-ptest-all. Tried to build it but it > > > > > doesn't > > > > > seem to be compatible with IMAGE_FEATURES += "ssh-server-dropbear" > > > > > which is > > > > > needed to test core-image-minimal: > > > > > > > > > > Error: > > > > > Problem: package packagegroup-core-ssh-dropbear-1.0-r1.noarch from > > > > > oe-repo requires dropbear, but none of the providers can be installed > > > > > - package dropbear-2022.83-r0.core2_64 from oe-repo conflicts with > > > > > openssh provided by openssh-9.3p2-r0.core2_64 from oe-repo > > > > > - package openssh-9.3p2-r0.core2_64 from oe-repo conflicts with > > > > > dropbear provided by dropbear-2022.83-r0.core2_64 from oe-repo > > > > > - conflicting requests > > > > > (try to add '--allowerasing' to command line to replace conflicting > > > > > packages or '--skip-broken' to skip uninstallable packages) > > > > > > > > > > oeqa runtime testing core-image-minimal without ssh server doesn't > > > > > make sense as all tests will > > > > > just be skipped. > > > > > > > > The autobuilder actually does that, the minimal image is just tested > > > > with the small number of non-network tests. The main thing was to test > > > > it does actually boot to a login prompt. We have other tests which test > > > > the other areas with other images. > > > > > > Yes, granted it's enough to test that boot to serial console login works. > > > > > > > The reason for the above is that there will be ptest openssh images > > > > which conflict with the dropbear ones. You can likely avoid that by > > > > using: > > > > > > > > IMAGE_FEATURES:append:pn-core-image-minimal = " ssh-server-dropbear" > > > > > > > > The ptest images are designed to only include the ptest in question so > > > > in theory are otherwise as minimal as the dependencies allow. > > > > > > Alright, this I could try. But I fear there is a log more missing from my > > > plain poky and default machine target to get the selftests and tests > > > running. > > > > There is no secret magic config the autobuilder uses. You keep asking > > me for this and there isn't anything. It is actually starting to annoy > > me a bit as there isn't anything "hidden". > > If I can't run the tests for poky the way yocto upstream does, then I'm afraid > I can't really help with the issues you've seeing with the tests.
If that isn't possible we need to fix the docs. > > The configurations used are all from this file: > > > > https://git.yoctoproject.org/yocto-autobuilder-helper/tree/config.json > > Ok so https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1948 > for example uses yocto-autobuilder-helper at commit > af5d072a654a060c3ee61b5f394f52632e20200b. And the full repo > URL is visible not in the snippet there but in the full stdio download > of "Fetch yocto-autobuilder-helper" step. It was the web UI confusing me. > > I'm sorry if these are all obvious to you and other developers but not > to me. > > > Yes, there is a block of high level config around numbers of threads, > > disk space monitoring, pressure regulation values and so on but we > > purposefully keep the config to be as close to standard poky as we can. > > > > When we run selftest we do a couple of things. Firstly we split the > > machine and toolchain targets into separate areas. We also split > > reproducibility to it's own target and test mirroring elsewhere too. > > This results in a slightly more complex selftest invocation: > > > > OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 > > oe-selftest -a --skip-tests distrodata.Distrodata.test_checkpkg > > buildoptions.SourceMirroring.test_yocto_source_mirror reproducible -T > > machine -T toolchain-user -T toolchain-system -j 15 > > > > The only test which I don't think we run anywhere any more is the > > test_checkpkg target. > > > > You can see all this from the logs buildbot shows from it's UI on the > > autobuilder too. > > Thanks, this explains alot! > > I'm still wondering how the build hosts are setup with "modprobe vgem" and > that > build user account is in "render" group (on Ubuntu at least). Should these > be added to some documentation too? Yes, they should. > > > > This magic is somewhere in the autobuilder related git repositories, but > > > from plain > > > poky checkout with a specific commit from master branch I don't know > > > which versions > > > and repos to use so that the tests would be passing. > > > > > > With these modifications in local.conf: > > > > > > IMAGE_CLASSES += "testimage" > > > TEST_RUNQEMUPARAMS += "slirp" > > > > We do not use slirp on the autobuilder. We never have and we're > > unlikely ever to do so and it is not something we officially support > > for this. This is likely the biggest source of problems. > > Sadly I can't figure out how to setup runqemu and testimage.bbclass and > oe-selftests networking without slirp and for my testing needs it has been > good > enough, now also with oe-selftests. As root you need to run: runqemu-gen-tapdevs <uid> <gid> <number tap devs> where uid is your user ID and gid is the group you want to be able to access those devices. Once done once at boot, the builds will use those devices. The autobuilder has these pre-setup. You raise a good point that this should be documented, probably in the testing manual. As we're all aware, documentation is hard so we should either file a bug for that (and the vgem issue) or write a docs patch. https://docs.yoctoproject.org/test-manual/index.html > > I appreciate that gives some networking challenges for people in > > constrained environments but we did that primarily to allow for > > simplifications in the rest of the setup. > > > > > IMAGE_FEATURES += "ssh-server-dropbear" > > > > I've already explained that this one does likely cause problems. We > > simply don't run many tests against minimal images. > > > > > # update kernel to latest available in poky > > > PREFERRED_VERSION_linux-yocto = "" > > > > Not sure why this is needed? > > I'm trying to test the 6.4 kernel update and reproduce the issues you've seen > there too. Ok, I did change the default to 6.4 now. > > > SANITY_TESTED_DISTROS = "" > > > > This one we've discussed. It really should be fixed in a better way but > > isn't anywhere near the top of the priority list. > > I'll try to get to this. Thanks, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#186575): https://lists.openembedded.org/g/openembedded-core/message/186575 Mute This Topic: https://lists.openembedded.org/mt/100910036/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
