[OE-core] [PATCH] systemtap: 3.3 -> 4.0

Victor Kamensky kamensky at cisco.com
Wed Oct 17 05:56:13 UTC 2018



On Tue, 16 Oct 2018, Richard Purdie wrote:

> On Tue, 2018-10-16 at 10:27 +0100, Burton, Ross wrote:
>> On Mon, 15 Oct 2018 at 19:22, Victor Kamensky <kamensky at cisco.com>
>> wrote:
>>> Upgrade systemtap from 3.3 to 4.0: Removed backported patch.
>>
>> WARNING: systemtap-4.0-r0 do_package_qa: QA Issue: systemtap:
>> /systemtap/etc/stap-exporter/EXAMPLE is owned by uid 1000, which is
>> the same as the user running bitbake. This may be due to host
>> contamination
>> systemtap: /systemtap/etc/stap-exporter/EXAMPLE_NOERROR is owned by
>> uid 1000, which is the same as the user running bitbake. This may be
>> due to host contamination
>> systemtap: /systemtap/etc/stap-exporter/errno.stp is owned by uid
>> 1000, which is the same as the user running bitbake. This may be due
>> to host contamination
>> systemtap: /systemtap/etc/stap-exporter/syscalllatency.stp is owned
>> by
>> uid 1000, which is the same as the user running bitbake. This may be
>> due to host contamination
>> systemtap: /systemtap/etc/stap-exporter/timeout.stp is owned by uid
>> 1000, which is the same as the user running bitbake. This may be due
>> to host contamination
>> systemtap: /systemtap/etc/stap-exporter/topsys.stp is owned by uid
>> 1000, which is the same as the user running bitbake. This may be due
>> to host contamination [host-user-contaminated]
>
> There are also other issues from the addition of systemd unit files in
> 4.0. I've a patch in -next which tweaks both issues which I'll put in
> for testing.

Richard, thank you very prompt help.

In the long term it would be beneficial that those issues be
fixed in SystemTap itself, correct? If so, I can look at creating
proper patches and pushing them into SystemTap.

Also on my todo list is to attempt to push few existing
OE systemtap patches into SystemTap upstream source. I believe
they look like quite legit issues and I hope they could be
upstreamed.

Thanks,
Victor

> Cheers,
>
> Richard
>
>



More information about the Openembedded-core mailing list