Bug 13786 - gstreamer build not determinstic (setcap)
Summary: gstreamer build not determinstic (setcap)
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: multimedia (show other bugs)
Version: 3.0
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 3.1 M3
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2020-02-06 23:20 UTC by Richard Purdie
Modified: 2020-02-19 21:30 UTC (History)
5 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Purdie 2020-02-06 23:20:51 UTC 
The gstreamer build (gstreamer1.0_1.16.1.bb) is showing determinism issues depending on whether setcap is installed on the buildhost or not. The autotools fix would be:

# setcap may not exist on the host
CACHED_CONFIGUREVARS = "ac_cv_path_SETCAP=${sbindir}"

Unfortunately I don't know the meson equivalent.

The diffoscope difference shows a dependency on libcap in some builds and not in others.
Comment 1 Carlos Rafael Giani 2020-02-07 06:12:55 UTC 
The relevant location in the meson based builds is here: https://gitlab.freedesktop.org/gstreamer/gstreamer/blob/master/libs/gst/helpers/meson.build#L67

This meson.build file also contains PTP related checks that may similarly cause nondeterministic builds, though I am not sure this really is the case. Worth checking too.
Comment 2 Alexander Kanavin 2020-02-19 15:38:32 UTC 
I think simply adding a dependency on whatever native recipe provides setcap, and then making sure target libcap is there as well should be enough?
Comment 3 Alexander Kanavin 2020-02-19 15:38:58 UTC 
Reading that meson code, it does look for setcap in PATH first before falling back to hardcoded host paths.