|
New Override Syntax
Darcy Watkins
Hi,
Does anyone know how long (or how many releases) that the old override syntax will still be supported? (Like a deprecation EOL cycle).
A corollary question: How far back in old releases is the new syntax supported?
This potentially affects layers that have a single branch that support multiple versions of Yocto/OE.
Thanks!
Regards,
Darcy
Darcy Watkins :: Senior Staff Engineer, Firmware
SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [M4]
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
yocto 3.1.3 cant seem to remove run-postinsts
jared_terry@...
https://www.yoctoproject.org/docs/3.1.3/ref-manual/ref-manual.html#migration-2.1-miscellaneous-changes
IMAGE_FEATURES="debug-tweaks read-only-rootfs" according to the manual having read-only-rootfs should remove run-postinsts and I still have it. How can I get rid of this? local.conf: PACKAGE_EXCLUDE = "run-postinsts" This didn't do anything either.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Project Status WW32`21
Stephen Jolley
Current Dev Position: YP 3.4 M3 Next Deadline: 23rd Aug. 2021 YP 3.4 M3 build (Feature Freeze)
Next Team Meetings:
Key Status/Updates:
http://docs.yoctoproject.org/migration-guides/migration-3.4.html#override-syntax-changes
Ways to contribute:
YP 3.4 Milestone Dates:
Planned upcoming dot releases:
Tracking Metrics:
The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC
The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status
[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW32
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW32!
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
What is the best way to get Environment variables setup in my shell script for export PATH?
JH
Hi,
Please correct me, but I think the system environment set up in Yocto Linux may not be the same as other distributions. I have a shell script to set up export PATH and LD_LIBRARY_PATH, I want to avoid putting full path in ExecStart and all of my shell scripts ExecStart=my_measurement.sh I have been thinking of the following options, but I am not sure which one works, if the syntax is correct or not, which one is the best for common practice, appreciate your advice. (1) Setup in all systemd service scripts [Service] EnvironmentFile=/usr/bin/my_export.sh ExecStart=my_measurement.sh Is the syntax above statements in service scripts correct? Will it work? (2) Add my_export.sh to /etc/profile.d That one works for Ubuntu, Debian and CentOS, will all Yocto systemd service scripts pick up environment setup from /etc/profile.d automatically in Yocto Linux distribution? (3) Add my_export.sh to /etc/default Some distributions automatically pick setup from /etc/default, does it work for Yocto Linux for systemd service scripts to pick up my_export.sh setup from /etc/default? Thank you. Kind regards, - jupiter
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current high bug count owners for Yocto Project 3.4
Stephen Jolley
All,
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 374 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, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.
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: How does one add do_fetch, do_unpack to an image recipe?
John Klug
Thanks for your great help. A native recipe is what I needed with data in it only. So my native recipe copies files into ${D}${datadir}/${PN}.
Then my image build uses DEPENDS= to bring in the native recipe. Then my IMAGE_POSTPROCESS_COMMAND can reference ${STAGING_DATADIR_NATIVE}/[native recipe name] to find the data it needs. Then I don't need to patch the bbclass file. From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> on behalf of Josef Holzmayr <jester@theyoctojester.info> Sent: Monday, August 9, 2021 12:41 AM To: yocto@lists.yoctoproject.org Subject: Re: [yocto] How does one add do_fetch, do_unpack to an image recipe? Howdy! Am 07.08.2021 um 02:25 schrieb John Klug: I am using dunfell.From first glance, I'd guess that the approach is just not correct. If that thing to be fetched also needs to go *into* the image: make it a recipe on its own. If you only need it during build time, then it should probably be a -native dependency, and therefore again a recipe on its own. Then the image recipe can depend on it and use its contents during the build/postprocess stage. Greetz
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Audio playback issue with ogg123 (vorbis-tools)
Michael Opdenacker
Greetings,
I'm trying to play an Ogg/Vorbis sample from an image I generated with Poky (master) and meta-oe (master), by adding "ogg123" and "alsa-utils" (for testing purposes) to "core-image-minimal". I built the image for qemux86-64 and tested it ran in a chroot on my x86 build machine. I mounted proc, sysfs and devtmpfs on /proc, /sys/ and /dev in the chroot, respectively. I could play a WAV file through "aplay" (from alsa-utils) from the chroot, but I didn't manage to play an Ogg/Vorbis sample on the audio card: # ogg123 /sample.ogg === Could not load default driver and no driver specified in config file. Exiting. However, I could "play" the sample file to a WAV file: ogg123 -d wav -f output.wav /sample.ogg Looking at the code, it seems there's a back-end issue (libao, alsa-lib?), so I suspect ogg123 or libao were built with missing features. I checked that libao was configured with Alsa support. I'll go on investigating, but if you have ideas, I'm interested! Cheers, Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Hello world recipe
Bel Hadj Salem Talel <bhstalel@...>
It is clear that the build system cannot find anything that is providing 'python-hello' recipe.
Which means it parsed all layers in bblayers.conf and it didn't find any python-hello_*.bb file (the _* is the version) It is mentioned in the tutorial that you provided that the recipe should be in meta-layer/recipes-custom/python-hello So, you need to create that layer, follow: bitbake-layers create-layer meta-custom bitbake-layers add-layer meta-custom Now, in that layer create folders: recipes-custom/python-hello, in that you should have: 1. another folder: files in that you put python-hello.py 2. python-hello.bb the content of all of that is in the tutorial .
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello world recipe
yasminebenghozzi6@...
Hello everyone,
SO i ve been following this tutorial to be able to execute hello world on the raspberry pi, but i tried so much and still not working, please any help? e I followed the tutorial from the Scripts et modules PYthon part: https://www.blaess.fr/christophe/yocto-lab/sequence-III-1/index.html#scripts-et-modules-python 
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-selinux][dunfell][PATCH] libselinux: Backport class cache flushing patch from 3.1
Daniel Danner <daniel.danner@...>
This fixes a bug in libselinux that gets triggered by loading another
policy at runtime. Before this patch, the userspace class cache was not flushed when a new policy was loaded. This led to SELinux-aware processes performing invalid lookups if their lifecycle overlapped with a policy load. Specifically, lookups performed by dbus-daemon would yield invalid results due to using outdated class IDs in their query. --- ...t-flush_class_cache-call-it-on-polic.patch | 126 ++++++++++++++++++ recipes-security/selinux/libselinux_3.0.bb | 1 + 2 files changed, 127 insertions(+) create mode 100644 recipes-security/selinux/libselinux/0001-libselinux-export-flush_class_cache-call-it-on-polic.patch diff --git recipes-security/selinux/libselinux/0001-libselinux-export-flush_class_cache-call-it-on-polic.patch recipes-security/selinux/libselinux/0001-libselinux-export-flush_class_cache-call-it-on-polic.patch new file mode 100644 index 0000000..dd79f64 --- /dev/null +++ recipes-security/selinux/libselinux/0001-libselinux-export-flush_class_cache-call-it-on-polic.patch @@ -0,0 +1,126 @@ +From 7bece3768b8ce63d79ef59bab83517b4e950f8fb Mon Sep 17 00:00:00 2001 +From: Stephen Smalley <sds@tycho.nsa.gov> +Date: Tue, 21 Jan 2020 11:18:22 -0500 +Subject: [PATCH] libselinux: export flush_class_cache(), call it on policyload + +Rename flush_class_cache() to selinux_flush_class_cache(), export it +for direct use by userspace policy enforcers, and call it on all policy +load notifications rather than only when using selinux_check_access(). +This ensures that policy reloads that change a userspace class or +permission value will be reflected by subsequent string_to_security_class() +or string_to_av_perm() calls. + +Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> +--- + libselinux/include/selinux/selinux.h | 3 +++ + libselinux/src/avc_internal.c | 2 ++ + libselinux/src/checkAccess.c | 13 ------------- + libselinux/src/selinux_internal.h | 3 +-- + libselinux/src/stringrep.c | 4 +++- + 5 files changed, 9 insertions(+), 16 deletions(-) + +Upstream-Status: Backport [https://github.com/SELinuxProject/selinux/commit/7bece3768b8ce63d79ef59bab83517b4e950f8fb] + +diff --git libselinux/include/selinux/selinux.h libselinux/include/selinux/selinux.h +index fe46e681..7922d96b 100644 +--- libselinux/include/selinux/selinux.h ++++ libselinux/include/selinux/selinux.h +@@ -418,6 +418,9 @@ extern int security_av_string(security_class_t tclass, + /* Display an access vector in a string representation. */ + extern void print_access_vector(security_class_t tclass, access_vector_t av); + ++/* Flush the SELinux class cache, e.g. upon a policy reload. */ ++extern void selinux_flush_class_cache(void); ++ + /* Set the function used by matchpathcon_init when displaying + errors about the file_contexts configuration. If not set, + then this defaults to fprintf(stderr, fmt, ...). */ +diff --git libselinux/src/avc_internal.c libselinux/src/avc_internal.c +index 49cecc96..568a3d92 100644 +--- libselinux/src/avc_internal.c ++++ libselinux/src/avc_internal.c +@@ -23,6 +23,7 @@ + #include "callbacks.h" + #include "selinux_netlink.h" + #include "avc_internal.h" ++#include "selinux_internal.h" + + #ifndef NETLINK_SELINUX + #define NETLINK_SELINUX 7 +@@ -207,6 +208,7 @@ static int avc_netlink_process(void *buf) + avc_prefix, rc, errno); + return rc; + } ++ selinux_flush_class_cache(); + rc = selinux_netlink_policyload(msg->seqno); + if (rc < 0) + return rc; +diff --git libselinux/src/checkAccess.c libselinux/src/checkAccess.c +index 16bfcfb6..7227ffe5 100644 +--- libselinux/src/checkAccess.c ++++ libselinux/src/checkAccess.c +@@ -10,25 +10,12 @@ + static pthread_once_t once = PTHREAD_ONCE_INIT; + static int selinux_enabled; + +-static int avc_reset_callback(uint32_t event __attribute__((unused)), +- security_id_t ssid __attribute__((unused)), +- security_id_t tsid __attribute__((unused)), +- security_class_t tclass __attribute__((unused)), +- access_vector_t perms __attribute__((unused)), +- access_vector_t *out_retained __attribute__((unused))) +-{ +- flush_class_cache(); +- return 0; +-} +- + static void avc_init_once(void) + { + selinux_enabled = is_selinux_enabled(); + if (selinux_enabled == 1) { + if (avc_open(NULL, 0)) + return; +- avc_add_callback(avc_reset_callback, AVC_CALLBACK_RESET, +- 0, 0, 0, 0); + } + } + +diff --git libselinux/src/selinux_internal.h libselinux/src/selinux_internal.h +index 8b4bed2f..61b78aaa 100644 +--- libselinux/src/selinux_internal.h ++++ libselinux/src/selinux_internal.h +@@ -107,8 +107,7 @@ hidden_proto(selinux_trans_to_raw_context); + hidden_proto(security_get_initial_context); + hidden_proto(security_get_initial_context_raw); + hidden_proto(selinux_reset_config); +- +-hidden void flush_class_cache(void); ++hidden_proto(selinux_flush_class_cache); + + extern int require_seusers hidden; + extern int selinux_page_size hidden; +diff --git libselinux/src/stringrep.c libselinux/src/stringrep.c +index 4db95398..29757b75 100644 +--- libselinux/src/stringrep.c ++++ libselinux/src/stringrep.c +@@ -158,7 +158,7 @@ err1: + return NULL; + } + +-hidden void flush_class_cache(void) ++void selinux_flush_class_cache(void) + { + struct discover_class_node *cur = discover_class_cache, *prev = NULL; + size_t i; +@@ -180,6 +180,8 @@ hidden void flush_class_cache(void) + discover_class_cache = NULL; + } + ++hidden_def(selinux_flush_class_cache) ++ + security_class_t string_to_security_class(const char *s) + { + struct discover_class_node *node; +-- +2.25.1 + diff --git recipes-security/selinux/libselinux_3.0.bb recipes-security/selinux/libselinux_3.0.bb index 05d2346..17a25a9 100644 --- recipes-security/selinux/libselinux_3.0.bb +++ recipes-security/selinux/libselinux_3.0.bb @@ -12,4 +12,5 @@ SRC_URI += "\ file://libselinux-make-SOCK_CLOEXEC-optional.patch \ file://libselinux-define-FD_CLOEXEC-as-necessary.patch \ file://0001-Fix-building-against-musl-and-uClibc-libc-libraries.patch \ + file://0001-libselinux-export-flush_class_cache-call-it-on-polic.patch \ " -- 2.25.1
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: How does one add do_fetch, do_unpack to an image recipe?
Josef Holzmayr
Howdy!
Am 07.08.2021 um 02:25 schrieb John Klug: I am using dunfell.From first glance, I'd guess that the approach is just not correct. If that thing to be fetched also needs to go *into* the image: make it a recipe on its own. If you only need it during build time, then it should probably be a -native dependency, and therefore again a recipe on its own. Then the image recipe can depend on it and use its contents during the build/postprocess stage. Greetz Thanks.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: linux-hotplug recipe
Josef Holzmayr
Howdy!
Am 08.08.2021 um 16:11 schrieb chiefsleepyeye@gmail.com: I'm new to yocto so forgive me if this has been answered before. I searched a number of resources and wasn't able to find an answer. I've been able to install yocto and make modifications to the bblayers.conf and local.conf files to add recipes and layers that provide recipes for the components I need. I wanted to add hotplug and found there is a "meta package" from yocto called "linux-hotplug". The problem I'm having is finding out which layer provides that recipe. Can someone point me in the right direction and/or point me at a tool that allows searching through all recipes, configured for use or not, for recipes. I've used oe-pkgutils-tool and bitbake-layers but, as far as I can tell they only search in layers configured to be used. I also tried the layer search tool on the open embedded website but got no hits for the aforementioned recipe. I feel like I'm missing something here but I don't know what. Any help would be appreciated. Thanks to all.http://layers.openembedded.org respectively for you http://layers.openembedded.org/layerindex/branch/master/recipes/?q=hotplug obviously... gut it doesn't seem that the information you based your question on is accurate, no "linux-hotplug" there. If I had to guess, then you found either something massively outdated, or referring to a non-openly accessible layer. Greetz Mike
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: Aug 5, 2021
YP AB Intermittent failures meeting
=================================== Aug 5, 2021, 9 AM ET https://windriver.zoom.us/j/3696693975 Attendees: Tony, Richard, Trevor, Randy, Sakib! Summary: ======== ptest failures again are better but there's still room for improvement. The make/ninja load average limit is in but it's not clear if it's effective yet and it breaks dunfell. Trevor investigating. There's not much new this week, I've commented on a few existing activities below and added "Aug 5" in most cases. We did talk about the YP SWAT process and trying to get people to all follow the same workflow and for the people who are working on reporting and analysis tools to understand what SWAT does. Alex is going to think about it and come up with a plan. If anyone wants to help, we could use more eyes on the logs, particularly the summary logs and understanding iostat # when the dd test times out. I moved Michael to BCC here and I'll drop him next week unless asked to do otherwise. Plans for the week: =================== All: Wait and see if the ptest failure rate continues to be lower than previous weeks. Richard: Alex: SWAT plans. Sakib: hook more responsive load average in to latency test. (v3) Trevor: patch to set PARALLEL_MAKE : -l 50 -> dunfell, gatesgarth, hardknott (Aug 5 - it's a priority) Investigate dunfell which failed with this change. Tony: Saul: Randy: Look at performance data Meeting Notes: ============== 1. job server - ninja could be patched with make's more responsive algorithm next or is this good enough? - Richard suggested that we extract make's code for measuring the load average to a separate binary and run it in the periodic io latency test. Also can we translate it to python? - Trevor is working on this and had some problems so next week. 2. AB status Trevor is learning about buildbot and working on a scheduling bug (CentOS worker?) bitbake layer setup tool should allow multiple backends: eg: kas, a y-a-helper. ptest cases are improving, we may be close to done! Let's wait a week to see how things go. (July29, Aug 5, we're not done...) - development week with lots of failures and a-quick builds so it's hard to say. - lttng timeouts are still happening so RP is going to increase timeout for all ptests from 300, 450. (Aug 5, timeout bumped) 3. Sakib's improvements to the logging are merged. Sakib generated a summary of all high latency 'top' logs from ~July 23->July 29 by just running his summary script on the merged raw top logs. <snip last week's summary of summaries text> More analysis required.... Still relevant parts of Previous Meeting Notes: ======================= 4. bitbake server timeout ( no change july 29) "Timeout while waiting for a reply from the bitbake server (60s)" Clearly the YP ABs aren't running in docker but what about firmware and kernel tunings. 5. io stalls (no update: July 29) Richard said that it would make sense to write an ftrace utility / script to monitor io latency and we could install it with sudo Ch^W mentioned ftrace on IRC. Sakib and Randy will work on that but not for a week or two. ../Randy
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
linux-hotplug recipe
Mike
I'm new to yocto so forgive me if this has been answered before. I searched a number of resources and wasn't able to find an answer. I've been able to install yocto and make modifications to the bblayers.conf and local.conf files to add recipes and layers that provide recipes for the components I need. I wanted to add hotplug and found there is a "meta package" from yocto called "linux-hotplug". The problem I'm having is finding out which layer provides that recipe. Can someone point me in the right direction and/or point me at a tool that allows searching through all recipes, configured for use or not, for recipes. I've used oe-pkgutils-tool and bitbake-layers but, as far as I can tell they only search in layers configured to be used. I also tried the layer search tool on the open embedded website but got no hits for the aforementioned recipe. I feel like I'm missing something here but I don't know what. Any help would be appreciated. Thanks to all.
Mike
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
How does one add do_fetch, do_unpack to an image recipe?
John Klug
I am using dunfell.
In the documentation I see: https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#unsetting-variables In case some filter removes the yocto URL, I am referring to: docs/current/bitbake-user-manual/bitbake-user-manual.html#unsetting-variables Which has this example: unset do_fetch[noexec] If I put this in my image recipe, the do_fetch noexec item still exists. In order to fix this problem I had to patch openembedded-core/meta/classes/image.bbclass, and remove the line setting do_fetch[noexec]="1" and the ones following. I need to do a fetch for my IMAGE_POSTPROCESS_COMMAND. Thanks.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[meta-rockchip][PATCH] rockchip-gpt-img: fix for new override syntax
Trevor Woerner
It looks like I missed a case for the new bitbake override syntax. My tests
weren't done from a fresh build so either a preexisting image was still available, or the unfixed syntax caused a race. Signed-off-by: Trevor Woerner <twoerner@gmail.com> --- classes/rockchip-gpt-img.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/classes/rockchip-gpt-img.bbclass b/classes/rockchip-gpt-img.bbclass index 434c100..b698db0 100644 --- a/classes/rockchip-gpt-img.bbclass +++ b/classes/rockchip-gpt-img.bbclass @@ -9,7 +9,7 @@ IMG_ROOTFS_TYPE = "ext4" IMG_ROOTFS = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${IMG_ROOTFS_TYPE}" # This image depends on the rootfs image -IMAGE_TYPEDEP_rockchip-gpt-img = "${IMG_ROOTFS_TYPE}" +IMAGE_TYPEDEP:rockchip-gpt-img = "${IMG_ROOTFS_TYPE}" GPTIMG = "${IMAGE_NAME}-gpt.img" GPTIMG_SYMLK = "${IMAGE_BASENAME}-${MACHINE}-gpt.img" -- 2.30.0.rc0
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: [meta-openssl102][PATCH 1/2] layer.conf: add honister to LAYERSERIES_COMPAT
Mark Hatle
I'll get this staged later today.
toggle quoted messageShow quoted text
Thanks for running the conversion.
On 8/6/21 2:09 AM, Yi Zhao wrote:
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|