Le 14/12/2023 à 20:36, Khem Raj a écrit :
> On Thu, Dec 14, 2023 at 11:33 AM Alexandre Belloni
> <[email protected]> wrote:
>>
>> On 14/12/2023 10:53:05-0800, Khem Raj wrote:
>>> On Thu, Dec 14, 2023 at 1:10 AM Alexander Kanavin
>>> <[email protected]> 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.
>>>>
>>>> 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.
>>>
>>> I looked briefly into util-linux pertaining to mdadm needs in tests, there
>>> are 4 tests needing it.
>>> md-raid0-whole, md-raid1-part, md-raid1-whole, align-512-4K-md
>>>
>>> and all of them are marked as
>>> TS_KNOWN_FAIL="yes"
>>>
>>> See 
>>> https://github.com/util-linux/util-linux/commit/7519c3edab120b14623931d5ddb16fdc6e7cad5d
>>>
>>> I think we can skip running these tests as well and safely avoid
>>> depending upon mdadm for util-linux ptests which can break the depchain as 
>>> well.
>>>
>>
>> I think dropping the mdam ptests was the plan seeing the amount of
>> breakage this does on the AB.
> 
> Good deal, I also see them happening on musl so I went ahead and cooked a 
> patch
> and posted it on ml. Musl util-linux ptests have 4 less fails now.

FYI, since Khem's patch ([OE-core] [PATCH] util-linux: Delete md-raid tests) 
also prevent bluez to be built in a default core-image-minimal build, we can 
skip this one (strace: Disable bluetooth support by default) and still fix 
[YOCTO #15323].

>>
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> Alex
>>>>
>>>> 
>>>>
>>
>> --
>> Alexandre Belloni, co-owner and COO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com

-- 
Yoann Congal
Smile ECS - Tech Expert
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#192425): 
https://lists.openembedded.org/g/openembedded-core/message/192425
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to