Re: [yocto] CVE Scanners and Package Version
Hi Marta > > The discussion in this thread is in fact related to what we have in > sessions > about SRTools. Would you be willing to join? > I remember that the meetings were announced via the mailing lists. But I can no longer find them and they are not listed on https://www.yoctoproject.org/community/get-involved/#virtual-meetings. How can I participate? Thank you. Best regards, Adrian > Kind regards, > Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62133): https://lists.yoctoproject.org/g/yocto/message/62133 Mute This Topic: https://lists.yoctoproject.org/mt/103332846/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
On Tue, 2024-01-02 at 09:24 +0200, Mikko Rapeli wrote: > Hi, > > On Sat, Dec 23, 2023 at 02:47:36AM -0800, fabian.hanke via > lists.yoctoproject.org wrote: > > Hello Yocto community, > > > > we must provide a SBOM for our Yocto based product which will then > > be used for (internal) CVE scanning by the security department. > > Generating the base document in cycloneDX format is fairly easy > > (thanks to the nature of Yocto). Our experts have also opted for CycloneDX. Is your CycloneDX generator publicly available? > > Note that SBOM is mostly used for documenting SW components and their > licenses. > Obvious but needs to be made clear. I don't think that's true. A SBOM should probably also list the CVE patches and provide information about fixed CVEs. I'm not sure about SPDX, but CycloneDX also addresses this use case: https://cyclonedx.org/capabilities/vex/. > > > But we do not know how to include information about CVE patches for > > each package in the document. Not providing these, will cause a lot > > of “false” feedback on CVEs for specific versions which are already > > patched (but version number did not change). Yes, that's a real issue. > > This problem was also mentioned a few days ago in the presentation > > from David Reyna: https://youtu.be/PegU1G1bA80?t=1127. I like the > > proposed solution of adding a vendor specific string to the package > > version. But I'm still wondering: How would the CVE scanner vendor > > know which CVEs are included in a yocto specific version and which > > are not? If the SBOM contains the information from CVE_STATUS_* variables and the CVE scanner has access to the NIST database it should theoretically work. > > If the intention is to know CVE paching and analysis status of a > product, then I'd use > the yocto upstream tooling for this, cve-check.bbclass. SBOM and SPDX > are tempting but not actually > useful for CVE patching and analysis work, except when they show that > a lot of old open source > SW components are embedded into various binaries. This works well from a developer's point of view, but not from an end customer's or penetration tester's point of view. Many companies sell products with a pre-installed Yocto-based firmware, but do not provide the layers and bitbake with the firmware. > > The work needed to push CVE data into SPDX and SBOM is not worth it > and it's better to put > the saved effort into fixing the actual CVEs. Fixing the CVEs is one thing. But depending on the use case, it is also important to be able to document this. > If management wants reports, generate > them from cve-check.bbclass output, but note that CVE database is a > moving target too. Adding information about open CVEs to the SBOM would be a moving target and therefore a bad idea. But that was probably not the intention here. Much more reasonable is to provide a static SBOM which provides information about: - Installed packages and versions - CVE related patches for the packages - Additional information from CVE_STATUS_* variables (These use cases were also the motivation for adding this additional information) Such a SBOM would enable a user or a pen-tester to use a tool which generates a CVE report from the SBOM and the current data from e.g. the NIST database. This tool can run at any time and could be a generic SBOM tool which is independent from Yocto. The NIST DB is dynamic, but publicly available. The SBOM is static and provided with each firmware release. > > AFAIK, and I'd be happy to be proven wrong, SPDX and SBOM don't help > matching SW component names > and version strings so that comparison against CVE database > information works. Only license names > are standardized. I'm not sure what the current status is. But even if it's not completely solved today, that doesn't mean it can't or shouldn't be solved. The specifications are also open source. Adrian > > Cheers, > > -Mikko > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62071): https://lists.yoctoproject.org/g/yocto/message/62071 Mute This Topic: https://lists.yoctoproject.org/mt/103332846/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] do_populate_sdk_ext failed
It depends on your use case, but might be that https://docs.yoctoproject.org/sdk-manual/extensible.html#setting-up-the-extensible-sdk-environment-directly-in-a-yocto-build could work for you. With recent Yocto versions populate_sdk_ext is no longer needed to get the eSDK environment. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61890): https://lists.yoctoproject.org/g/yocto/message/61890 Mute This Topic: https://lists.yoctoproject.org/mt/103167520/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto][meta-yocto][poky][eSDK] builtin eSDK recipes generate wrong environment file
> I found the following RFC and I apply that and seems to be fine > https://lore.kernel.org/all/20220622103312.1098389-3-a...@linutronix.de/T/#m7eadf6c722410f5b233ebba9fc700a895af9f052 > How can we proceed? We also picked just these patches back to kirkstone. This works without negative impact. So I think it is possible to cherry-pick the patches from master or to revert the doc changes as proposed by Alex: https://lists.yoctoproject.org/g/docs/message/4642 Adrian -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61730): https://lists.yoctoproject.org/g/yocto/message/61730 Mute This Topic: https://lists.yoctoproject.org/mt/102730009/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Sat, 2023-11-04 at 11:09 +, Richard Purdie wrote: > On Sat, 2023-11-04 at 11:29 +0100, adrian.freiho...@gmail.com wrote: > > Hi Alex, hi Richard > > > > After some internal discussions, I would like to clarify my > > previous > > answers on this topic. > > > > * Usually there are two different workflows > > - application developers: could use an SDK with a locked > > sstate-cache. > > - Yocto/BSP developers: need an unlocked SDK. They change the > > recipes. > > * A locked SDK > > - can work with setscene from SSTATE_MIRRORS > > - setscene does caching in the SSTATE_DIR (no issue about that) > > - But network problems can occur during the initial build > > because > > bitbake executes many independent setscene tasks. Opening so > > many > > independent connections slows down the build, especially if > > the > > server treats them as a denial of service attack. > > - The denial of service problem is difficult to solve because > > each > > setscene task runs in its own bibtake task. Reusing a > > connection to > > download multiple sstate artifacts seems almost impossible. > > This is much easier to solve with separate sstate download > > script. > > FWIW, we did have a similar issue with do_fetch overloading > servers/proxies/ISPs and added: > > do_fetch[number_threads] = "4" > > Finding the right place to put a thread limit on overall setscene > tasks > is harder but in theory possible. Or perhaps a "network capable > tasks" > thread limit? > > Is the overload caused by the initial query of sstate presence, or, > does it happen when the setscene tasks themselves run? The most extreme situation is probably bitbake --setscene-only with an empty TMPDIR. Each of the setscene tasks establishes a new connection. A server receives so many connections that it treats them as a denial of service attack by throttling. A separate script would allow the same connection to be reused to download all the required artifacts. Limiting the number of threads does not really solve the issue because there are still the same amount of connections which get quickly opened. > > > > * An unlocked SDK > > - Tries to download the sstate cache for changed recipes and > > their > > dependencies, which obviously can't work. > > - The useless download requests slow down the build > > considerably and > > cause a high load on the servers without any benefit. > > Is this sstate over http(s) or something else? I seem to remember you > mentioning sftp. If this were using sftp, it would be horribly slow > as > it was designed for a light overhead "does this exist?" check which > http(s) can manage well. Yes, we are evaluating sftp. You are right, it is not optimal from a performance point of view. For example S3 is much faster. A compromise is to set up a limited number of parallel sftp connections. This has worked very well so far. The question of why we use sftp brings us to a larger topic that is probably relevant for almost all Yocto users, but not for the Yocto project itself: Security. There is usually a git server infrastructure that makes it possible to protect Git repositories with finely graded access policies. As the sstate-cache contains the same source code, the protection concept for the Git repositories must also be applied to the sstate-cache artifacts. First of all a user authentication is required for the sstate-mirror. An obvious idea is to use the same user authentication for the sstate- cache server as for the Git server. In addition to https, ssh is also often used for git repositories. SSH even offers some advantages in terms of user-friendliness and security (if a ssh agent is used). This consideration finally leads us to use the sftp protocol for the sstate mirror. This is also relatively easy to administer: Simply copy the user's public ssh keys from the git server to the sftp server. If one then wants to scale an sstate-cache server for many different projects and users, one quickly wishes for an option for authorization at artifact level. Ideally, the access rights to the source code would be completely transferred to the associated sstate artifacts. For such an authorization the ssate mirror server would require the SRC_URI which was used to compile the sstate artifact. With this information, it could ask the Git server whether or not a user has access to all source code repositories to grant or deny access to a particular sstate artifact. It should not be forgotten that the access rights to the Git repositories can change. > > Recently we've been wondering about teaching the hashequiv server > about > "presence", which would then mean the build would only query things > that stood a good chance of existing. > Yes, that sound very interesting. There are probably even more such kind of meta data which could be provided by the hashserver to improve the management of a shared sstate mirror. Would it make
Re: [yocto] [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
Hi Alex, hi Richard
After some internal discussions, I would like to clarify my previous
answers on this topic.
* Usually there are two different workflows
- application developers: could use an SDK with a locked sstate-cache.
- Yocto/BSP developers: need an unlocked SDK. They change the recipes.
* A locked SDK
- can work with setscene from SSTATE_MIRRORS
- setscene does caching in the SSTATE_DIR (no issue about that)
- But network problems can occur during the initial build because
bitbake executes many independent setscene tasks. Opening so many
independent connections slows down the build, especially if the
server treats them as a denial of service attack.
- The denial of service problem is difficult to solve because each
setscene task runs in its own bibtake task. Reusing a connection to
download multiple sstate artifacts seems almost impossible.
This is much easier to solve with separate sstate download script.
* An unlocked SDK
- Tries to download the sstate cache for changed recipes and their
dependencies, which obviously can't work.
- The useless download requests slow down the build considerably and
cause a high load on the servers without any benefit.
- A script which gets a list of sstate artifacts from bitbake and then
does a upfront download works much better
+ The script runs only when the user calls it or the SDK gets boot-
strapped
+ The script uses a reasonable amount of parallel connections which
are re-used for more then one artifact download
* Idea for a smart lock/unlock implementation
- Form a user's perspective a locked vs. an unlocked SDK does not make
much sense. It makes more sense if the SDK would automatically
download the sstate-cache if it is expected to be available.
Lets think about an implementation (which allows to override the
logic) to switch from automatic to manual mode:
SSTATE_MIRRORS_ENABLED ?= "${is_sstate_mirror_available()}"
In our case the sstate mirror is expected to provide all artifacts
for tagged commits and for some git branches of the layer
repositories.
The sstate is obviousely not usable for a "dirty" git layer
repository. That's what the is_sstate_mirror_available function
could check to automatically enable and disable lazy downloads.
- If is_sstate_mirror_available() returns false, it should still be
possible to initiate a sstate-cache download manually.
* Terminology
- Older Yocto Releases:
+ eSDK means an installer which provides a different environment with
different tools
+ The eSDK was static, with a locked sstate cache
+ Was for one MACHINE, for one image...
- Newer Yocto Releases:
+ The bitbake environment offers all features of the eSDK installer. I
consider this as already implemented with meta-ide-support and
build-sysroots.
+ The term eSDK means a replicable bitbake environment. (The
documentation was recently changed in that sense)
+ The new SDK installer can be generated in different variants similar
to what was already supported by the eSDK
installer: https://docs.yoctoproject.org/sdk-manual/appendix-
customizing.html#customizing-the-extensible-sdk-standalone-
installer.
* The lightest variant is just a script that sets up the layers (git
clone or git checkout) and provides the build config. If
SSTATE_MIRRORS are configured lazy downloads will just work
otherwise bitbake will compile everything from scratch.
* The heaviest variant of the SDK installer includes the layers and
the sstate-cache. After installing it is_sstate_mirror_available()
evaluates to True.
* devtool ide
- Tries to bring this ideas further towards IDE configuration
- It supports two modes: No recipe mode is like the old eSDK
environment. The recipe mode goes beyond that. It is based on
devtool modify.
- Naming: I was thinking about "devtool ide" versus "devtool esdk"
+ Why ide? I want to set up my IDE to work with the Yocto SDK. And
that means, of course, that I have to bootstrap the SDK.
+ Could also be esdk: I want to bootstrap the eSDK and that should
also configure my IDE.
* Latest patch series is here:
- https://lists.openembedded.org/g/openembedded-core/message/189899
- docs: https://lists.yoctoproject.org/g/docs/message/4578
Adrian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61610): https://lists.yoctoproject.org/g/yocto/message/61610
Mute This Topic: https://lists.yoctoproject.org/mt/102320109/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
Re: [yocto] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Wed, 2023-11-01 at 18:28 +0100, Alexander Kanavin wrote:
> On Wed, 1 Nov 2023 at 16:45, wrote:
> > I think these differences between SDK and bitbake environment are
> > no
> > longer required and they have been problematic. I would try to make
> > the
> > bitbake environment usable like the eSDK environment was without
> > trying
> > to replicate all the details of the eSDK installer such as these
> > local.conf settings.
>
> I have now split up the populate_sdk_ext into separate functions [1]
> for better maintainability, and the more I think about what to do
> next, the more I agree with Adrian. I just don't see why (in a
> standard yocto build) would we want to manipulate PATH to provide a
> restricted set of tools, or to create a "local.conf+extra stuff"
> (locked signatures, esdk tweaks) environment, when existing
> local.conf
> by itself is already working fine, and full set of tools is better
> than a restricted one. If we want to add or remove locked signatures,
> this can be done with 'bitbake -s lockedsigs' or bblock for specific
> recipes only. And SDK's cross-toolchain is accessible via
> meta-ide-support/build-sysroots flow.
>
> [1]
> https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/sstate-for-all
Splitting allows to copy the new function with the + from the patch
into this email and comment it.
+python copy_buildsystem () {
+ import oe.copy_buildsystem
+
+ baseoutpath = d.getVar('SDK_OUTPUT') + '/' + d.getVar('SDKPATH')
+
+ # Determine if we're building a derivative extensible SDK (from
devtool build-sdk)
+ derivative = (d.getVar('SDK_DERIVATIVE') or '') == '1'
What's the advantage of that? There are now two worlds: The bitbake
world and the SDK world which behave similar but not equal. Both need
to be maintained and tested.
We use only bitbake on our CI/CD infrastructure. For users who have
only the eSDK installed, it's hard to understand what the CI does and
even harder to reproduce errors happening on the CI.
We also had some setups with a containerized eSDK on the CI for the
integration of application source code. But this did not work at all.
The SDK container is basically outdated when the first component of the
firmware gets updated. If other components depend on that component an
SDK container update is required. Handling breaking changes easily is a
big advantage of bitbake which gets lost when using any kind of locked
or badly packaged variant of it.
+
+ conf_initpath, conf_bbpath, core_meta_subdir, sdkbblayers =
copy_bitbake_and_layers(d, baseoutpath, derivative)
Changing the directory layout leads to many pitfalls especially if more
layers than just poky are used. This should be replaced by the new
bitbake-layers tools. This means there is only one official way for
setting up bitbake layers and the folder structure gets exactly
replicated.
+
+ write_devtool_config(d, baseoutpath, conf_bbpath, conf_initpath,
core_meta_subdir)
Not sure there is much left when we have only the bitbake world. But
defining some defaults might be still useful.
+
+ write_unlocked_sigs(d, baseoutpath)
Lets turn this more towards a QA check. As a SDK maintainer I would
like to provide SDKs with 100% sstate included. But as a user, if I
have a choice between waiting a few minutes until bitbake compiled some
missing parts or getting an error message telling me I can't get an SDK
now, I'd probably choose compile.
If I remember correctly, with the old eSDK installer this is even
worse. This error happens during the installation which leads to an SDK
in an undefined state. The user must delete it again and fix the
generation of the SDK installer, which might be a very complicated and
time consuming task with the existing tools.
+
+ write_bblayers_conf(d, baseoutpath, sdkbblayers)
Also something which can be replaced by the new bitbake-layers utility.
+
+ uninative_checksum = copy_uninative(d, baseoutpath)
Not sure if this is still needed. With a bitbake environment this just
happens from sstate, I guess. So why doing it differently for the SDK?
+
+ write_local_conf(d, baseoutpath, derivative, core_meta_subdir,
uninative_checksum)
Also something which can be replaced by the new bitbake-layers utility.
+
+ prepare_locked_cache(d, baseoutpath, conf_initpath)
The sstate could be shipped in three different ways:
* Included in the installer and just extracted into $SSTATE_DIR. This
is simple but it does not scale at all. If you maintain multiple
distros and MACHINES and want to have fast update cycles,
distributing complete sstate archives quickly becomes practically
impossible, as the same data is packed into several huge archives.
That leads to issues on the infrastructure side. But also on the
user's machine having one sstate folder e.g. ~/sstate-cache instead
of several $TMPDIR/sstate-cache folders is beneficial.
* No sstate is included, the sstate gets "lazy" fetched from
SSTATE_MIRROR. Also that looks easy but does not scale very well for
the
Re: [yocto] [Openembedded-architecture] [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Wed, 2023-11-01 at 16:19 +0100, Alexander Kanavin via lists.openembedded.org wrote: > On Wed, 1 Nov 2023 at 15:18, wrote: > > We are currently experimenting with replacing the eSDK installer > > with > > the bitbake build environment for our users. Part of this > > transformation is, of course, the shared sstate-cache, for which > > this > > discussion seems quite relevant. The workflow we are aiming for is > > as > > follows: > > > > 1. Setup the layers and build config (out of scope here) > > 2. Download the sstate for a particular recipe (usually an image > > recipe). > > I'm not sure I understand the case for downloading the complete set > of > cache objects up front. What's wrong with 'lazy' downloading, e.g. > only when the objects are actually needed in a build? > > Even then, does --setscene-only do just that, or am I completely > confused? If I remember correctly, when configuring a SSTATE_MIRROR, the server is queried when a Setcene task is executed. This is not ideal for several reasons: * Bitbake Setcene tasks run in the context of a recipe, which means that thousands of connections are opened against the mirror server. Many servers treat this behavior as a denial of service attack. With a separate download tool, this can be handled with a reasonable number of parallel connections. With bitbake's architecture, this is a barely solvable issue. * Especially with an SDK, setcene tasks can run much more frequently than do_fetch tasks. So the same artifact is downloaded multiple times, which is not efficient. * SDK users may be located in different places in the world. This results in poor performance depending on the location. * With a separate download, you can download on a fast network and then switch to a slower network or even work offline. * Of course, supporting downloading in advance does not mean that a SSTATE_MIRROR should not be supported. Adrian > > Alex > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61561): https://lists.yoctoproject.org/g/yocto/message/61561 Mute This Topic: https://lists.yoctoproject.org/mt/102324539/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
Hi Richard, hi Alex On Mon, 2023-10-30 at 14:07 +, Richard Purdie wrote: > On Mon, 2023-10-30 at 14:50 +0100, Alexander Kanavin wrote: > > On Thu, 14 Sept 2023 at 14:56, Richard Purdie > > wrote: > > > There are design elements to this work. We need to work out how > > > we can > > > make eSDK and "normal" builds more similar and less of an > > > overhead to > > > switch between one and the other. A "bblock all" command does > > > partly > > > get you to an eSDK effectively so part of this may be switching > > > eSDK to > > > use the new lock command. What other differences are there? What > > > other > > > differences are necessary or make sense for the use cases eSDK > > > was > > > designed for? How would you turn an existing build into an eSDK > > > like > > > one? Could you provide a copy of a local build to someone else > > > easily > > > using something like eSDK's tooling? What does the eSDK look like > > > at > > > the end of this. One section we don't have good answers to yet is > > > setup > > > and configuration although I know you've started on some of that. > > > > So I see the following differences between esdk and normal modes: > > > > 1. Environment and tooling availability. > > > > a) esdk sets a number of variables from its initialization script > > that > > aid with cross-compiling components directly (e.g. the core use > > case > > of SDKs). Normal mode doesn't do that, but recently added > > meta-ide-support will generate a similar initialization script that > > will set up the same environment from the normal mode. There are > > tests > > and documentation for it. > > In that case, this one is something we can document as how to make > the > functionality available in the normal build. > > > b) PATH. eSDK has a number of items in PATH that point to various > > locations inside tmp/sysroots/, collectively they provide the > > cross-toolchain. > > > > eSDK also puts a selection of yocto tools into path - wic, devtool > > but > > not bitbake: > > > > > > alex@Zen2:~/poky_sdk$ ls -l sysroots/x86_64-pokysdk-linux/usr/bin/ > > total 48 > > lrwxrwxrwx 1 alex alex 39 Oct 30 12:52 devtool -> > > ../../../../layers/poky/scripts/devtool > > lrwxrwxrwx 1 alex alex 54 Oct 30 12:52 oe-find-native-sysroot -> > > ../../../../layers/poky/scripts/oe-find-native-sysroot > > lrwxrwxrwx 1 alex alex 42 Oct 30 12:52 recipetool -> > > ../../../../layers/poky/scripts/recipetool > > lrwxrwxrwx 1 alex alex 39 Oct 30 12:52 runqemu -> > > ../../../../layers/poky/scripts/runqemu > > lrwxrwxrwx 1 alex alex 55 Oct 30 12:52 runqemu-addptable2image -> > > ../../../../layers/poky/scripts/runqemu-addptable2image > > lrwxrwxrwx 1 alex alex 53 Oct 30 12:52 runqemu-export-rootfs -> > > ../../../../layers/poky/scripts/runqemu-export-rootfs > > lrwxrwxrwx 1 alex alex 51 Oct 30 12:52 runqemu-extract-sdk -> > > ../../../../layers/poky/scripts/runqemu-extract-sdk > > lrwxrwxrwx 1 alex alex 51 Oct 30 12:52 runqemu-gen-tapdevs -> > > ../../../../layers/poky/scripts/runqemu-gen-tapdevs > > lrwxrwxrwx 1 alex alex 46 Oct 30 12:52 runqemu-ifdown -> > > ../../../../layers/poky/scripts/runqemu-ifdown > > lrwxrwxrwx 1 alex alex 44 Oct 30 12:52 runqemu-ifup -> > > ../../../../layers/poky/scripts/runqemu-ifup > > lrwxrwxrwx 1 alex alex 100 Oct 30 12:52 unfsd -> > > ../../../../tmp/work/qemuarm64-poky-linux/core-image- > > minimal/1.0/recipe-sysroot-native/usr/bin/unfsd > > lrwxrwxrwx 1 alex alex 35 Oct 30 12:52 wic -> > > ../../../../layers/poky/scripts/wic > > == > > > > 'normal mode' puts bitbake/bin/ and oe-core/scripts in PATH. > > Cross-toolchain can be added by the same environment script made by > > meta-ide-support as mentioned in 1a. > > Right, so in theory we can change PATH and change this which can also > easily be documented. > > > 2. Configuration (e.g. local.conf). I think these differences between SDK and bitbake environment are no longer required and they have been problematic. I would try to make the bitbake environment usable like the eSDK environment was without trying to replicate all the details of the eSDK installer such as these local.conf settings. > > > > eSDK local.conf is local.conf from the normal mode that was used to > > produce eSDK, stripped of all comments, and with a bunch of extra > > settings: > > > > > > INHERIT:remove = "buildhistory icecc" That's not needed it there is a full bitbake environment. > > CONNECTIVITY_CHECK_URIS = "" > > > > SIGGEN_LOCKEDSIGS_SSTATE_EXISTS_CHECK = "none" > > > > SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn" As already mentioned in my previous mail, a locked SDK is not a must if the full bitbake environment with shared sstate-cache is available. Locking might be added later as an optional feature. > > > > BB_HASHCONFIG_IGNORE_VARS:append = " SIGGEN_UNLOCKED_RECIPES" > > > > BB_SETSCENE_ENFORCE_IGNORE_TASKS = "%:* *:do_shared_workdir > > *:do_rm_work
Re: [yocto] [OE-core] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
Hi Alex, hi Richard The discussion looks really interesting. I would like to contribute some comments from the point of view of a rather naive user and try to understand the workflows for which these improvements would be beneficial also on a bigger picture. On Thu, 2023-09-14 at 20:51 +0200, Alexander Kanavin wrote: > On Thu, 14 Sept 2023 at 14:56, Richard Purdie > wrote: > > For the task signatures, we need to think about some questions. If > > I > > make a change locally, can I query how much will rebuild and how > > much > > will be reused? There is bitbake --dry-run but perhaps it is time > > for a > > an option (or dedicated separate command?) to give some statistics > > about what bitbake would do? How much sstate would be reused? > > > > That then logically leads into the questions, can we tell what has > > changed? Why isn't my sstate being reused? For that we perhaps > > should > > define some existing scenarios where it is currently very difficult > > to > > work this out and then work out how we can report that information > > to > > the user. These could become test cases? > > So I think there are two questions here that the tools should answer: > > 1. If I would run a build, what would be missing in the cache and > need > to be built? The missing cache objects are in a dependency hierarchy, > so only those missing objects with no dependecies on other missing > objects would be printed. That should be comparatively easy to add as > bitbake already does those checks all the time. Is there something > else that's easily done and useful to print? > > 2. Then there's the question of *why* they are missing, which is > harder to answer. If, say, curl:do_package is not in the cache, then > the tool would have to walk the cache tree (I/O heavy operation as > there is no index), make a list of all curl:do_package objects that > are there, and do a recursive bitbake-diffsig (going up the task > tree) > on them vs the one we want. Then print them starting with the newest. > Something like: > We are currently experimenting with replacing the eSDK installer with the bitbake build environment for our users. Part of this transformation is, of course, the shared sstate-cache, for which this discussion seems quite relevant. The workflow we are aiming for is as follows: 1. Setup the layers and build config (out of scope here) 2. Download the sstate for a particular recipe (usually an image recipe). Note: Working with SSTATE_MIRRORS does not work very well because bitbake connects way too often to the sstate server. So we started to develop a script which downloads the sstate artifacts into SSTATE_DIR to get the SDK set up. Your point 1. is basically what our (a bit hacky) download script does in the --dry-run mode: Printing all the required sstate artifacts. I think as a first step, it would be very valuable to have a function or a tinfoil API in the core that returns a list of sstate artifacts for a given recipe. As a second step a tool or a new feature of an existing tool could download the artifacts into SSTATE_DIR. This would also be a great successor for the not so much maintained devtool sdk- update command. 3. At this point, the user is basically in the same situation as after installing the eSDK installer. devtool and now also bitbake are available, the sstate-cache is fully populated. Maintaining such an SDK and sstate mirror infrastructure brings us to your point 2. Tooling for maintaining the sstate cache becomes even more important than it is now. Also, locking the sstate cache and treating missing artifacts as errors seems to be an important feature. But I would consider the locking/unlocking more relevant for testing rather than for deploying locked SDKs. Unlocked SDKs allow the user to switch the branches of the layers to commits where the sstate is not available. If the user is in a full featured bitbake environment rather than the constrained eSDK installer environment this is perfectly fine. Bitbake can just compile the missing recipes. Such an SDK would combine all the advantages of the current eSDK installer and the much more flexible Bitbake environment. This would imply that the sstate download script should just try to download what's available on the mirror and maybe print a warning for artifacts which cannot be downloaded. But it should not abort with an error for missing artifacts. Does that make sense? Regrads, Adrian > Existing cache objects are not suitable because: > was built on and has a mismatching SRCREV > was built on and has a different > do_compile() > > > One of the big problems in the past was that we lost much of the > > hash > > information after parsing completed. This meant that if the hashes > > then > > didn't match, we couldn't tell why as the original computation was > > lost. I did some work on allowing us to retain
Re: [yocto] Trouble making a recipe for the IOBB library
The best would probably be to improve the Makefile to install the files to
standard paths such as /usr instead of /usr/local. /usr/local is usually
used for not packaged files and therefore not handled by the default FILES
package splitting rules of Yocto.
Ideally there would be a PREFIX variable in the Makefile which defaults to
/usr/local and gets over written by bitbake to /usr. Then also the FILES
line should no longer be needed.
Another approach would be to replace the Makefile by e.g. meson or cmake
which both do all these details right by default.
As a workaround extending the FILES line would work as well. But using
locations like lib or usr in FILES is not a good idea. It probably adds too
many files like debug stuff to the package.
To see the variables for you recipe you might want to use bitbake -e. To
see how bitbake spits the packages you might look into the
packages-splitted folder in the $WORKDIR of your recipe.
Regards
Adrian
Iurascu Teodor schrieb am Sa., 21. Okt. 2023,
09:05:
> Hello!
> I am new to the Yocto Project and I have been trying to make a recipe to
> include the IOBB library in my SDK for the BeagleBone Black board. I have
> used devtool to create a recipe based on a fork of the library.
>
>
> Library makefile:
>
>
> LIB_PATH = ./BBBio_lib/
> DEMO_PATH = ./Demo/
> TOOLKIT_PATH = ./Toolkit/
> LAB_PATH = ./Lab/
>
>
> LIBRARIES = iobb
>
> all
> : libiobb.a LED ADT7301 SEVEN_SCAN SMOTOR LED_GPIO DEBOUNCING 4x4keypad
> ADC ADC_VOICE GPIO_STATUS EP_STATUS ADC_CALC lcd3-test test-outputs
> pb-test-outputs test-inputs pb-test-inputs
>
> libiobb.a : ${LIB_PATH}BBBiolib.c ${LIB_PATH}BBBiolib.h BBBiolib_PWMSS.o
> BBBiolib_McSPI.o BBBiolib_ADCTSC.o i2cfunc.o
> gcc -c ${LIB_PATH}BBBiolib.c -o ${LIB_PATH}BBBiolib.o
>
> ar -rs ${LIB_PATH}libiobb.a ${LIB_PATH}BBBiolib.o
> ${LIB_PATH}BBBiolib_PWMSS.o ${LIB_PATH}BBBiolib_McSPI.o
> ${LIB_PATH}BBBiolib_ADCTSC.o ${LIB_PATH}i2cfunc.o
> cp ${LIB_PATH}libiobb.a ./
> cp ${LIB_PATH}BBBiolib.h ./iobb.h
> cp ${LIB_PATH}BBBiolib_ADCTSC.h ./
> cp ${LIB_PATH}BBBiolib_McSPI.h ./
> cp ${LIB_PATH}BBBiolib_PWMSS.h ./
> cp ${LIB_PATH}i2cfunc.h ./
>
> BBBiolib_PWMSS.o : ${LIB_PATH}BBBiolib_PWMSS.c ${LIB_PATH}BBBiolib_PWMSS.h
> gcc -c ${LIB_PATH}BBBiolib_PWMSS.c -o ${LIB_PATH}BBBiolib_PWMSS.o -W
>
> BBBiolib_McSPI.o : ${LIB_PATH}BBBiolib_McSPI.c ${LIB_PATH}BBBiolib_PWMSS.h
> gcc -c ${LIB_PATH}BBBiolib_McSPI.c -o ${LIB_PATH}BBBiolib_McSPI.o -W
>
> BBBiolib_ADCTSC.o : ${LIB_PATH}BBBiolib_ADCTSC.c ${LIB_PATH}BBBiolib_ADCTSC.h
> gcc -c ${LIB_PATH}BBBiolib_ADCTSC.c -o ${LIB_PATH}BBBiolib_ADCTSC.o -W
>
> i2cfunc.o : ${LIB_PATH}i2cfunc.c ${LIB_PATH}i2cfunc.h
> gcc -c ${LIB_PATH}i2cfunc.c -o ${LIB_PATH}i2cfunc.o
>
> install :
> ifndef locatie
> $(info locatie is [${locatie}])
> rm -f /usr/local/include/BBBiolib.h
> cp ${LIB_PATH}libiobb.a /usr/local/lib
> cp ${LIB_PATH}BBBiolib.h /usr/local/include/iobb.h
> cp ${LIB_PATH}BBBiolib_ADCTSC.h /usr/local/include
> cp ${LIB_PATH}BBBiolib_McSPI.h /usr/local/include
> cp ${LIB_PATH}BBBiolib_PWMSS.h /usr/local/include
> cp ${LIB_PATH}i2cfunc.h /usr/local/include
> ln -s /usr/local/include/iobb.h /usr/local/include/BBBiolib.h
> else
> $(info locatie is [${locatie}])
> rm -f $(locatie)/usr/local/include/BBBiolib.h
> mkdir -p $(locatie)/usr/local/lib
> mkdir -p $(locatie)/usr/local/include
> cp ${LIB_PATH}libiobb.a $(locatie)/usr/local/lib
> cp ${LIB_PATH}BBBiolib.h $(locatie)/usr/local/include/iobb.h
> cp ${LIB_PATH}BBBiolib_ADCTSC.h $(locatie)/usr/local/include
> cp ${LIB_PATH}BBBiolib_McSPI.h $(locatie)/usr/local/include
> cp ${LIB_PATH}BBBiolib_PWMSS.h $(locatie)/usr/local/include
> cp ${LIB_PATH}i2cfunc.h $(locatie)/usr/local/include
> cp $(locatie)/usr/local/include/iobb.h
> $(locatie)/usr/local/include/BBBiolib.h
> endif
>
>
> recipe file:
>
> LICENSE = "Unknown"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=7db6c9cd5c53a0a05ffa2f383b2408dc"
>
> SRC_URI = "git://github.com/TeoThatsMe/iobb;protocol=https;branch=master"
>
> # Modify these as desired
> PV = "1.0+git${SRCPV}"
> SRCREV = "1a7bdf1767f730b0d6058117e42c4ec77047b4ab"
>
> S = "${WORKDIR}/git"
> FILES:${PN} += "${base_libdir}"
>
> # NOTE: the following library dependencies are unknown, ignoring: iobb fftw3
> # (this is based on recipes that have previously been built and
> packaged)
>
> # NOTE: this is a Makefile-only piece of software, so we cannot generate much
> of the
> # recipe automatically - you will need to examine the Makefile yourself and
> ensure
> # that the appropriate arguments are passed in.
>
> do_configure () {
> # Specify any needed configure commands here
> :
> }
>
> do_compile () {
> # You will almost certainly need to add additional arguments here
> oe_runmake
> }
>
> do_install () {
> # This is a guess; additional arguments may be required
> oe_runmake install locatie=${D}
>
Re: [yocto] Http access token fetching with gitsm fetcher
Did you already consider to write the credentials in a .netrc file?
Regards
Adrian
schrieb am Fr., 20. Okt. 2023, 13:55:
> Greetings!
> I try to use gitsm fetcher to fetch bitbucket repository with read-only
> https access token. SRC_URI looks like this
>
> SRC_URI =
> "gitsm://**.git;protocol=https;branch=${BRANCH};user=azoykin:${TOKEN}"
>
> This recipe fetches parent repository, but is unable to fetch submodule,
> writing *fatal: could not read Username for 'https://tps-git.topcon.com
> ': No such device or address *in log.do_fetch
> It happens because url is passed to fetcher function already with user
> string. I suggest a patch to fix this issue
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61433): https://lists.yoctoproject.org/g/yocto/message/61433
Mute This Topic: https://lists.yoctoproject.org/mt/102079282/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Run generated executable in cmake recipe #cmake #kirkstone #make #native #yocto
Hi Darek Making the recipe compiling for cross and native and adding a DEPENDS from cross to native seems to be the cleanest and most Yocto-ish way to me. Alternatively this patch would allow to run cross compiled executables with Qemu in the cmake project https://git.yoctoproject.org/poky-contrib/commit/?h=adrianf/devtool-ide=6c63df973d9530ecabc9480f8ba2aba3ff93952f. But that's not the most common approach. It's also possible to hack a cmake script which allows to pass a native tool-chain file for B. But this approach needs some hacks because cmake is designed to work with one tool-chain file only. I did that for a special use case, but I'm not aware of a public example. Regards, Adrian Darek Konopka schrieb am Do., 19. Okt. 2023, 17:21: > Hello all, > > So I have a cmake project that uses an executable generated from a cmake > subproject. > My architecture is as such > ├── ProjectA > ├── projecta_1.0.bb > ├── files >├── ProjectA > ├── CMakeLists.txt > ├── ProjectB > ├── CMakeLists.txt > My recipe is a standard recipe that inherits pkgconfig cmake > The issue that occurs is that when manually building ProjectA natively it > builds as expected, but when building it with yocto, during the do_compile > for ProjectA, it says it is missing the executable generated by ProjectB > located in /usr/bin/ProjBEXE (this executable is needed in order to compile > ProjectA). > > What did work is creating a projectb-native recipe that runs cmake-native, > and then have projecta depend on it, but I was wondering, is there a way to > have projecta_1.0.bb build the executable and use it within its own > cmake? Perhaps making projectB a package to have projectA use it? > NOTE: I am using yocto kirkstone > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61421): https://lists.yoctoproject.org/g/yocto/message/61421 Mute This Topic: https://lists.yoctoproject.org/mt/102062177/21656 Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #cmake:https://lists.yoctoproject.org/g/yocto/mutehashtag/cmake Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone Mute #make:https://lists.yoctoproject.org/g/yocto/mutehashtag/make Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] continuous security updates for the Linux system
Hi Would it be possible to extend the https://wiki.yoctoproject.org/wiki/System_Update table with compatible backends? Ideally the license of the backends should also be transparent. OE/Yocto should not end up with a vendor lock in when it comes to a standard update mechanism. In the end it's about a solution with client and server, where a client alone is usually pretty worthless. Regards, Adrian On Mon, 2023-10-09 at 06:22 -0700, MOHAMMED HASSAN wrote: > On Mon, Oct 9, 2023 at 06:12 AM, Josef Holzmayr wrote: > > Please see https://wiki.yoctoproject.org/wiki/System_Update > > > Thanks for your reply. I am aware of the system_updates feature > though still yet to implement. Is it possible to update the yocto > version (i use dunfell) to the latest one, to update the linux > version(mine is 5.4.180) to the latest and to update the tools to the > latest using these features. Actually i have no clarity with this so > I am asking. > > Thanks and regards, > Hassan > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61287): https://lists.yoctoproject.org/g/yocto/message/61287 Mute This Topic: https://lists.yoctoproject.org/mt/101851310/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Qemu not working for raspberry pi
On Sat, 2023-08-19 at 19:21 +0200, Alexander Kanavin wrote: > It’s well possible that emulating the arm hardware is not needed, in > this case x86_64 is vastly better, as it will run at native speeds > with kvm. When qemu translates arm to x86, the performance drops 10x > or more. > > The issue preventing qemu from running is something else in any case, > I’d suggest making a plain poky build in a new build directory from > scratch actually. This approach has two advantage (as Alex already pointed out): - The firmware runs with native speed of the host machine if started with kvm. - It's trivial to setup. It just works. But it also also comes with a major disadvantage: It requires to build everything twice: Once for the target architecture and once for the host architecture. The compromise which just works but does not require an extra build for Qemu is what we have with the beaglebone-yocto machine in poky: https://git.yoctoproject.org/poky/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf. This allows to build for the target hardware but also running the same firmware image with runqemu. The trick is to add the QB_ configuration lines to the machine conf file and adding some drivers for the Qemu emulated hardware to the target kernel. I guess the Raspberry layer could be improved to support this as well. But I do not use it. Regards, Adrian > > Alex > > On Sat 19. Aug 2023 at 19.09, Khem Raj wrote: > > On Sat, Aug 19, 2023 at 5:42 AM > > wrote: > > > > > > Hi all, > > > i want to run my raspberry pi in qemu and for this, I have > > > created the image using core-image-weston and also set machine > > > to:MACHINE ??= "qemux86-64" .after this whenever I try to run > > > using qemu it shows > > > Error:"runqemu - ERROR - IMAGE_LINK_NAME wasn't set to find > > > corresponding .qemuboot.conf file" > > > > Its not clear what you are trying to do but I guess you have built > > an > > image for RPI which > > you want to run on an emulator instead of real hardware. In that > > case, > > you have to use > > either qemuarm or qemuarm64 depending upon your image being 64bit > > or > > 32bit. you might > > have to explore runqemu options where you can point it to a kernel > > and > > rootfs explicitly > > and use that to point it to the rpi images. This may not work even > > after that since there might be more tweaks needed for the pi image > > to > > run in qemu. > > > > > > > > Please help > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60833): https://lists.yoctoproject.org/g/yocto/message/60833 Mute This Topic: https://lists.yoctoproject.org/mt/100837806/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] systemd service not enabled #kirkstone #systemd
On Sun, 2023-07-30 at 04:00 -0700, daniel_herrman...@web.de wrote:
> Hello,
> I have a problem enabling a simple systemd service.
> I need a manual "systemctl enable" once after boot to enable my
> service.
> If anybody has an idea, it would be very cool.
> Here are my files.
> distro conf:
> DISTRO_FEATURES:append = " systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
> schedulingrealtime.bb:
> DESCRIPTION = "Setup a realtime sheduling"
> LICENSE = "CLOSED"
>
> inherit systemd
> NATIVE_SYSTEMD_SUPPORT = "1"
> SYSTEMD_PACKAGES = "${PN}"
> SYSTEMD_AUTO_ENABLE = "enable"
> SYSTEMD_SERVICE_${PN} = "schedulingrealtime.service"
This will probably fix it:
SYSTEMD_SERVICE:${PN} = "schedulingrealtime.service"
These lines are probably not needed:
NATIVE_SYSTEMD_SUPPORT = "1"
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_AUTO_ENABLE = "enable"
Did you also consider using the sysctl service instead of an extra
service?
https://www.freedesktop.org/software/systemd/man/systemd-sysctl.service.html
Regards,
Adiran
>
>
> FILESEXTRAPATHS:prepend := "${THISDIR}:"
> SRC_URI = " \
> file://schedulingrealtime.service \
> "
>
> do_install () {
> install -d ${D}${systemd_system_unitdir}
>
> install -m 0755 ${WORKDIR}/schedulingrealtime.service
> ${D}${systemd_system_unitdir}
> }
>
> FILES:${PN} += "\
> ${systemd_system_unitdir}/schedulingrealtime.service \
> schedulingrealtime.service
> [Unit]
> Description=modify scheduling parameter for realtime threads
>
> [Service]
> Type=oneshot
> ExecStart=/bin/bash -c "echo -1 >
> /proc/sys/kernel/sched_rt_runtime_us && echo -1 >
> /proc/sys/kernel/sched_rt_period_us"
>
> [Install]
> WantedBy=multi-user.target
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60682): https://lists.yoctoproject.org/g/yocto/message/60682
Mute This Topic: https://lists.yoctoproject.org/mt/100441626/21656
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Mute #systemd:https://lists.yoctoproject.org/g/yocto/mutehashtag/systemd
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] do_configure error while adding networkmanager to image
On Thu, 2023-07-06 at 13:12 +0300, Anders Montonen wrote: > > > > On 6 Jul 2023, at 12:55, MOHAMMED HASSAN > > wrote: > > > > On Thu, Jul 6, 2023 at 02:29 AM, Adrian Freihofer wrote: > > > Hi Hassan > > > > > > It's a bit hard to guess what you are really doing. The bb is a > > > fork > > > from a quite old version when it was still using the autotools. > > > Now we > > > use meson. > > > > > > The check for rl_echo_signal_char came into NetworkManager 8 > > > years ago > > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/b69143b5085c58e51ab8077ee5cbe6fafe73e041 > > > . > > > It's probably not a change on NetworkManager side which came in > > > recently with your update to 1.22.16. > > > > > > Compiling nmcli with readline works with the bb from meta- > > > openembedded > > > and the poky version with a similar age. That's the default. > > > > > > Some ideas: > > > - Try if the original recipe throws the same error > > > - Pass the readline parameter to autotools (what we do with newer > > > versions of the recipe and meson) > > > - Compile without nmcli and remove the readline dependency. Look > > > at the > > > commit history of the networkmanager.bb. There was an autotools > > > based > > > recipe which supported compiling without nmcli at some point in > > > time. > > Actually I want nmcli recipe in my yocto image file. I am still a > > beginner with this so i am facing these issues. Alternatively, I > > was looking at adding wireless-tools to my image file but i dont > > have its related recipe in my SDK. Do let me know if you have any > > suggestions. > > Are you using meta-gplv2? Its version of readline is too old for > NetworkManager. No, we don't use meta-gplv2. But we contributed the feature for compiling NetworkManager without readline to NetworkManager. Recent NetworkManager recipe versions 1.36+ have a packageconfig flag to build it with libedit instead of libreadline. Here are all commits: https://github.com/openembedded/meta-openembedded/commits/master/meta-networking/recipes-connectivity/networkmanager That's the one which introduces the libedit feature: https://github.com/openembedded/meta-openembedded/commit/9632eca6d27f29dc229d7a4c6663f97fc036661e --> Updating at least NetworkManager would help you. Regards, Adrian > > -a > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60528): https://lists.yoctoproject.org/g/yocto/message/60528 Mute This Topic: https://lists.yoctoproject.org/mt/99982001/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] do_configure error while adding networkmanager to image
On Thu, 2023-07-06 at 02:54 -0700, MOHAMMED HASSAN wrote: > On Thu, Jul 6, 2023 at 02:29 AM, Adrian Freihofer wrote: > > Hi Hassan > Hi Adrian, > Thanks for your reply. > > It's a bit hard to guess what you are really doing. The bb is a > > fork > > from a quite old version when it was still using the autotools. Now > > we > > use meson. > > > > The check for rl_echo_signal_char came into NetworkManager 8 years > > ago > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/b69143b5085c58e51ab8077ee5cbe6fafe73e041 > > . > > It's probably not a change on NetworkManager side which came in > > recently with your update to 1.22.16. > > > > Compiling nmcli with readline works with the bb from meta- > > openembedded > > and the poky version with a similar age. That's the default. > > > > Some ideas: > > - Try if the original recipe throws the same error > > - Pass the readline parameter to autotools (what we do with newer > > versions of the recipe and meson) > > - Compile without nmcli and remove the readline dependency. Look at > > the > > commit history of the networkmanager.bb. There was an autotools > > based > > recipe which supported compiling without nmcli at some point in > > time. > Actually I want nmcli recipe in my yocto image file. I am still a > beginner with this so i am facing these issues. Alternatively, I was > looking at adding wireless-tools to my image file but i dont have its > related recipe in my SDK. Do let me know if you have any suggestions. Sounds like I cannot provide any hints because with a standard bitbake environment this should just work. readline should be compiled and installed automatically. But since you mention SDK I guess you have a special (and potentially broken) setup. > > > > Regards, > > Adrian > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60526): https://lists.yoctoproject.org/g/yocto/message/60526 Mute This Topic: https://lists.yoctoproject.org/mt/99982001/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] do_configure error while adding networkmanager to image
Hi Hassan It's a bit hard to guess what you are really doing. The bb is a fork from a quite old version when it was still using the autotools. Now we use meson. The check for rl_echo_signal_char came into NetworkManager 8 years ago https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/b69143b5085c58e51ab8077ee5cbe6fafe73e041. It's probably not a change on NetworkManager side which came in recently with your update to 1.22.16. Compiling nmcli with readline works with the bb from meta-openembedded and the poky version with a similar age. That's the default. Some ideas: - Try if the original recipe throws the same error - Pass the readline parameter to autotools (what we do with newer versions of the recipe and meson) - Compile without nmcli and remove the readline dependency. Look at the commit history of the networkmanager.bb. There was an autotools based recipe which supported compiling without nmcli at some point in time. Regards, Adrian -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60523): https://lists.yoctoproject.org/g/yocto/message/60523 Mute This Topic: https://lists.yoctoproject.org/mt/99982001/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Register out-of-tree fetcher with devtool
On Fri, 2023-06-02 at 04:47 +, Weihmann, Konrad (Avnet Embedded)
wrote:
>
>
>
> Hi all,
>
> we do have an out-of-tree fetcher that I would like to make use of
> with devtool, for instance for upgrade checking.
> Within our recipes the fetcher is registered by this workaround
>
> python () {
> import foo
> bb.fetch2.methods.append(foo.FooFetcher())
> }
Hi Konrad
Is there a specific reason why you need to fetch at the time of
parsing? Or would it be possible to override the do_fetch task?
Regards,
Adrian
>
> Which isn’t the nicest possible solution still does the trick.
>
> But that doesn’t work for devtool, as it seems to not take any but
> oe-core lib-paths into consideration.
>
> For devtool check-upgrade-status
>
> I get something like “no handler for foo://… found”.
>
> Is there any way to register this out-of-tree fetcher module so
> tinfoil/devtool can “see” them?
>
> Cheers
> Konrad
>
>
>
>
--
Adrian Freihofer
Gschwaderweg 29
8610 Uster
+41 76 503 37 98
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60166): https://lists.yoctoproject.org/g/yocto/message/60166
Mute This Topic: https://lists.yoctoproject.org/mt/99280594/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] NetworkManager recipe installing both sysVinit script and systemd service ... which to use ?
Hi Steve Maybe this discussion provides some hints for you https://lists.openembedded.org/g/openembedded-devel/topic/98852053#102633 Regards Adrian -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60165): https://lists.yoctoproject.org/g/yocto/message/60165 Mute This Topic: https://lists.yoctoproject.org/mt/99274573/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [RFC][yocto][meta-lts-mixins][kirkstone/go] Backport golang from master to kirkstone
Hi Alex, hi José The meta-lts-mixin layers for dunfell have a major disadvantage: Replacing the go tool-chain breaks more or less all recipes from meta- virtualization and potentially other layers. I think with go it should be possible to have a meta-lts-mixin layer which adds support for additional go versions instead of overriding the version provided by poky. That would potentially allow to use poky on the kirkstone branch and meta-virtualization on a newer branch on the long run. Would it be possible to add e.g. a copy of the go.bbclass as well as the go recipes from a recent poky version in a way it does not override the go stack provided by poky? As an example: Would it be possible to add a go1-19.bbclass to the meta-meta-lts-mixin layer? This would allow to add also a newer Docker recipe which inherits go1-19 instead of just go to the meta-lts-mixin layers without breaking anything from poky or meta-virtualization. I already tried to share my thoughts here: https://lists.openembedded.org/g/openembedded-core/message/178146?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Cgolang%2C20%2C2%2C0%2C97444547 Best regards, Adrian On Thu, 2023-03-30 at 12:08 +0200, Alexander Kanavin wrote: > I think I pushed the work directly to the respecitve branches in > meta-lts-mixins. I'd suggest you send the patches here, and we'll > sort > out the technicalities (I can publish the branch on > git.yoctoproject.org, or maybe you'll be able to push directly as > well, provided you also send the patches here). There's no > autobuilder > testing; for mixin items the contributors are trusted :) > > Alex > > > On Thu, 30 Mar 2023 at 11:20, Jose Quaresma > wrote: > > > > Hi, > > > > The golang version in kirkstone is the 1.17 and because of this is > > not possible to use some recent version of other projects like > > docker that requires a more recent version of the language. > > > > I have a kirkstone branch [1] available at Foundries.io with the > > golang backported from the oe-core master that I liked to submit to > > the meta-lts-mixins [2]. > > Alex is the maintainer of the dunfell golang backport and this > > kirkstone branch is based on that version. > > > > Would that be interesting for the project? How should I proceed? > > > > [1] > > https://github.com/foundriesio/meta-lts-mixins/tree/kirkstone/go > > [2] https://git.yoctoproject.org/meta-lts-mixins > > > > Jose > > > > -- > > Best regards, > > > > José Quaresma > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#59549): https://lists.yoctoproject.org/g/yocto/message/59549 Mute This Topic: https://lists.yoctoproject.org/mt/97946990/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] error when try to use sudo command in recipe
Hi Simon
I guess in the deploy folder (build/tmp/deploy/...) you will find a tar
archive which can be used with e.g. docker import.
If you need to upload the OCI image to a container registry skopeo
might be used somehow like that:
bitbake "skopeo-native:do_addto_recipe_sysroot"
OCI_DIR="build/tmp/deploy/images/${MACHINE}/${TARGET_IMAGE}-
${MACHINE}.rootfs-oci"
oe-run-native skopeo-native skopeo login -u "${CI_REGISTRY_USER}" -p
"${CI_REGISTRY_PASSWORD}" "${CI_REGISTRY}" --authfile
${HOME}/.registry-auth.json
oe-run-native skopeo-native skopeo copy oci:${OCI_DIR}
docker://${CI_REGISTRY_IMAGE}:${CI_COMMIT_REF_SLUG}-${OCI_ARCH} --
authfile ${HOME}/.registry-auth.json
If you need to provide the container for different architectures
manifest-tool can do that. After uploading images to a registry the
manifest tool can convert all the per ARCH images into a multi arch
container image.
Regards,
Adrian
On Thu, 2023-02-09 at 10:45 -0800, SIMON BABY wrote:
> Hello,
>
> I was testing the meta-virtualization/recipes-demo/images/ app-
> container. I was able to build the container. But I am not sure where
> is the image created and how do we run the image using docker
> commands. I also see the .yaml files.
> On the target I can see /usr/bin/flask-app. Below is the folder
> contents after bitbake.
>
> bitbake app-container
>
> build/tmp/work/armv8a-poky-linux/helloworld-flask$ ls
> 0.1-r0
> /build/tmp/work/armv8a-poky-linux/helloworld-flask$ cd 0.1-r0/
> build/tmp/work/armv8a-poky-linux/helloworld-flask/0.1-r0$ ls -ll
> total 84
> -rw-r--r-- 1 tdydev tdydev 65 Feb 7 11:58 configure.sstate
> drwxr-xr-x 3 tdydev tdydev 4096 Feb 7 12:10 deploy-debs
> drwxr-xr-x 2 tdydev tdydev 4096 Feb 7 11:38 deploy-source-date-
> epoch
> -rwxrwxr-x 1 tdydev tdydev 518 Feb 2 14:24 flask-app
> -rw-r--r-- 1 tdydev tdydev 511 Feb 7 11:58 flask-app-service.yaml
> -rw-r--r-- 1 tdydev tdydev 178 Feb 7 11:58 flask-app.yaml
> drwxr-xr-x 2 tdydev tdydev 4096 Feb 7 11:35 helloworld-flask-0.1
> drwxr-xr-x 4 tdydev tdydev 4096 Feb 7 11:58 image
> drwxr-xr-x 3 tdydev tdydev 4096 Feb 7 11:38 license-destdir
> drwxr-xr-x 4 tdydev tdydev 4096 Apr 5 2011 package
> drwxr-xr-x 10 tdydev tdydev 4096 Feb 7 12:10 packages-split
> drwxr-xr-x 7 tdydev tdydev 4096 Apr 5 2011 pkgdata
> drwxr-xr-x 7 tdydev tdydev 4096 Feb 7 11:58 pkgdata-pdata-input
> drwxr-xr-x 7 tdydev tdydev 4096 Feb 7 11:58 pkgdata-sysroot
> drwxrwxr-x 2 tdydev tdydev 4096 Feb 7 12:10 pseudo
> drwxr-xr-x 5 tdydev tdydev 4096 Feb 7 12:10 recipe-sysroot
> drwxr-xr-x 8 tdydev tdydev 4096 Feb 7 12:10 recipe-sysroot-native
> drwxr-xr-x 2 tdydev tdydev 4096 Feb 7 11:35 source-date-epoch
> drwxr-xr-x 2 tdydev tdydev 12288
>
>
>
>
>
> Regards
> Simon
>
>
> On Sun, Feb 5, 2023 at 4:00 PM SIMON BABY via lists.yoctoproject.org
> wrote:
> > Hi Richard,
> >
> > I added extra code in the recipe to print the sudo permissions to
> > compare with actual permissions.
> >
> > Regards
> > Simon
> >
> >
> >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59207): https://lists.yoctoproject.org/g/yocto/message/59207
Mute This Topic: https://lists.yoctoproject.org/mt/96733939/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] meta-swupdate integration with the custom Yocto image #dunfell
Hi, I guess the sw-description file must be added to the Image recipe not to swupdate.bb. Note: There is a specific mailing list for swupdate. Regards, Adrian Mahendra Sondagar schrieb am So., 25. Sept. 2022, 20:01: > Thanks, Chetan for swift reply :) > > However, swupdate unable to fetch the files mentioned in .bbappend file! > > The error logs are attahced here > > As i said in my post, I have created recipes-myswupdate in to the > meta-custom file, which is parallel to meta-swupdate > All the above files distributions are inside this recipes-myswupdate file > I guess, that's the issue > > From the error logs, you can see, it's tries to find the file in to the > default *meta-swupdate/recipes-support* files rather than > *meta-custom/recipes-myswupdate*! > > Anyone else ? > > Regards > Mahendra > > > Thanks, > Mahendra Sondagar > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#58157): https://lists.yoctoproject.org/g/yocto/message/58157 Mute This Topic: https://lists.yoctoproject.org/mt/93911152/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] press request
Hi Jens-Christoph By when do you need it? The article should probably be written in German, correct? Regards, Adrian On Tue, 2022-04-26 at 10:25 +, Jens-Christoph Brendel wrote: > Hello, > > We, the German Linux magazine, are planning a focus on Linux > distributions for the IoT in the 07/22 issue. One of them we have in > mind is Yocto. We are therefore looking for an author who can > introduce Yocto to our readers in an article. Such an article should > be four to six pages (about 4000 characters each) and cover questions > such as: > > - What is Yocto? (main purpose, target audience, compatibility) > - Scope of services > - Differences and similarities compared to similar operating systems > - Advantages and disadvantages > - Examples of use > > After reading this, one should be able to estimate whether Yocto > meets the user's expectations and whether it is worth trying out. > > Is there anyone out there who would like and have the time to write > such an article for us? We would pay 80 Euro per printed page. We > prefer plain ASCII as text format and need some illustrations > (screenshots or diagrams or photos). Please contact me at > jens-christoph.bren...@computec.de. > > Thanks in advance > Jens-Christoph > . . . . > Disclaimer: The recipient acknowledges that Computec Media GmbH is > unable to exercise control over the content of information contained > in transmissions made via the Internet. Computec Media GmbH hereby > excludes any warranty, written or implied, as to the quality or > accuracy of any information contained in this message and any > liability of any kind for the information contained, therein, or for > its transmission, reception, storage or usage in any way, whatsoever. > Sitz der Gesellschaft und Registergericht: Fürth (HRB 14364) > Geschäftsführer: Christian Müller, Rainer Rosenbusch Umsatzsteuer- > Identifikationsnummer: DE812575276 > Informationen zur Datenverarbeitung und Datenschutz: > https://www.computec.de/datenschutz > . . . . > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56907): https://lists.yoctoproject.org/g/yocto/message/56907 Mute This Topic: https://lists.yoctoproject.org/mt/90704769/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [ptest-runner 5/5] main: Do not return number of failed tests when calling ptest-runner
Hi Lukasz Also our test infrastructure expects an exit value not equal to 0 in case of a failed test. Regards, Adrian On Wed, 2021-07-21 at 11:46 +0200, ?ukasz Majewski wrote: > Up till now ptest-runner2 returns number of failed tests with its > exit status code. Such use case is not recommended [1] and may cause > issues when there are more than 256 tests to be executed. > > To alleviate this issue the number of total tests with number of failed > ones is printed before exit. To be more specific - failure of a single > test doesn't indicate that the ptest-runner itself encounter any issue > during its execution. > > One can test this change with executing: > ./ptest-runner -d tests/data fail > > Links: > [1] - https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html > > Signed-off-by: Lukasz Majewski > --- > main.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/main.c b/main.c > index efa21b2..9f03857 100644 > --- a/main.c > +++ b/main.c > @@ -219,6 +219,9 @@ main(int argc, char *argv[]) > ptest_list_remove(run, opts.exclude[i], 1); > > > rc = run_ptests(run, opts, argv[0], stdout, stderr); > + fprintf(stdout, "TOTAL: %d FAIL: %d\n", ptest_list_length(run), rc); > + if (rc > 0) > + rc = 0; > > > ptest_list_free_all(); > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54239): https://lists.yoctoproject.org/g/yocto/message/54239 Mute This Topic: https://lists.yoctoproject.org/mt/84352910/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-security][master][dunfell][PATCH] gitignore added
After running testimage there are some python left overs at lib/oeqa/runtime/cases/__pycache__/ Signed-off-by: Adrian Freihofer --- .gitignore | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..c01df45 --- /dev/null +++ b/.gitignore @@ -0,0 +1,7 @@ +*.pyc +*.pyo +/*.patch +*.swp +*.orig +*.rej +*~ -- 2.26.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50779): https://lists.yoctoproject.org/g/yocto/message/50779 Mute This Topic: https://lists.yoctoproject.org/mt/77029779/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
