Add BitBake (Yocto) as supported package manager #722
Assignees
Labels
Comments
tsteenbe
added
enhancement
tsteenbe
changed the title
|
I recommend using the latest version of the bitbake manual: https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html. 1.6 is pretty old at this point. |
haikoschol
pushed a commit
that referenced
this issue
Aug 17, 2018
This is done in preparation of implementing BitBake support (#722), which requires a mechanism to pass a list of recipes to analyze. Since this list is specific to the repository being analyzed, it makes sense to add this information to .ort.yml and give package manager instances access to it, analogous to the command line parameters via AnalyzerConfiguration.
haikoschol
pushed a commit
that referenced
this issue
Aug 20, 2018
This is done in preparation of implementing BitBake support (#722), which requires a mechanism to pass a list of recipes to analyze. Since this list is specific to the repository being analyzed, it makes sense to add this information to .ort.yml and give package manager instances access to it, analogous to the command line parameters via AnalyzerConfiguration.
|
Maybe also have a look at https://github.com/Waldleufer/archproj-bmwteam of which our contributor @andreas-bauer has a fork. |
|
FYI, there's been work started in the bitbake branch. |
|
The questions below outline the prerequisites of things we need to figure out prior to be able to add Yocto support to ORT
|
|
I think it's still an open question if it's really appropriate the use ORT on Yocto in the first place. In our case, we provide meta-updater and some additional supporting layers as open-source projects to help our users integrate aktualizr into their projects. However, meta-updater (and essentially all of Yocto) is just metadata. We don't normally deploy or deliver the software built with Yocto, just the metadata that explains how to build it. The metadata itself that we use is released under friendly open-source terms. The software built with the metadata is more complex, and Yocto has some internal tooling for detecting it. I wrote a script that can collect the licenses for a given package and its dependencies and another script that uses the first to specifically find the dependencies of aktualizr. However, I'm not sure anymore if that is actually useful. So before those six questions can be answered, we need to clarify: are we trying to search for licenses of the metadata that is Yocto or the underlying software that is built with Yocto? |
The latter, IMO. Or more generically: We need to determine the licenses of what is being distributed in the end. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
We're currently trying to approach this with file level, rather than package level license granularity, so it might not be completely relevant for ORT, but here's where we're at: Yocto has some built in tooling to scan the built image for source files used to build it. We're using this to get the hash values to find licenses of individual files, but it the tooling might be useful for separating the code in the build from build/test ones for you aswell. We've described the process in a little more detail here (heavily WIP). |
This comment was marked as off-topic.
This comment was marked as off-topic.
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 13, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 13, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 13, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 13, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 13, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 13, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 15, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
May 16, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
|
For reference, I just learned that besides Double Open's original https://github.com/doubleopen-project/meta-doubleopen, there's also https://github.com/fossas/meta-fossa that might be worth looking at. |
|
Also https://github.com/fosslight/fosslight_yocto_scanner may be worth looking into.. |
sschuberth
added a commit
to doubleopen-project/ort
that referenced
this issue
Sep 25, 2024
Add the beginnings of an analyzer for BitBake [1], see [2] for context. It basically works by making the build inherit from the "create-spdx" class [3] to create SPDX 2.2 files and post-processing them via ORT's SPDX document file analyzer. This initial implementations has several known limitations still. First of all, as the "create-spdx" class cannot be used without building, and builds are not cached, so the analyzer is very slow. Secondly, SPDX external documents refs cannot be resolved yet. This requires some post-processing of the SPDX document files before passing them on, notably by adjusting the `SPDX_NAMESPACE_PREFIX` variable [4]. [1]: https://docs.yoctoproject.org/bitbake/ [2]: oss-review-toolkit#722 [3]: https://docs.yoctoproject.org/dev/dev-manual/sbom.html [4]: https://docs.yoctoproject.org/ref-manual/variables.html#term-SPDX_NAMESPACE_PREFIX Signed-off-by: Sebastian Schuberth <sebastian@doubleopen.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add support for the BitBake (Yocto) dependency manager to the analyzer module.
Links:
BitBake manual: https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html
Useful Bitbake commands: https://community.nxp.com/docs/DOC-94953
Bitbake repos: https://git.yoctoproject.org/
Projects starting with poky-* and meta-* likely contain bitbake files
The text was updated successfully, but these errors were encountered: