|
Re: Conf for a single recipe only
Alexander Kanavin
There's no way to build two versions of the same component, if the
versions share the recipe name. You have to fix the application, or try to rename one set of the go recipes so it is separate from the other set, to something like 'go-old'. Alex On Tue, 2 Aug 2022 at 15:15, Sebastian Rühl via lists.yoctoproject.org <sebastian=mapped.com@...> wrote:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: BBClass function and symbolic link (symlink) ... I throw in the towel
#kirkstone
#python
#bitbake
Joshua Watt
On Tue, Aug 2, 2022 at 8:44 AM Martin Leduc via lists.yoctoproject.org
<martin.leduc=luminator.com@...> wrote: Can you provide a little more detail about how it crashes? Also, I'm not quite clear what you mean by "works like a charm with Warrior"; it sounds like something still isn't working in Warrior that you need, or just in Kirkstone?
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
BBClass function and symbolic link (symlink) ... I throw in the towel
#kirkstone
#python
#bitbake
Martin Leduc <martin.leduc@...>
Hi team,
Well, I throw in the towel. But it's looks like so simple .... for me 🤣🤣. I've a function to replace the version file in /etc/version. This function is integrated into my mybase-image.bbclass, defined in my layer and I add, in my core-image-minimal.bbappend recipe inherit mybase-image.bbclass. In my bbclass, I call my function using ROOTFS_POSTPROCESS_COMMAND += " \
set_version_file ; \
"
My function is written like this set_version_file() {
bbplain "set_version_file BEGIN"
mkdir -p ${IMAGE_ROOTFS}/etc/tmp/
echo ${PV} > ${IMAGE_ROOTFS}/etc/tmp/version
chmod 644 ${IMAGE_ROOTFS}/etc/tmp/version
rm ${IMAGE_ROOTFS}/etc/version
ln -sf /etc/tmp/version "${IMAGE_ROOTFS}/etc/version"
}
I mean, I don't try to do anything outstanding but the ln -sf line makes my compilation crash BUT.... it works like a charm with Warrior but Kirkstone rejects "ln -sf" command. I'm definitely not the only one who adds symlinks to the recipes I've also tried:
I'm unable to find where is my issue. Any ideas are welcome, even if it works like a charm on Warrior but not in Kirkstone. BR, Martin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Nikita Gupta <nikitagupta2509@...>
I have generated two yocto builds at different times while taking the same SDK and target. So is there any way to verify yocto builds so I could differentiate between them for their timestamp, date and yocto version, etc? And also could get to know whether both bzImages are the same or not. Thanks in Advance |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Conf for a single recipe only
Sebastian Rühl
Is there a way to set the GOVERSION for a single recipe only?
At the moment I set the Golang version to 1.18 using the recipes from master (on a local dunfell branch) and set the go version in the layer conf: PREFERRED_VERSION_go-binary-native = "1.18%" PREFERRED_VERSION_go-cross-canadian = "1.18%" PREFERRED_VERSION_go-cross = "1.18%" PREFERRED_VERSION_go-crosssdk = "1.18%" PREFERRED_VERSION_go-native = "1.18%" PREFERRED_VERSION_go-runtime = "1.18%" PREFERRED_VERSION_go = "1.18%" So I want to use those settings only for my application recipe. Any ideas how to achieve that? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[layerindex-web][PATCH] utils.py: Use get_layer_var() to get BBFILE_COLLECTIONS
Robert Yang
The commit 38e6288c7dad579518b0de2b6664f23be58889b6 has added oe-core to
BBLAYERS by default, and then there will be mutliple BBFILE_COLLECTIONS and caused update.py failed to update layers (most of the dependencies or reccommends are missing), use get_layer_var() to get BBFILE_COLLECTIONS to fix the problem since it can ignore the extra oe-core from BBFILE_COLLECTIONS. Signed-off-by: Robert Yang <liezhi.yang@...> --- layerindex/utils.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/layerindex/utils.py b/layerindex/utils.py index efd18e4..ed7fb47 100644 --- a/layerindex/utils.py +++ b/layerindex/utils.py @@ -188,7 +188,7 @@ def _add_dependency(var, name, layerbranch, config_data, logger=None, required=T logger.warn('Either set REMOVE_LAYER_DEPENDENCIES to remove them from the database, or fix conf/layer.conf') def set_layerbranch_collection_version(layerbranch, config_data, logger=None): - layerbranch.collection = config_data.getVar('BBFILE_COLLECTIONS', True) + layerbranch.collection = get_layer_var(config_data, 'BBFILE_COLLECTIONS', logger) ver_str = "LAYERVERSION_" if layerbranch.collection: layerbranch.collection = layerbranch.collection.strip() -- 2.37.0 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW31
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW31!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 4.1
Stephen Jolley
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
Stephen Jolley
All,
The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 410 unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “4.1”, “4.2”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.
Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Confused as to why runtime variables (RDEPENDS, RPROVIDES, etc) require package name overrides
kergoth@...
It doesn't have anything to do with parsing. A single bitbake recipe will write multiple binary packages by splitting up its files, so each binary package it writes has its own metadata. On Mon, Aug 1, 2022 at 10:45 AM <brownij6@...> wrote: Essentially I don't understand why variables like RDEPENDS require a package name conditional override such as "RDEPENDS_${PN}" while other variables, including DEPENDS, do not require this. Isn't putting the package name as a conditional after the variable pointless, since bitbake only parses the variables from the recipe it is currently building? I feel like my confusion may stem from some fundamental misunderstanding of the way the build system works. --
Christopher Larson chris_larson@..., chris.larson@..., kergoth@... Principal Software Engineer, Embedded Linux Solutions, Siemens Digital Industries Software |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Confused as to why runtime variables (RDEPENDS, RPROVIDES, etc) require package name overrides
brownij6@...
Essentially I don't understand why variables like RDEPENDS require a package name conditional override such as "RDEPENDS_${PN}" while other variables, including DEPENDS, do not require this. Isn't putting the package name as a conditional after the variable pointless, since bitbake only parses the variables from the recipe it is currently building? I feel like my confusion may stem from some fundamental misunderstanding of the way the build system works.
Thanks for your help, James |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 2/2] packagegroup-core-security: remove krill for some archs
Signed-off-by: Armin Kuster <akuster808@...>
--- recipes-core/packagegroup/packagegroup-core-security.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb index 821ebf6..a12a4c2 100644 --- a/recipes-core/packagegroup/packagegroup-core-security.bb +++ b/recipes-core/packagegroup/packagegroup-core-security.bb @@ -44,7 +44,10 @@ RDEPENDS:packagegroup-security-utils = "\ RDEPENDS:packagegroup-security-utils:append:x86 = "chipsec" RDEPENDS:packagegroup-security-utils:append:x86-64 = "chipsec" -RDEPENDS:packagegroup-security-utils:remove:mipsarch = "firejail" +RDEPENDS:packagegroup-security-utils:remove:mipsarch = "firejail krill" +RDEPENDS:packagegroup-security-utils:remove:libc-musl = "krill" +RDEPENDS:packagegroup-security-utils:remove:riscv64 = "krill" +RDEPENDS:packagegroup-security-utils:remove:armv7ve = " krill" SUMMARY:packagegroup-security-scanners = "Security scanners" RDEPENDS:packagegroup-security-scanners = "\ -- 2.25.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-security][PATCH 1/2] krill: only builds on x86/x86-64 and arm64
Signed-off-by: Armin Kuster <akuster808@...>
--- recipes-security/krill/krill_0.9.6.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/recipes-security/krill/krill_0.9.6.bb b/recipes-security/krill/krill_0.9.6.bb index c8b5b0c..fd86c4b 100644 --- a/recipes-security/krill/krill_0.9.6.bb +++ b/recipes-security/krill/krill_0.9.6.bb @@ -20,7 +20,6 @@ CARGO_SRC_DIR = "" inherit pkgconfig useradd systemd cargo - do_install:append () { install -d ${D}${sysconfdir} install -d ${D}${datadir}/krill @@ -39,3 +38,5 @@ USERADD_PARAM:${PN} = "--system -g ${KRILL_GID} --home-dir \ --shell /sbin/nologin ${BPN}" FILES:${PN} += "{sysconfdir}/defaults ${datadir}" + +COMPATIBLE_HOST = "(i.86|x86_64|aarch64).*-linux" -- 2.25.1 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: nftables_0.7 not working
Quentin Schulz
Hi Maik,
On 8/1/22 17:34, Maik Vermeulen wrote: Hi Quentin,No, you would indeed need to enable those in your kernel config. Cheers, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: nftables_0.7 not working
Maik Vermeulen
Hi Quentin, Thank you for your response! I added kernel-modules to the IMAGE_INSTALL_append, but it seems that the modules are still not being loaded. Is that the correct way? Also I see that CONFIG_NF_TABLES is not set (with ~# zcat /proc/config.gz | grep CONFIG_NF_ | grep TABLE) Is that expected? On Mon, Aug 1, 2022 at 3:51 PM Quentin Schulz <quentin.schulz@...> wrote: Hi Maik,  Automotive Campus 70 —5708 JZ Helmond, the Netherlands This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: nftables_0.7 not working
Quentin Schulz
Hi Maik,
On 8/1/22 14:41, Maik Vermeulen wrote: Hi,It seems you built many netfilter features/drivers as modules and not built-in in the kernel. When that is the case, you need to add the modules to your image because Yocto does not do it for you. Yocto splits each module in its own package. As a simple try, you can add the kernel-modules package to your image, it is a package that pulls all kernel module packages all at once. At least you'll know if there's another issue before pinpointing the exact kernel module package names you will want in your image (kernel-modules can be pretty big if you don't have a "clean" defconfig with many unnecessary drivers built as modules). Cheers, Quentin |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
error building core-image-full-cmdline image on kirkstone for powerpc 64 (meta-freescale, t1024rdb-64b machine)
Sona Sarmadi (ssarmadi) <ssarmadi@...>
Hi everyone,
I get some errors when I build “core-image-full-cmdline” for t1024rdb-64b machine. I fix the error then I get another one, so I wonder if anybody has seen these errors or if meta-freescale (kirkstone) has been tested/used by someone?
This is what I do:
Here are the errors I get: #error 1:
| make -f /home/sona/shared/yocto-kirkstone/builds/ppc64/tmp/work/t1024rdb_64b-poky-linux/u-boot-qoriq/2021.04+fslgit-r0/git/scripts/Makefile.build obj=drivers
Vim cpld.h +24 struct cpld_data { Is “cpld_data_t” supposed to be a type definition (as the “_t” suffix indicates) or a variable declaration? Variable declarations in header files need “extern” and an accompanying variable definition in some C file.
#error 2: File "../yocto- kirkstone/builds/ppc64/tmp/work/t1024rdb_64b-poky-linux/u-boot-qoriq/2021.04+fslgit-r0/git/tools/binman/../binman/control.py", line 11, in <module> meta-freescale/recipes-bsp/u-boot/u-boot-qoriq_2021.04.bb
#error 3:
..yocto-kirkstone/builds/ppc64/tmp/work/t1024rdb_64b-poky-linux/lttng-modules/2.13.3-r0/lttng-modules-2.13.3/src/wrapper/kallsyms.c:20:3: error: #error "LTTng-modules
requires CONFIG_KPROBES on kernels >= 5.7.0"
Thanks --Sona
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
nftables_0.7 not working
Maik Vermeulen
Hi,
I added the following to our image recipe: IMAGE_INSTALL_append = " nftables" When running that image, nftables seems to be included, but we get the following error: ~# nft ../../nftables-0.7/src/netlink.c:59: Unable to initialize Netlink socket: Protocol not supported Furthermore, it's not showing in lsmod, and also not in modprobe --showconfigs. This is the active kernel config: root@agent336:~# zcat /proc/config.gz | grep "CONFIG_NF_\|CONFIG_NETFILTER_" CONFIG_NETFILTER_ADVANCED=y CONFIG_NETFILTER_INGRESS=y # CONFIG_NETFILTER_NETLINK_ACCT is not set # CONFIG_NETFILTER_NETLINK_QUEUE is not set # CONFIG_NETFILTER_NETLINK_LOG is not set CONFIG_NF_CONNTRACK=m CONFIG_NF_LOG_COMMON=m # CONFIG_NF_LOG_NETDEV is not set # CONFIG_NF_CONNTRACK_MARK is not set CONFIG_NF_CONNTRACK_PROCFS=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_TIMEOUT is not set # CONFIG_NF_CONNTRACK_TIMESTAMP is not set CONFIG_NF_CT_PROTO_DCCP=y CONFIG_NF_CT_PROTO_SCTP=y CONFIG_NF_CT_PROTO_UDPLITE=y # CONFIG_NF_CONNTRACK_AMANDA is not set # CONFIG_NF_CONNTRACK_FTP is not set # CONFIG_NF_CONNTRACK_H323 is not set # CONFIG_NF_CONNTRACK_IRC is not set # CONFIG_NF_CONNTRACK_NETBIOS_NS is not set # CONFIG_NF_CONNTRACK_SNMP is not set # CONFIG_NF_CONNTRACK_PPTP is not set # CONFIG_NF_CONNTRACK_SANE is not set # CONFIG_NF_CONNTRACK_SIP is not set # CONFIG_NF_CONNTRACK_TFTP is not set # CONFIG_NF_CT_NETLINK is not set # CONFIG_NF_CT_NETLINK_TIMEOUT is not set CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_NF_NAT_PROTO_DCCP=y CONFIG_NF_NAT_PROTO_UDPLITE=y CONFIG_NF_NAT_PROTO_SCTP=y # CONFIG_NF_NAT_AMANDA is not set # CONFIG_NF_NAT_FTP is not set # CONFIG_NF_NAT_IRC is not set # CONFIG_NF_NAT_SIP is not set # CONFIG_NF_NAT_TFTP is not set # CONFIG_NF_NAT_REDIRECT is not set # CONFIG_NF_TABLES is not set CONFIG_NETFILTER_XTABLES=m # CONFIG_NETFILTER_XT_MARK is not set # CONFIG_NETFILTER_XT_CONNMARK is not set # CONFIG_NETFILTER_XT_TARGET_AUDIT is not set CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m # CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set # CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set # CONFIG_NETFILTER_XT_TARGET_DSCP is not set # CONFIG_NETFILTER_XT_TARGET_HL is not set # CONFIG_NETFILTER_XT_TARGET_HMARK is not set # CONFIG_NETFILTER_XT_TARGET_IDLETIMER is not set # CONFIG_NETFILTER_XT_TARGET_LED is not set CONFIG_NETFILTER_XT_TARGET_LOG=m # CONFIG_NETFILTER_XT_TARGET_MARK is not set CONFIG_NETFILTER_XT_NAT=m # CONFIG_NETFILTER_XT_TARGET_NETMAP is not set # CONFIG_NETFILTER_XT_TARGET_NFLOG is not set # CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set # CONFIG_NETFILTER_XT_TARGET_RATEEST is not set # CONFIG_NETFILTER_XT_TARGET_REDIRECT is not set # CONFIG_NETFILTER_XT_TARGET_TEE is not set # CONFIG_NETFILTER_XT_TARGET_TPROXY is not set # CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set # CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP is not set CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m # CONFIG_NETFILTER_XT_MATCH_BPF is not set # CONFIG_NETFILTER_XT_MATCH_CGROUP is not set # CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set # CONFIG_NETFILTER_XT_MATCH_COMMENT is not set # CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set # CONFIG_NETFILTER_XT_MATCH_CONNLABEL is not set # CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set # CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m # CONFIG_NETFILTER_XT_MATCH_CPU is not set # CONFIG_NETFILTER_XT_MATCH_DCCP is not set # CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set # CONFIG_NETFILTER_XT_MATCH_DSCP is not set # CONFIG_NETFILTER_XT_MATCH_ECN is not set # CONFIG_NETFILTER_XT_MATCH_ESP is not set # CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set # CONFIG_NETFILTER_XT_MATCH_HELPER is not set # CONFIG_NETFILTER_XT_MATCH_HL is not set # CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set # CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set # CONFIG_NETFILTER_XT_MATCH_L2TP is not set # CONFIG_NETFILTER_XT_MATCH_LENGTH is not set # CONFIG_NETFILTER_XT_MATCH_LIMIT is not set # CONFIG_NETFILTER_XT_MATCH_MAC is not set # CONFIG_NETFILTER_XT_MATCH_MARK is not set # CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set # CONFIG_NETFILTER_XT_MATCH_NFACCT is not set # CONFIG_NETFILTER_XT_MATCH_OWNER is not set # CONFIG_NETFILTER_XT_MATCH_POLICY is not set # CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set # CONFIG_NETFILTER_XT_MATCH_QUOTA is not set # CONFIG_NETFILTER_XT_MATCH_RATEEST is not set # CONFIG_NETFILTER_XT_MATCH_REALM is not set # CONFIG_NETFILTER_XT_MATCH_RECENT is not set # CONFIG_NETFILTER_XT_MATCH_SCTP is not set # CONFIG_NETFILTER_XT_MATCH_STATE is not set # CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set # CONFIG_NETFILTER_XT_MATCH_STRING is not set # CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set # CONFIG_NETFILTER_XT_MATCH_TIME is not set # CONFIG_NETFILTER_XT_MATCH_U32 is not set CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_SOCKET_IPV4 is not set # CONFIG_NF_DUP_IPV4 is not set # CONFIG_NF_LOG_ARP is not set CONFIG_NF_LOG_IPV4=m CONFIG_NF_REJECT_IPV4=m CONFIG_NF_NAT_IPV4=m CONFIG_NF_NAT_MASQUERADE_IPV4=m # CONFIG_NF_NAT_PPTP is not set # CONFIG_NF_NAT_H323 is not set CONFIG_NF_DEFRAG_IPV6=m CONFIG_NF_CONNTRACK_IPV6=m # CONFIG_NF_SOCKET_IPV6 is not set # CONFIG_NF_DUP_IPV6 is not set CONFIG_NF_REJECT_IPV6=m CONFIG_NF_LOG_IPV6=m CONFIG_NF_NAT_IPV6=m CONFIG_NF_NAT_MASQUERADE_IPV6=m What am I missing? Should I enable it some other way instead of using IMAGE_INSTALL_append? Do I need to enable more? Thanks, Kind regards, Automotive Campus 70 —5708 JZ Helmond, the Netherlands This email may contain information which is privileged and/or confidential. If you received this e-mail in error, please notify us immediately by e-mail and delete the email without copying or disclosing its contents to any other person. Lightyear is a trade name of Atlas Technologies B.V. and is registered at the Dutch Chamber of Commerce under number 67264298. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Re : rdepends upon non-existent task do_package_write_deb
Poornesh G ( India - Bangalore )
Thanks for your valuable reply .
I followed the procedure which you have mentioned i.e added IMAGE_INSTALL:append = " go.opentelemetry.io-proto-otlp" in local.conf file. After that I am getting this error , can you please suggest me where I need to modify . ------------------------------------------------------------------------ user@user-Latitude-3490:~/yocto/imx_krikstone/build$ bitbake core-image-minimal WARNING: You have included the meta-virtualization layer, but 'virtualization' has not been enabled in your DISTRO_FEATURES. Some bbappend files may not take effect. See the meta-virtualization README for details on enabling virtualization support. Loading cache: 100% |############################################################################################################| Time: 0:00:00 Loaded 5514 entries from dependency cache. Parsing recipes: 100% |##########################################################################################################| Time: 0:00:00 Parsing of 3954 .bb files complete (3953 cached, 1 parsed). 5514 targets, 658 skipped, 5 masked, 0 errors. Removing 1 recipes from the cortexa7t2hf-neon sysroot: 100% |####################################################################| Time: 0:00:00 Removing 1 recipes from the imx6ul_pds sysroot: 100% |###########################################################################| Time: 0:00:00 NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'go.opentelemetry.io-proto-otlp' (but /home/user/yocto/imx_krikstone/sources/poky/meta/recipes-core/images/core-image-minimal.bb RDEPENDS on or otherwise requires it) NOTE: Runtime target 'go.opentelemetry.io-proto-otlp' is unbuildable, removing... Missing or unbuildable dependency chain was: ['go.opentelemetry.io-proto-otlp'] ERROR: Required build target 'core-image-minimal' has no buildable providers. Missing or unbuildable dependency chain was: ['core-image-minimal', 'go.opentelemetry.io-proto-otlp'] ------------------------------------------------------------------------ Thanks in advance |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||