On Thu, 2023-12-14 at 10:09 +0100, Alexander Kanavin wrote: > On Wed, 13 Dec 2023 at 09:57, Yoann Congal <[email protected]> wrote: > > > > The bluetooth support adds a bluez5 dependency (and,recursively, a lot > > of other stuff). Disable it by default to avoid having to build all of > > this when it is not needed. > > > > This decrease the number of tasks run for a core-image-minimal build by > > ~1000 (-21%). > > > > To re-enable bluetooth support in strace, add "bluez" to strace > > PACKAGECONFIG. For example, in local.conf: > > PACKAGECONFIG:append:pn-strace = " bluez" > > > > Fixes [YOCTO #15323] > > I'm afraid I have to raise objections. > > First, this needs an explanation: what functionality in strace does > this disable? Is that functionality important from the point of having > bluetooth in DISTRO_FEATURES? Not respecting DISTRO_FEATURES sets a > bad precedent, and should be more carefully justified and treated as > an exception.
This was raised as a question on the call on Tuesday. I appreciate you weren't there and the commit message above does give the reasoning but let me elaborate. The bluez support in strace is basically for protocol decoding. This is not something most users of strace use, I personally can never remember using it. Yes, if you need it, it is extremely useful. If you know how to debug bluetooth wireless, you can probably work out how to turn on the packageconfig. The downside to having this enabled by default is a significant dependency chain increase (21%). Sometimes we need to think about the big picture and whether one single packageconfig is really worth the increased build cycles it places upon everyone by default. > Second, why is strace even needed in the context of > core-image-minimal? It's not installed into the image, so I went and > checked: > util-linux-ptest needs mdadm > mdadm-ptest needs strace. > > Which begs the question. Should we continue to enable ptest by default > in poky? Should we create and use a ptest-less distro configuration? > It does pull in a ton of extra stuff all over the place which > lengthens the builds a lot. And the resulting ptest packages aren't > even used until one explicitly requests one of the ptest images. This was also asked. We did use to have it off by default but then nearly every package upgrade broke ptest since the upgraders didn't remember to turn it on for testing. I decided on for poky, off for oe- core was a better compromise. > As an example, I saw an oe-selftest-armhost yesterday, which ran > nearly 17 hours: > https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/2587 > > If you go and look at what tests in it took the longest time, you see: > 2023-12-13 15:45:22,812 - oe-selftest - INFO - RESULTS - > runtime_test.Postinst.test_postinst_rootfs_and_boot_systemd: PASSED > (32620.46s) > 2023-12-13 15:45:22,794 - oe-selftest - INFO - RESULTS - > prservice.BitbakePrTests.test_import_export_override_db: PASSED > (12789.45s) > 2023-12-13 15:45:22,789 - oe-selftest - INFO - RESULTS - > overlayfs.OverlayFSEtcRunTimeTests.test_all_required_variables_set: > PASSED (35205.79s) > 2023-12-13 15:45:22,781 - oe-selftest - INFO - RESULTS - > minidebuginfo.Minidebuginfo.test_minidebuginfo: PASSED (15395.76s) > 2023-12-13 15:45:22,782 - oe-selftest - INFO - RESULTS - > multiconfig.MultiConfig.test_multiconfig: PASSED (11098.06s) > 2023-12-13 15:45:22,776 - oe-selftest - INFO - RESULTS - > incompatible_lic.IncompatibleLicensePerImageTests.test_bash_and_license: > PASSED (24012.67s) > 2023-12-13 15:45:22,775 - oe-selftest - INFO - RESULTS - > imagefeatures.ImageFeatures.test_mandb: PASSED (19394.74s) > 2023-12-13 15:45:22,762 - oe-selftest - INFO - RESULTS - > devtool.DevtoolExtractTests.test_devtool_build_image: PASSED > (27341.75s) > 2023-12-13 15:45:22,760 - oe-selftest - INFO - RESULTS - > debuginfod.Debuginfod.test_debuginfod_qemu: PASSED (25784.11s) > 2023-12-13 15:45:22,759 - oe-selftest - INFO - RESULTS - > containerimage.ContainerImageTests.test_expected_files: PASSED > (19453.84s) > 2023-12-13 15:45:22,758 - oe-selftest - INFO - RESULTS - > buildoptions.SanityOptionsTest.test_options_warnqa_errorqa_switch: > PASSED (10492.68s) > 2023-12-13 15:45:22,758 - oe-selftest - INFO - RESULTS - > buildoptions.ToolchainOptions.test_toolchain_fortran: PASSED > (11367.46s) > 2023-12-13 15:45:22,743 - oe-selftest - INFO - RESULTS - > baremetal.BaremetalTest.test_baremetal: PASSED (24196.04s) > > The same a-full selftest, but on a x86 host has these times, quicker > than arm but still measured in hours: > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/6179/steps/15/logs/stdio > > What do most of these tests do? They do indeed build > core-image-minimal (sometimes full-cmdline or some other images), and > sometimes in multiple variants within a single test. But they never > use ptest. And so we need to find a way to make it happen faster. Once a given build has run through the system, things do run much faster but this is basically the performance issue I've been mentioning in the weekly status reports. Even the above packageconfig change in this patch would actually speed a lot of these up, but you're objecting to that. The tests themselves are actually quite valuable as we're way beyond the point I can work out which patch will break which features. Some of the tests could undoubtedly be improved. If we disable the ptests for the selftests, we run the risk of not reusing sstate so a better question might be, why are all the tests not reusing sstate more efficiently? > I'm going to get some numbers, first without any changes, then with > your proposed change, then with ptest dropped - this will take a bit > of time, so I wanted to get the concerns written and sent first. I don't think dropping the ptests is the right approach, we should likely focus on sstate reuse? I am also pretty in favour of this patch. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#192343): https://lists.openembedded.org/g/openembedded-core/message/192343 Mute This Topic: https://lists.openembedded.org/mt/103146402/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
