[yocto] how to intelligently avoid OOM build errors with BB_PRESSURE_MAX_MEMORY?
a colleague is using Wind River Linux and is getting occasional OOM
errors when taking advantage of maximum parallelism, so he took the
quick way out and dialed things back using BB_NUMBER_THREADS and
PARALLEL_MAKE.
however, i am aware of the bitbake variables
BB_PRESSURE_MAX_{IO,CPU,MEMORY} and was wondering if there is a decent
writeup on how to use, perhaps, BB_PRESSURE_MAX_MEMORY, to dynamically
detect imminent OOM and adjust things. that is, how to calculate a
sane value for that as i haven't yet dug into the values under
/proc/pressure and how to interpret them?
i've seen mentions of combining the above with the "memstat"
command, and other approaches. thoughts?
rday
p.s. is there a docs page that expands on this stuff?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61771): https://lists.yoctoproject.org/g/yocto/message/61771
Mute This Topic: https://lists.yoctoproject.org/mt/102868689/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] example where "RDEPENDS" is including a "virtual/" run-time dependency
while the dev manual insists that "virtual/" dependencies are only
for build-time deps and not run-time deps, i ran across this example
on the meta-intel master branch, under
dynamic-layers/openembedded-layer/recipes-oneapi/ (blank lines added
for clarity):
$ grep -r "RDEPENDS.*virtual/" *
compiler/intel-oneapi-compiler_2023.0.0-25370.bb:RDEPENDS:${PN} +=
"perl elfutils virtual/opencl-icd level-zero-loader zlib tbb libelf
setup-intel-oneapi-env"
dpcpp-compiler/intel-oneapi-dpcpp-cpp-runtime_2023.1.0-46305.bb:RDEPENDS:${PN}
+= "virtual/opencl-icd zlib tbb level-zero-loader bash tcsh"
mkl/intel-oneapi-mkl_2023.0.0-25398.bb:RDEPENDS:${PN} += "bash tbb
intel-oneapi-compiler setup-intel-oneapi-env virtual/opencl-icd"
i have no opinion on it, just observing that it seems to fly in the
face of the rules laid down in the dev manual:
https://docs.yoctoproject.org/dev-manual/new-recipe.html#using-virtual-providers
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61374): https://lists.yoctoproject.org/g/yocto/message/61374
Mute This Topic: https://lists.yoctoproject.org/mt/102015778/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in a YP riscv mailing list?
On 2023-10-13 11:14, Ross Burton wrote: On 13 Oct 2023, at 15:20, Robert P. J. Day via lists.yoctoproject.org wrote: given that other acrhitectures have their own ML, is it reasonable that risc-v have its own mailing list? meta-arm, meta-intel etc are primarily because they take patches via the mailing list. meta-riscv (https://github.com/riscv/meta-riscv) does pull requests and issues via GitHub. If the yocto@ list ended up getting swamped with riscv-specific discussion then there’s be a case for creating a list, but architecture-specific discussion is rare. understood. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61339): https://lists.yoctoproject.org/g/yocto/message/61339 Mute This Topic: https://lists.yoctoproject.org/mt/101940855/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] any interest in a YP riscv mailing list?
given that other acrhitectures have their own ML, is it reasonable that risc-v have its own mailing list? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61333): https://lists.yoctoproject.org/g/yocto/message/61333 Mute This Topic: https://lists.yoctoproject.org/mt/101940855/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] are there any plans for a RISC-V reference board?
On Fri, 13 Oct 2023, Alexander Kanavin wrote: > Can you clarify please what LTS means here? > > Alex > > On Fri 13. Oct 2023 at 9.09, Robert P. J. Day wrote: > On Tue, 10 Oct 2023, Josef Holzmayr wrote: > > > Hi Robert, > > > It has been discussed at numerous occasions. The main blocker is: we > > need a commitment for the maintenance. So if a high-ranking member > > decides to push forwards with this and allocate resources, or a new > > member from the RISC-V ecosystem steps up to make it happen, then > > the project is all ears. > > > > Greetz, > > Josef > > Ask and ye shall receive. I just got the following private note > from jiaqi.d...@starfivetech.com, who obviously saw my earlier post > (and agreed to let me reproduce his response to me to the list): > > > I think VisionFive 2 is an appropriate reference board. We offer > > Long Term Support for JH7110 and VisionFive 2. After being upgraded, > > VisionFive 2 with big improvements in the processor work frequency, > > multimedia processing capabilities, and scalability. Since August of > > last year, we have continued to promote the ecosystem of VF2, it has > > successively adapted to Deepin OS, Ubuntu OS, UEFI EDK2, OpenWrt, > > PPSSPP…you can check out the RVspace forum. So we would like to work > > with the developers and provide LTS if there are specific project > > requirements. I don't know, this is just the email I got from someone at StarFive who considered me the right contact person because I asked the question in the first place. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61329): https://lists.yoctoproject.org/g/yocto/message/61329 Mute This Topic: https://lists.yoctoproject.org/mt/101869785/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] are there any plans for a RISC-V reference board?
On Tue, 10 Oct 2023, Josef Holzmayr wrote: > Hi Robert, > It has been discussed at numerous occasions. The main blocker is: we > need a commitment for the maintenance. So if a high-ranking member > decides to push forwards with this and allocate resources, or a new > member from the RISC-V ecosystem steps up to make it happen, then > the project is all ears. > > Greetz, > Josef Ask and ye shall receive. I just got the following private note from jiaqi.d...@starfivetech.com, who obviously saw my earlier post (and agreed to let me reproduce his response to me to the list): > I think VisionFive 2 is an appropriate reference board. We offer > Long Term Support for JH7110 and VisionFive 2. After being upgraded, > VisionFive 2 with big improvements in the processor work frequency, > multimedia processing capabilities, and scalability. Since August of > last year, we have continued to promote the ecosystem of VF2, it has > successively adapted to Deepin OS, Ubuntu OS, UEFI EDK2, OpenWrt, > PPSSPP…you can check out the RVspace forum. So we would like to work > with the developers and provide LTS if there are specific project > requirements. Sound promising? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61327): https://lists.yoctoproject.org/g/yocto/message/61327 Mute This Topic: https://lists.yoctoproject.org/mt/101869785/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Sovereign Tech Fund Boosts Yocto Project
cool ... https://www.linuxfoundation.org/blog/sovereign-tech-fund-boosts-yocto-project rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61301): https://lists.yoctoproject.org/g/yocto/message/61301 Mute This Topic: https://lists.yoctoproject.org/mt/101872860/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] are there any plans for a RISC-V reference board?
at some point, will there be a poky (meta-yocto-bsp) RISC-V reference board? i'm thinking the Nezha Allwinner D1 (which is already supported in meta-riscv) would be a safe choice. or maybe the more powerful VisionFive 2? thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61297): https://lists.yoctoproject.org/g/yocto/message/61297 Mute This Topic: https://lists.yoctoproject.org/mt/101869785/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] meta-riscv layer *seems* to have broken opensbi_%.bbappend file
the SRC_URI line: SRC_URI:append:nezha = " \ ... seems odd since the machine name is actually "nezha-allwinner-d1", not just "nezha". i checked and the two listed patches there don't appear to be applied, for what i assume is just that reason. or is this somehow related to the "nezha.yml" file in the meta-riscv layer? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57488): https://lists.yoctoproject.org/g/yocto/message/57488 Mute This Topic: https://lists.yoctoproject.org/mt/92288014/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] meta-riscv: building curl, "undefined reference to '__atomic_exchange_1'
On Thu, 7 Jul 2022, Khem Raj wrote: > On Thu, Jul 7, 2022 at 1:06 PM Robert P. J. Day wrote: > > > > On Thu, 7 Jul 2022, Khem Raj wrote: > > > > > On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day > > > wrote: > > > > > > > > On Thu, 7 Jul 2022, Robert P. J. Day wrote: > > > > > > > > > > > > > on admittedly unsupported ubuntu 22.04 platform but it's clear this > > > > > is a known issue as it's pretty much identical to what one reads here: > > > > > > > > > > https://github.com/advancedtelematic/aktualizr/issues/1427 > > > > > > > > > > the explanation being that, "not every atomic operation is currently > > > > > supported by GCC on RISC-V." > > > > > > > > > > oddly, building a riscv64 core-image-minimal once upon a time on > > > > > fedora worked just fine, so i'm assuming a difference in gcc versions > > > > > is what is causing this. > > > > > > > > > > what is the recommended workaround for this? > > > > > > > > another data point, matches exactly what i'm referring to: > > > > > > > > https://github.com/curl/curl/issues/9055 > > > > > > > > > > does backporting > > > > > > https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2 > > > > > > to curl help ? > > > > as i read it, this issue is also related to -pthread versus > > -lpthread: > > > > this would mean that you want to rely on side effects of -pthread > which may work with gcc but may not > work with clang or other compiler drivers. The issue you have is that > some variables are needing atomics > and solution is either you link with libatomic or avoid using the code > which needs them > > > https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/ so while i'm still trying to wrap my head around all this, what *would* be the ideal resolution for this? the link above suggests the simple solution of introducing a gcc config option "--always-link-libatomic". would that solve all this in a general way, not just for RISC-V? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57478): https://lists.yoctoproject.org/g/yocto/message/57478 Mute This Topic: https://lists.yoctoproject.org/mt/92225230/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] meta-riscv: building curl, "undefined reference to '__atomic_exchange_1'
On Thu, 7 Jul 2022, Khem Raj wrote: > On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day wrote: > > > > On Thu, 7 Jul 2022, Robert P. J. Day wrote: > > > > > > > on admittedly unsupported ubuntu 22.04 platform but it's clear this > > > is a known issue as it's pretty much identical to what one reads here: > > > > > > https://github.com/advancedtelematic/aktualizr/issues/1427 > > > > > > the explanation being that, "not every atomic operation is currently > > > supported by GCC on RISC-V." > > > > > > oddly, building a riscv64 core-image-minimal once upon a time on > > > fedora worked just fine, so i'm assuming a difference in gcc versions > > > is what is causing this. > > > > > > what is the recommended workaround for this? > > > > another data point, matches exactly what i'm referring to: > > > > https://github.com/curl/curl/issues/9055 > > > > does backporting > > https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2 > > to curl help ? as i read it, this issue is also related to -pthread versus -lpthread: https://blog.jiejiss.com/A-RISC-V-gcc-pitfall-revealed-by-a-glibc-update/ rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57476): https://lists.yoctoproject.org/g/yocto/message/57476 Mute This Topic: https://lists.yoctoproject.org/mt/92225230/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] meta-riscv: building curl, "undefined reference to '__atomic_exchange_1'
On Thu, 7 Jul 2022, Khem Raj wrote: > On Thu, Jul 7, 2022 at 6:14 AM Robert P. J. Day wrote: > > > > On Thu, 7 Jul 2022, Robert P. J. Day wrote: > > > > > > > on admittedly unsupported ubuntu 22.04 platform but it's clear this > > > is a known issue as it's pretty much identical to what one reads here: > > > > > > https://github.com/advancedtelematic/aktualizr/issues/1427 > > > > > > the explanation being that, "not every atomic operation is currently > > > supported by GCC on RISC-V." > > > > > > oddly, building a riscv64 core-image-minimal once upon a time on > > > fedora worked just fine, so i'm assuming a difference in gcc versions > > > is what is causing this. > > > > > > what is the recommended workaround for this? > > > > another data point, matches exactly what i'm referring to: > > > > https://github.com/curl/curl/issues/9055 > > > > does backporting > > https://github.com/curl/curl/commit/50efb0822aa0e0ab165158dd0a26e65a2290e6d2 > > to curl help ? it does indeed fix the curl build error, thanks. i haven't tested its operation yet, but getting a build was all i was after at the moment. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57473): https://lists.yoctoproject.org/g/yocto/message/57473 Mute This Topic: https://lists.yoctoproject.org/mt/92225230/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] meta-riscv: building curl, "undefined reference to '__atomic_exchange_1'
On Thu, 7 Jul 2022, Robert P. J. Day wrote: > on admittedly unsupported ubuntu 22.04 platform but it's clear this > is a known issue as it's pretty much identical to what one reads here: > > https://github.com/advancedtelematic/aktualizr/issues/1427 > > the explanation being that, "not every atomic operation is currently > supported by GCC on RISC-V." > > oddly, building a riscv64 core-image-minimal once upon a time on > fedora worked just fine, so i'm assuming a difference in gcc versions > is what is causing this. > > what is the recommended workaround for this? another data point, matches exactly what i'm referring to: https://github.com/curl/curl/issues/9055 rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57470): https://lists.yoctoproject.org/g/yocto/message/57470 Mute This Topic: https://lists.yoctoproject.org/mt/92225230/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] meta-riscv: building curl, "undefined reference to '__atomic_exchange_1'
on admittedly unsupported ubuntu 22.04 platform but it's clear this is a known issue as it's pretty much identical to what one reads here: https://github.com/advancedtelematic/aktualizr/issues/1427 the explanation being that, "not every atomic operation is currently supported by GCC on RISC-V." oddly, building a riscv64 core-image-minimal once upon a time on fedora worked just fine, so i'm assuming a difference in gcc versions is what is causing this. what is the recommended workaround for this? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57469): https://lists.yoctoproject.org/g/yocto/message/57469 Mute This Topic: https://lists.yoctoproject.org/mt/92225230/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] looking to build meta-riscv based HDMI image for nezha board
after finally unpacking my risc-v nezha SBC, i'm trying to download/build an image that will boot to a desktop with as little effort as possible. that is, given this board, i would prefer to do no more than: * flash appropriate image to micro SD and insert * connect HDMI port to monitor * power up i don't want to connect ethernet, don't want debug port, don't even want to connect USB mouse or keyboard ... with just what i've listed above, i'd like to see the end result on the monitor. the image that comes with the board apparently defaults to the MIPI DSI display, so that doesn't help. i've set up all of the meta-riscv (and other) layers to build an image, so is there an image that will give me the above? or am i overlooking something critical? thanks. rday p.s. a downloadable image from somewhere (not even YP-based) just to prove this scenario works would be helpful as well. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57269): https://lists.yoctoproject.org/g/yocto/message/57269 Mute This Topic: https://lists.yoctoproject.org/mt/91556194/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] what's the situation with yocto support for qualcomm qcs{410,610} eval boards?
colleague just asked if i had any useful advice (spoiler: no) on how easy it would be to build a yocto-based image for *some* qcs410-based eval board. i'm familiar with meta-qcom, and machine definitions for dragonboards, but this is clearly(?) different, and i see nothing in the meta-qcom layer for this. what i see is that qualcomm supplies a linux sdk, and i quote from https://linuxgizmos.com/module-and-dev-kit-run-linux-on-qcs610-camera-soc/: "A Linux SDK is built on Yocto Thud with Linux kernel 4.1.4. The SDK integrates Qualcomm optimizations, GStreamer wth RTSP streaming support, and AI support for TensorFlow Lite and Qualcomm SNPE. Android 10 support is coming later." the more i read in the last half hour, the more it seems that one needs to bury oneself in qualcomm SDK, and repo-based checkouts from codeaurora and so on. is this the way to go? or have i missed something? colleague has some freedom in choice of qcs410-based eval board, if that makes things easier. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57139): https://lists.yoctoproject.org/g/yocto/message/57139 Mute This Topic: https://lists.yoctoproject.org/mt/91216262/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] simple YP layer to add "snaps" to a YP build
these days, i'm hip-deep in canonical stuff, working with ubuntu core and snaps (boo! hiss! oh, relax ... :-), and i chanced across a somewhat-neglected layer that supports adding snaps to a basic YP build, so i forked a copy, tidied it up, and verified that i can build a core-image-minimal for qemux86-64 that supports adding and running your basic "hello, world" snap. here's my current version of the layer (branch snapd-2.55.3, soon to be updated to snapd-2.55.5 as soon as this current build finishes and runs): https://github.com/rpjday/meta-snapd/tree/snapd-2.55.3 the README there needs to be cleaned up as much of that is no longer necessary, since i added a "snapd_on_yp" DISTRO that centralizes much of the essential config settings. so if you wanted to play with adding snaps to your established YP build, give it a try. still lots of tidying up to do, but it seems to work. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57122): https://lists.yoctoproject.org/g/yocto/message/57122 Mute This Topic: https://lists.yoctoproject.org/mt/91160342/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] is there already online the YP summit "hands-on setup"?
On Mon, 16 May 2022, Nicolas Dechesne wrote: > On Mon, May 16, 2022 at 2:17 PM Robert P. J. Day > wrote: > > i note that one of the first sessions is 15 minutes of "A session to > help people setup their Digital Ocean account." would this lab already > be online somewhere so people can do this ahead of time to make sure > nothing goes wrong? > > No , we are using a different cloud provider / partner this time. > That requires all the 'students' to have a valid account with our > partner (Digital Ocean), and all the hands on will be done using DO > cloud instances. All registered 'students' will get credits on their > Digital Ocean accounts for the duration of our event. This first > session is to make sure everyone is all set up with their account > before we start the hands on. so just to be clear, one need do nothing related to digital ocean in advance, it will all be done in that 15-minute setup session? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57111): https://lists.yoctoproject.org/g/yocto/message/57111 Mute This Topic: https://lists.yoctoproject.org/mt/91138090/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] is there already online the YP summit "hands-on setup"?
i note that one of the first sessions is 15 minutes of "A session to help people setup their Digital Ocean account." would this lab already be online somewhere so people can do this ahead of time to make sure nothing goes wrong? rday https://pretalx.com/yocto-project-summit-2022-05/talk/URUNLG/ -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57109): https://lists.yoctoproject.org/g/yocto/message/57109 Mute This Topic: https://lists.yoctoproject.org/mt/91138090/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] a waitlist for YP summit 2022.05?
On Mon, 16 May 2022, Nicolas Dechesne wrote: > On Mon, May 16, 2022 at 11:29 AM Nicolas Dechesne > wrote: > hey Robert, > > On Mon, May 16, 2022 at 11:27 AM Robert P. J. Day > wrote: > > given that i freed up my schedule for the upcoming week, i zipped > over to register for this week's yp virtual summit, but was told i was > being placed on a wait list. a wait list for a virtual summit? is > there a limit being put on registrations due to technical limitations > or something? seems odd. > > > It is odd. And it was not expected. We are aware of the issue, and > have reached out to LF Events team and asked for help. > > > The problem is fixed now. You should be able to register again! > Sorry about that. yup, all good, thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57108): https://lists.yoctoproject.org/g/yocto/message/57108 Mute This Topic: https://lists.yoctoproject.org/mt/91136063/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] a waitlist for YP summit 2022.05?
given that i freed up my schedule for the upcoming week, i zipped over to register for this week's yp virtual summit, but was told i was being placed on a wait list. a wait list for a virtual summit? is there a limit being put on registrations due to technical limitations or something? seems odd. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57104): https://lists.yoctoproject.org/g/yocto/message/57104 Mute This Topic: https://lists.yoctoproject.org/mt/91136063/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] are there any plans for meta-riscv support for StarFive VisionFive?
On Thu, 12 May 2022, Khem Raj wrote: > On Thu, May 12, 2022 at 2:00 AM Robert P. J. Day > wrote: > > > https://shop.allnetchina.cn/products/starfive-visionfive-ai-single-board-computer?variant=39522167783526 > > > Yes There already is beagleV machine and it will be derived from > that I have plans to add it if Someone is working on it please let > me know not working on the machine definition myself, but have already ordered one of those boards so certainly willing to test once it arrives. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57081): https://lists.yoctoproject.org/g/yocto/message/57081 Mute This Topic: https://lists.yoctoproject.org/mt/91054159/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] are there any plans for meta-riscv support for StarFive VisionFive?
https://shop.allnetchina.cn/products/starfive-visionfive-ai-single-board-computer?variant=39522167783526 rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57063): https://lists.yoctoproject.org/g/yocto/message/57063 Mute This Topic: https://lists.yoctoproject.org/mt/91054159/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] looking to boot core-image-minimal on meta-riscv board
On Fri, 25 Feb 2022, Khem Raj wrote: > On Fri, Feb 25, 2022 at 8:36 AM Robert P. J. Day > wrote: > > > > > > a friend of mine is diving into trying to boot linux on a meta-riscv > > linux starter kit -- he's not using YP, and this is what he's > > targeting: > > > > https://www.aliexpress.com/item/1005003751298305.html > > > > since i've wanted to jump into meta-riscv for a while, i figured i'd > > play along and ordered something more substantial: > > > > https://www.aliexpress.com/item/1005002796061251.html > > > > in any event, here's the story so far. > > > > as a first pass, i just fired up YP and built for qemuriscv64 to > > establish a baseline, and that seems to work just fine, booting with > > "runqemu nographic." and that at least gives me a bunch of config info > > i can look at later. > > > > as for my actual target board, i know that the meta-riscv layer > > defines support for two boards, neither of which is the one i will be > > getting, but while i'm waiting for it, i can at least start > > documenting all of the relevant settings and config values i'll want > > to try. > > > > i know precious little about meta-riscv, so is there a sane way to > > prepare for the eventual arrival of my board? my plan is to get > > familiar with how the meta-riscv layer builds for the two supported > > boards, so i'll have a handle on what i'll need to configure. > > > > any further advice would be most appreciated. > > We should add them to meta-riscv as reference BSPs. I have port of > unmatched locally and have been trying to get the needed changes > into meta-sifive which is still pending. so you have working BSPs for both of those? very cool. warning that i know effectively nothing about RISC-V but this is apparently my weekend project to dig into it. i don't see a meta-riscv-specific mailing list, so i assume if i want to start sending simple patches for meta-riscv, they would go here? already built and tested qemuriscv64, so i guess i'll work backwards from there and examine the configuration and construction of the components. opensbi, here we come ... rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56292): https://lists.yoctoproject.org/g/yocto/message/56292 Mute This Topic: https://lists.yoctoproject.org/mt/89391983/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] looking to boot core-image-minimal on meta-riscv board
a friend of mine is diving into trying to boot linux on a meta-riscv linux starter kit -- he's not using YP, and this is what he's targeting: https://www.aliexpress.com/item/1005003751298305.html since i've wanted to jump into meta-riscv for a while, i figured i'd play along and ordered something more substantial: https://www.aliexpress.com/item/1005002796061251.html in any event, here's the story so far. as a first pass, i just fired up YP and built for qemuriscv64 to establish a baseline, and that seems to work just fine, booting with "runqemu nographic." and that at least gives me a bunch of config info i can look at later. as for my actual target board, i know that the meta-riscv layer defines support for two boards, neither of which is the one i will be getting, but while i'm waiting for it, i can at least start documenting all of the relevant settings and config values i'll want to try. i know precious little about meta-riscv, so is there a sane way to prepare for the eventual arrival of my board? my plan is to get familiar with how the meta-riscv layer builds for the two supported boards, so i'll have a handle on what i'll need to configure. any further advice would be most appreciated. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56283): https://lists.yoctoproject.org/g/yocto/message/56283 Mute This Topic: https://lists.yoctoproject.org/mt/89391983/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] is there a viable YP-friendly risc-v dev kit?
Quoting Leon Woestenberg : Hello Robert, Alexander, On Fri, 4 Feb 2022 at 23:04, Robert P. J. Day wrote: Quoting Alexander Kanavin : > I think the best option at this point is qemu. Why does the 'friend' need > physical hardware? :) he's a hacker and just likes the feel of circuit boards, but qemu does look like the only feasible option at the moment. No. There is a sweet middle ground called FPGAs. You buy a board, with an IC on it, that is expensive as hell, empty like air, but fully re-configurable with almost any RISC-V SoC you can think of. For example the Rocket 64 bit RISC-V. hmmm ... not even that expensive a board: https://www.luffca.com/2021/09/linux-litex-rocket-arty/ https://www.xilinx.com/products/boards-and-kits/1-elhaap.html rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56082): https://lists.yoctoproject.org/g/yocto/message/56082 Mute This Topic: https://lists.yoctoproject.org/mt/88917825/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] is there a viable YP-friendly risc-v dev kit?
Quoting Alexander Kanavin : I think the best option at this point is qemu. Why does the 'friend' need physical hardware? :) he's a hacker and just likes the feel of circuit boards, but qemu does look like the only feasible option at the moment. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56080): https://lists.yoctoproject.org/g/yocto/message/56080 Mute This Topic: https://lists.yoctoproject.org/mt/88917825/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] is there a viable YP-friendly risc-v dev kit?
friend asked me about the options for a risc-v dev kit that worked with YP, and i'm aware of the meta-riscv layer, but wherever i looked, it seems like risc-v dev kits have a very short life span, being either put on hold or outright cancelled (beaglev, hifive unmatched, etc.) are there, in fact, any reasonable risc-v dev boards out there? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56078): https://lists.yoctoproject.org/g/yocto/message/56078 Mute This Topic: https://lists.yoctoproject.org/mt/88917825/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] bbappend usage
On Mon, 25 Oct 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote: > If I am building an image “image-ABC”, and it is composed of a > number recipes, and for some of these recipes I may NOT want to > install their final components within my image… > > Which is the best place to modify the build with bbappend ? > > Would I modify a recipe’s do_install (do_install_append-recipe_xyz) > ?, or would I modify the image recipe (do_install_append-image_ABC) > I am leaning this way to avoid cases where the component recipes > might have bbappends in place already ? i would think start with defining a minimal image, then define other images based on that one which add more recipes. this has nothing to do with redefining the recipes, it just means defining more than one image. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#55137): https://lists.yoctoproject.org/g/yocto/message/55137 Mute This Topic: https://lists.yoctoproject.org/mt/86576092/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] what's the state of things with pushing the bounds on ASSUME_PROVIDED?
i asked about this once upon a time, so i thought i'd follow up ... given the fairly stable state of recent linux distros, is there any standard for taking advantage of what *should* be robust native tools rather than building them? (i'm ignoring taking advantage of sstate and building SDKs and other clever speedups for now.) from scratch, i did a wind river (LINCD) build of wrlinux-image-small (and i assume it would be much the same under current oe-core), and i notice that numerous native tools were compiled, including such standards as cmake, curl, elfutils ... the list goes on and on. so other than the tools that are *required* to be installed, if i mention that i am currently running ubuntu 20.04, is there any indication as to which tools i'm relatively safe to take advantage using ASSUME_PROVIDED and HOSTTOOLS? i realize that the versions built will probably differ from the host versions, but it seems that if there is an incompatibility, that would be fairly obvious in short order. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53963): https://lists.yoctoproject.org/g/yocto/message/53963 Mute This Topic: https://lists.yoctoproject.org/mt/83758672/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] the downside of parallelism
On Sun, 20 Jun 2021, Robert ber...@yocto.user wrote: > Hi, > > On 20/06/2021 12:55, Robert P. J. Day wrote: > > > >refactoring existing (legacy) code base into more bite-sized > > bitbake recipes to speed up build by taking advantage of 6-core > > (12-thread) dell laptop ... end result is that i get so much > > parallelism that laptop shuts down from overheating. > > Sorry for my stupid question;) > > If you have 12 threads, it's 12 threads and not more. > > I guess there needs to be some kind of dependency between your new recipes. > > make -j can use as many cores as you like even with a single recipe. > > How would it speed up builds if you break up a recipe into multiple recipes? > > What is your refactoring approach? the (legacy) code base i was handed involves several sizable makefiles that were not designed to take advantage of parallelism -- apparently, they come from an environment (QNX?) where "make" does not do parallelism. so rather than design makefiles with parallelism in mind, many of the makefiles correspond to some large subsystem where the top-level target has a rule that simply descends into the numerous sub-component directories one at a time: fubar: $(MAKE) -C fubar1 $(MAKE) -C fubar2 ... $(MAKE) -C fubar42 and last i heard, the commands in any rule are definitely processed serially. so when the local folks started transmogrifying the code base to use YP, they just used SRC_URI to point at the existing makefiles (which *must* stay where they are for the purpose of legacy compatibility). so as a start, there is a recipe "fubar.bb" which just runs that top-level Makefile, but given its structure, once it starts, all you see is "fubar compiling" as it serially processes all of its subcomponents. now, most of the major components have sub-directories with, say, the shared libs, the test suite, and so on, and a lot of other components that allegedly DEPENDS on "fubar" obviously don't need *all* of fubar to finish compiling, just normally the library sub-component, but as it is, they have to wait for all of it, so you normally see "fubar compiling", and nothing else, for several minutes, and as soon as that finishes, a bunch of deps that have been patiently waiting finally kick off. as i refactor the above into smaller recipes, then the dependencies build much faster and as soon as the shared lib recipe finishes, all those other recipes can start, so i'm definitely getting way more parallelism but, as i mentioned, that comes with a price. now, given my unlimited cleverness into refactoring recipes, most of my 6 cores (12 threads) are busy, which is driving up the load average over the course of the build (easily over an hour for the whole thing), and sometimes the load average peaks at over 130, and the air vent on this laptop is blowing air so hot, it can actually burn you if you leave your hand there too long, and every so often, it just locks up and shuts down. what irony -- i redesign the recipes to boost parallelism, only to fall victim to hardware limitations. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53931): https://lists.yoctoproject.org/g/yocto/message/53931 Mute This Topic: https://lists.yoctoproject.org/mt/83664460/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] the downside of parallelism
On Sun, 20 Jun 2021, Alexander Kanavin wrote: > This is hardly Yocto's fault: putting a 6 core CPU into a laptop > should be validated by saturating all cores for several hours and > ensuring the cooling and frequency throttling can handle it. Laptop > OEM is trying to be cheap I'd say. > > Alex i wasn't blaming yocto ... that was an attempt at wry humour. or possibly irony. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53921): https://lists.yoctoproject.org/g/yocto/message/53921 Mute This Topic: https://lists.yoctoproject.org/mt/83664460/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] the downside of parallelism
refactoring existing (legacy) code base into more bite-sized bitbake recipes to speed up build by taking advantage of 6-core (12-thread) dell laptop ... end result is that i get so much parallelism that laptop shuts down from overheating. le *sigh* ... rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53919): https://lists.yoctoproject.org/g/yocto/message/53919 Mute This Topic: https://lists.yoctoproject.org/mt/83664460/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] thoughts on YP-friendly developer laptop?
starting to think about a new laptop that will, among other things, do lots of OE/YP builds, and i'll start with this as the basis for a few questions about hard drives: https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e while an SSD would be delightful, i'm concerned about how doing frequent 40-50G builds would wear out an SSD. so i was considering looking for something with a fast regular HD for the actual build directories, but room to put in an M.2 NVMe that would hold fairly static content, like the OS itself, all the layers, a local source mirror and so on. am i overthinking this? anyone have a laptop setup that is smokin' fast (yeah, 8 core AMD ryzen :-), and a dual drive layout that seems to work well with lots and lots of OE builds? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53859): https://lists.yoctoproject.org/g/yocto/message/53859 Mute This Topic: https://lists.yoctoproject.org/mt/83528013/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
On Fri, 28 May 2021, Zoran wrote: > > Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf > > Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no > blank at the beginning)? > > Thank you, > Zee you don't want the leading space. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53692): https://lists.yoctoproject.org/g/yocto/message/53692 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/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] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
On Thu, 27 May 2021, sayinswa...@gmail.com wrote: > Hello Yocto team: > > I just started with yocto and would like to know the process for switching > the init > manager from systemd to sysvinit. > > I tried this options in config file > VIRTUAL-RUNTIME_init_manager = "busybox" > PREFERRED_PROVIDER_udev = "sysvinit" > PREFERRED_PROVIDER_udev-utils = "sysvinit" > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" > DEFAULT_DISTRO_FEATURES += " sysvinit" as i recall, all of the above can be replaced by a single assignment to the INIT_MANAGER variable. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53677): https://lists.yoctoproject.org/g/yocto/message/53677 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/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] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-security][PATCH] Correct "securiyt" typo in maintainers.inc
Signed-off-by: Robert P. J. Day --- diff --git a/conf/distro/include/maintainers.inc b/conf/distro/include/maintainers.inc index 7b82ef7..e02b903 100644 --- a/conf/distro/include/maintainers.inc +++ b/conf/distro/include/maintainers.inc @@ -1,4 +1,4 @@ -# meta-securiyt Maintainers File +# meta-security Maintainers File # # This file contains a list of recipe maintainers. # -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca LinkedIn: http://ca.linkedin.com/in/rpjday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53619): https://lists.yoctoproject.org/g/yocto/message/53619 Mute This Topic: https://lists.yoctoproject.org/mt/83035798/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] what OE/YP layers should be considered "supported"?
On Tue, 4 May 2021, akuster808 wrote: > Helllo Robert, > > On 5/4/21 2:03 PM, Robert P. J. Day wrote: > > related to something that richard purdie mentioned on the OE list, > > if one wanted to do a YP-wide "cleanup" of some indeterminate form, > > what are the layers that would be considered mandatory to cover in > > such a cleanup? > I don't have an context in the email you are referring to. Can you > include it please? Supported will mean different things to different > people. > > -Armin granted, that Q was a bit vague ... based on a suggestion of richard's, i was going to do an "audit" of OE/YP layers to see the effect of doing a particular minor cleanup, but it's not clear the requirement for wide-sweepingness that would represent a sufficient audit. would that necessarily cover every single layer identified at layers.openembedded.org? that seems a bit onerous. so is there some moderately vague definition of what constitutes a minimally representative collection of layers? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53386): https://lists.yoctoproject.org/g/yocto/message/53386 Mute This Topic: https://lists.yoctoproject.org/mt/82589884/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] what OE/YP layers should be considered "supported"?
related to something that richard purdie mentioned on the OE list, if one wanted to do a YP-wide "cleanup" of some indeterminate form, what are the layers that would be considered mandatory to cover in such a cleanup? no-brainers would, of course, include: * oe-core * meta-openembedded beyond that, what else? i would think: * meta-virtualization * meta-java * meta-security * ... more? ... and there are the vendor layers: * meta-intel * meta-freescale * meta-qcom * meta-boundary where can one stop? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53373): https://lists.yoctoproject.org/g/yocto/message/53373 Mute This Topic: https://lists.yoctoproject.org/mt/82589884/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] looking for a bit more info on licensing certain recipe files
On Tue, 4 May 2021, Quentin Schulz wrote: > On Tue, May 04, 2021 at 06:00:10AM -0400, Robert P. J. Day wrote: > > On Tue, 4 May 2021, Quentin Schulz wrote: > > > > > Hi Robert, > > > > > > On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote: > > > > > > > > for the first time, i'm digging around in the docs for how to > > > > properly license various types of recipes, so a couple simple > > > > questions to start with, at least so i can make a first pass of > > > > cleaning up some content in front of me. > > > > > > > > as we established recently, packagegroup files need no > > > > licensing, the obvious observation being that they represent the > > > > collection of licenses that comprise them. however, i notice that > > > > the packagegroup.bbclass file does indeed define a default > > > > license: > > > > > > > > LICENSE ?= "MIT" > > > > > > > > so not only does a packagegroup have a default (MIT) license, but > > > > it's conditional suggesting one could give it a different license. > > > > what other licenses would make sense for a packagegroup? I'm > > > > sticking with the default that packagegroup recipe files need no > > > > LICENSE assignment, but now i'm curious as to what other options > > > > there are (or perhaps that that default assignment in > > > > packagegroup.bbclass is obsolete). > > > > > > Wild guess: all packages need a license. MIT is quite permissive so > > > safe as a default? > > > > superficially makes sense, except that a packagegroup does not > > really define a "package". perhaps all *recipe* files need a license > > They do define packages. Empty packages, but still packages. Look into > deploy/ipk and search for *packagegroup*, you'll see some. > > It's probably a requirement/feature of package managers, so that you > install one package which has a dependency on many others, and the > latter are just pulled in by the package manager directly. > > > but, again, it's not clear how a packagegroup license should percolate > > down to the packages it contains. or how things would percolate up. > > > > It does not apply to packages it RDEPENDS on, it applies to the packages > created by the packagegroup recipe, each of them then RDEPENDS on other > packages (with potentially (and often) licensed differently). ah, now it makes sense, thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53358): https://lists.yoctoproject.org/g/yocto/message/53358 Mute This Topic: https://lists.yoctoproject.org/mt/82402742/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] looking for a bit more info on licensing certain recipe files
On Tue, 4 May 2021, Quentin Schulz wrote: > Hi Robert, > > On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote: > > > > for the first time, i'm digging around in the docs for how to > > properly license various types of recipes, so a couple simple > > questions to start with, at least so i can make a first pass of > > cleaning up some content in front of me. > > > > as we established recently, packagegroup files need no > > licensing, the obvious observation being that they represent the > > collection of licenses that comprise them. however, i notice that > > the packagegroup.bbclass file does indeed define a default > > license: > > > > LICENSE ?= "MIT" > > > > so not only does a packagegroup have a default (MIT) license, but > > it's conditional suggesting one could give it a different license. > > what other licenses would make sense for a packagegroup? I'm > > sticking with the default that packagegroup recipe files need no > > LICENSE assignment, but now i'm curious as to what other options > > there are (or perhaps that that default assignment in > > packagegroup.bbclass is obsolete). > > Wild guess: all packages need a license. MIT is quite permissive so > safe as a default? superficially makes sense, except that a packagegroup does not really define a "package". perhaps all *recipe* files need a license but, again, it's not clear how a packagegroup license should percolate down to the packages it contains. or how things would percolate up. suddenly, i want some coffee. > > the same sort of question can be asked about image files, > > including the generic OE core-image*.bb recipe files. of all those > > current core-image files: > > > > core-image-base.bb > > core-image-minimal.bb > > core-image-minimal-dev.bb > > core-image-minimal-initramfs.bb > > core-image-minimal-mtdutils.bb > > core-image-tiny-initramfs.bb > > > > fail into two camps. > > > > the first sets a license, then inherits core-image: > > > > LICENSE = "MIT" > > inherit core-image > > > > the second type simply "require"s one of the other recipe files so it > > has no need to set its own license, as in core-image-minimal-dev.bb: > > > > require core-image-minimal.bb > > > > similar to packagegroups, does a core-image recipe really need a > > separate LICENSE setting, or could that be added to core-image.bbclass > > to centralize it (if it's even needed at all)? > > > > Don't know about this one but I guess it's some rest of the original > implementation where I guess everything needed a LICENSE? > > I can only guess, but maybe this'll start a discussion :) > > > finally, WRT .bbappend files, the original recipes will have > > their own licenses and if the .bbappend file is doing nothing but > > adding some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE, > > that sort of thing), then there should be no need for licensing in > > the bbappend file. does all this sound reasonable so far? > > I wouldn't expect any bbappend to modify a package/recipe license > without changing the sources (version bump). But not much experience > with that, so might be a valid use case? i'm not *trying* to be overly pedantic (well, yeah, i am :-), but given the importance of licensing these days, i want to understand how they work far more than i do at the moment, especially since my new co-workers are asking me about them. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53356): https://lists.yoctoproject.org/g/yocto/message/53356 Mute This Topic: https://lists.yoctoproject.org/mt/82402742/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] any compelling reason to use SDK rather than eSDK?
colleague wants to get into working with SDKs, and as i'm just diving into the intricacies of that myself, i'm not sure how to answser the question: "is there any reason to use the regular SDK as opposed to the extensible SDK?" superficially, it would seem that the eSDK has nothing but benefits, so other than perhaps needing more resources, is there any reason to use the regular SDK and forego the benefits of eSDK? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53334): https://lists.yoctoproject.org/g/yocto/message/53334 Mute This Topic: https://lists.yoctoproject.org/mt/82477342/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] looking for a bit more info on licensing certain recipe files
for the first time, i'm digging around in the docs for how to properly license various types of recipes, so a couple simple questions to start with, at least so i can make a first pass of cleaning up some content in front of me. as we established recently, packagegroup files need no licensing, the obvious observation being that they represent the collection of licenses that comprise them. however, i notice that the packagegroup.bbclass file does indeed define a default license: LICENSE ?= "MIT" so not only does a packagegroup have a default (MIT) license, but it's conditional suggesting one could give it a different license. what other licenses would make sense for a packagegroup? I'm sticking with the default that packagegroup recipe files need no LICENSE assignment, but now i'm curious as to what other options there are (or perhaps that that default assignment in packagegroup.bbclass is obsolete). the same sort of question can be asked about image files, including the generic OE core-image*.bb recipe files. of all those current core-image files: core-image-base.bb core-image-minimal.bb core-image-minimal-dev.bb core-image-minimal-initramfs.bb core-image-minimal-mtdutils.bb core-image-tiny-initramfs.bb fail into two camps. the first sets a license, then inherits core-image: LICENSE = "MIT" inherit core-image the second type simply "require"s one of the other recipe files so it has no need to set its own license, as in core-image-minimal-dev.bb: require core-image-minimal.bb similar to packagegroups, does a core-image recipe really need a separate LICENSE setting, or could that be added to core-image.bbclass to centralize it (if it's even needed at all)? finally, WRT .bbappend files, the original recipes will have their own licenses and if the .bbappend file is doing nothing but adding some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE, that sort of thing), then there should be no need for licensing in the bbappend file. does all this sound reasonable so far? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53292): https://lists.yoctoproject.org/g/yocto/message/53292 Mute This Topic: https://lists.yoctoproject.org/mt/82402742/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] what to include in a "hardware bringup image"?
for a current project (and subsequent projects), i want to define a hardware bringup image; that is, a really basic image chock-full of low-level utilities for debugging initial board bringup. this means precious little unnecessary userspace crud that has no value in that context. (at the moment, the target is aarch64 but, naturally, the ideal image would be maximally applicable no matter the target.) i'm thinking of recipes that allow probing/configuration of memory and busses and that sort of thing. off the top of my head: * pciutils * usbutils * libgpiod * phytool (or other MDIO probe/debug tools) * devmem2 * spidev-test/spitools * i2c-tools the list can go on and on, and i just ran across this which i had never seen before: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/c-periphery/c-periphery_2.3.1.bb?h=master suggestions? i suspect numerous folks on this list have already done something like this. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53144): https://lists.yoctoproject.org/g/yocto/message/53144 Mute This Topic: https://lists.yoctoproject.org/mt/82112196/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] is there a *compelling* use case for "FILESEXTRAPATHS_append"?
over the years, i've always been uncomfortable with the admittedly small number of examples in various layers i've found that append to FILESEXTRAPATHS rather than prepend, so i'm curious if there is an actual, persuasive reason to ever do that. philosophically, when one uses FILESEXTRAPATHS_prepend, one is effectively saying, "here, use my content. nobody else's. mine. it's right here. you can see it." and there should be no ambiguity, of course. when you append, however, you're allowing for some hitherto unknown earlier layer to jump in and override some of your content. effectively, it seems (and i'm willing to be corrected) that you're saying, "i have some content that *could* be used, but if some earlier layer has the same content, we'll use that instead." that seems to open up a huge can of non-determinism, if an earlier layer suddenly introduces (or, conversely removes) content of the same name without you noticing, and weird things start to happen. so the question is, is there a really, well-defined use case for appending to this variable? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53023): https://lists.yoctoproject.org/g/yocto/message/53023 Mute This Topic: https://lists.yoctoproject.org/mt/81888470/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] does meta-virtualization layer have superfluous dynamic layers stuff?
just noticed this is meta-virt layer, file layer.conf:
# The dynamic-layers directory hosts extensions and layer-specific
# modifications.
#
# The .bbappend and .bb files are included if the respective layer
# collection is available.
BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bbappend' %
layer \
for layer in BBFILE_COLLECTIONS.split())}"
BBFILES += "${@' '.join('${LAYERDIR}/dynamic-layers/%s/recipes*/*/*.bb' % layer
\
for layer in BBFILE_COLLECTIONS.split())}"
BBFILES_DYNAMIC += " \
raspberrypi:${LAYERDIR}/dynamic-layers/raspberrypi/*/*/*.bb \
raspberrypi:${LAYERDIR}/dynamic-layers/rasbperrypi/*/*/*.bbappend \
xilinx:${LAYERDIR}/dynamic-layers/xilinx/*/*/*.bb \
xilinx:${LAYERDIR}/dynamic-layers/xilinx/*/*/*.bbappend \
"
i'm *assuming* that those first two assignments to BBFILES
represent the earlier technique for supporting dynamic layers,
otherwise i'm not sure what they're doing there. with the assignment
to BBFILES_DYNAMIC, is there any value to the earlier assignments?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53008): https://lists.yoctoproject.org/g/yocto/message/53008
Mute This Topic: https://lists.yoctoproject.org/mt/81829908/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] where is the definitive/canonical layer for TPM stuff?
i just noticed that both of the layers meta-secure-core and meta-security: https://github.com/jiazhang0/meta-secure-core https://git.yoctoproject.org/cgit/cgit.cgi/meta-security seem to include a good deal of TPM/TPM2 content ... is there a primary layer for that stuff? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53006): https://lists.yoctoproject.org/g/yocto/message/53006 Mute This Topic: https://lists.yoctoproject.org/mt/81812620/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] what is the state of upcoming(?) NXP S32G2xx support; layer, BSP?
i note that the linux-yocto repo has a nxp-s32g2xx branch: https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx so wondering about the subsequent BSP layer, from NXP or elsewhere. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52990): https://lists.yoctoproject.org/g/yocto/message/52990 Mute This Topic: https://lists.yoctoproject.org/mt/81761268/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] is there a recent explanation of tricks you can play with MACHINEOVERRIDES?
On Sat, 20 Mar 2021, Quentin Schulz wrote: > Hi Robert, > > On March 19, 2021 9:54:34 AM UTC, "Robert P. J. Day" > wrote: > > > > years ago, i asked about how to support a small set of > >closely-related targets using MACHINEOVERRIDES to define how to apply > >patches in a (somewhat) hierarchical fashion: > > > >https://www.yoctoproject.org/pipermail/yocto/2016-March/028922.html > > > > is there any current BSP that does something like that? and is this > >sort of thing worth expanding on and adding to one of the manuals? > > > > Don't use _prepend but =. BEFORE the other includes in your machine > configuration files otherwise the order in MACHINEOVERRIDES is > incorrect. Do NOT use append, or .=, they result in incorrect order > too. i did write that a while back while i was still figuring it out. :-) > I do use this mechanism because we kind of use Yocto machines the > wrong way (basically using machines instead of distros or more > complex images). > > I think NXP is making extensive use of this variable by defining a > MACHINEOVERRIDES per SoC families (e.g. imx:imx8:imx8mm). > > I'm not sure we need to explain all possible uses of OVERRIDES > variables, just how to set it and how it works. i agree that it would be inappropriate in the *regular* sections of the docs, but i'm convinced it would be worth explaining in some sort of "advanced features" section. after all, you just admitted that *you* use it, and that NXP uses it. that should be enough to justify explaining it *somewhere*, no? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52781): https://lists.yoctoproject.org/g/yocto/message/52781 Mute This Topic: https://lists.yoctoproject.org/mt/81451700/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] does current bitbaking of core-image-minimal still need docbook stuff?
On Fri, 19 Mar 2021, Mike Looijmans wrote: > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijm...@topicproducts.com > W: www.topic.nl > > Please consider the environment before printing this e-mail > On 19-03-2021 11:45, Robert P. J. Day via lists.yoctoproject.org wrote: > > On Fri, 19 Mar 2021, Nicolas Dechesne wrote: > > > >> On Fri, Mar 19, 2021 at 10:47 AM Robert P. J. Day > >> wrote: > >>> > >>>testing building qemuarm64 core-image-minimal from scratch, and > >>> noticed it fetching for docbook-xml and docbook-xsl stuff ... is there > >>> something that still needs docbook support? i'm about to take a quick > >>> look to see what's demanding that, does anyone know? > >> It's not related to yp-docs at least. most likely some recipes that > >> use docbook for their docs/man pages, no? > >most likely, but as i'm explicitly not installing any documentation, > > i'm now poking around to see what insists on building that for no > > apparent reason. > > > My favorite method for that is to just remove the recipe that provides it and > then see where it breaks... it appears (after a *very* cursory investigation) that shared-mime-info-native is included, which drags in xmlto-native, which then drags in docbook stuff. i'll confirm that later. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52777): https://lists.yoctoproject.org/g/yocto/message/52777 Mute This Topic: https://lists.yoctoproject.org/mt/81451648/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] does current bitbaking of core-image-minimal still need docbook stuff?
On Fri, 19 Mar 2021, Nicolas Dechesne wrote: > On Fri, Mar 19, 2021 at 10:47 AM Robert P. J. Day > wrote: > > > > > > testing building qemuarm64 core-image-minimal from scratch, and > > noticed it fetching for docbook-xml and docbook-xsl stuff ... is there > > something that still needs docbook support? i'm about to take a quick > > look to see what's demanding that, does anyone know? > > It's not related to yp-docs at least. most likely some recipes that > use docbook for their docs/man pages, no? most likely, but as i'm explicitly not installing any documentation, i'm now poking around to see what insists on building that for no apparent reason. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52775): https://lists.yoctoproject.org/g/yocto/message/52775 Mute This Topic: https://lists.yoctoproject.org/mt/81451648/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] is there a recent explanation of tricks you can play with MACHINEOVERRIDES?
years ago, i asked about how to support a small set of closely-related targets using MACHINEOVERRIDES to define how to apply patches in a (somewhat) hierarchical fashion: https://www.yoctoproject.org/pipermail/yocto/2016-March/028922.html is there any current BSP that does something like that? and is this sort of thing worth expanding on and adding to one of the manuals? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca LinkedIn: http://ca.linkedin.com/in/rpjday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52773): https://lists.yoctoproject.org/g/yocto/message/52773 Mute This Topic: https://lists.yoctoproject.org/mt/81451700/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] does current bitbaking of core-image-minimal still need docbook stuff?
testing building qemuarm64 core-image-minimal from scratch, and noticed it fetching for docbook-xml and docbook-xsl stuff ... is there something that still needs docbook support? i'm about to take a quick look to see what's demanding that, does anyone know? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52772): https://lists.yoctoproject.org/g/yocto/message/52772 Mute This Topic: https://lists.yoctoproject.org/mt/81451648/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Recipes and meta-data directory tree
On Wed, 17 Mar 2021, keydi wrote: > Two projects are given. They use different YP release each. > Projects use also different target platform each. ... snip ... > project B (YP release 2.0, actually backport of some later release you can't legitimately expect support for YP 2.0, which is six years old and has been EOLed for quite some time. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52749): https://lists.yoctoproject.org/g/yocto/message/52749 Mute This Topic: https://lists.yoctoproject.org/mt/81407654/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Building test code?
On Tue, 16 Mar 2021, jchludzinski via lists.yoctoproject.org wrote: > I tried to build spidev-test using the bitbake recipe: > > spidev-test.bb > > I set: > ARCH=arm > BBPATH > CROSS_COMPILER=arm-linux-gnueabihf- > PATH > > ... and then tried to build spidev-test: > > $ bitbake -b spidev-test.bb > WARNING: Buildfile specified, dependencies will not be handled. If this is > not what you want, do not use -b / --buildfile. > Loading cache: 100% > || Time: > 0:00:00 > Loaded 1433 entries from dependency cache. > > Build Configuration: > BB_VERSION = "1.49.2" > BUILD_SYS= "x86_64-linux" > NATIVELSBSTRING = "fedora-33" > TARGET_SYS = "x86_64-oe-linux" > MACHINE = "qemux86-64" > DISTRO = "nodistro" > DISTRO_VERSION = "nodistro.0" > TUNE_FEATURES= "m64 core2" > TARGET_FPU = "" > meta = "master:fa1e1fbc082e82e41ccfeae58af97fe048c9aac7" > > Initialising tasks: 100% > |###| Time: 0:00:00 > Sstate summary: Wanted 6 Local 0 Network 0 Missed 6 Current 0 (0% match, 0% > complete) > NOTE: Executing Tasks > WARNING: spidev-test-1.0-r0 do_populate_lic: Could not copy license file > /home/fedora/openembedded-core/meta/files/common-lic > enses/GPL-2.0 to > /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0-r0/license-destdir/s > pidev-test/GPL-2.0: [Errno 2] No such file or directory: > '/home/fedora/openembedded-core/meta/files/common-licenses/GPL-2.0' > ERROR: spidev-test-1.0-r0 do_populate_lic: QA Issue: spidev-test: > LIC_FILES_CHKSUM points to an invalid file: /home/fedora/op > enembedded-core/meta/files/common-licenses/GPL-2.0 [license-checksum] > ERROR: spidev-test-1.0-r0 do_populate_lic: Fatal QA errors found, failing > task. > ERROR: Logfile of failure stored in: > /home/fedora/openembedded-core/build/tmp-glibc/work/qemux86_64-oe-linux/spidev-test/1.0- > r0/temp/log.do_populate_lic.281153 > ERROR: Task > (/home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic) > failed wi > th exit code '1' > NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and > 1 failed. > > Summary: 1 task failed: > > /home/fedora/junk/meta-openembedded/meta-oe/recipes-kernel/spidev-test/spidev-test.bb:do_populate_lic > Summary: There were 2 WARNING messages shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > What's this about licences? in current OE, there is no "GPL-2.0" license file, there is "GPL-2.0-only" and "GPL-2.0-or-later" and a bunch of others, so i think you need to pick one of those. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52741): https://lists.yoctoproject.org/g/yocto/message/52741 Mute This Topic: https://lists.yoctoproject.org/mt/81364125/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how often would one use "VAR_someoverride_append = ..."?
On Wed, 10 Mar 2021, Quentin Schulz wrote: ... snip ... > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.10.bb#n12 > for example. > > This is an example of a "valid" use case (not that there are invalid > ones) for VAR_foo. > > Would probably a better example: > https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.10.bb#n50 > > So, you might decide that a machine is so much different than others > that KERNEL_FEATURES should be overridden for said machine. > > Then in a bbappend, one might want to add another feature for this > machine, they'll therefore need to use KERNEL_FEATURES_foo_append. > > I do not have examples at hand of VAR_foo_append except the ones > Leon sent in another mail. Which should show how rare it is :) i will ramble for just a bit as i think i settled on a way to perhaps explain the difference here to some students. in the overwhelmingly common case, we normally see overrides at the end of either assignments or appends: VAR = "snafu" VAR_qemux86 = "more snafu" VAR_append_qemux86 = "qemux86_specific_fubar" it seems that the proper way to interpret the above is that, in the end, all you would be after is the *final* value of the single variable VAR, and all the appending and overriding is leading you in that direction -- whatever "VAR" contains after it's all over is all you care about. on the other hand, with the example from the kernel recipe: KBRANCH_qemuarm ?= "v5.10/standard/arm-versatile-926ejs" KBRANCH_qemuarm64 ?= "v5.10/standard/qemuarm64" KBRANCH_qemumips ?= "v5.10/standard/mti-malta32" KBRANCH_qemuppc ?= "v5.10/standard/qemuppc" KBRANCH_qemuriscv64 ?= "v5.10/standard/base" KBRANCH_qemux86 ?= "v5.10/standard/base" KBRANCH_qemux86-64 ?= "v5.10/standard/base" KBRANCH_qemumips64 ?= "v5.10/standard/mti-malta64" it seems that the right way to interpret the above is that you are, simultaneously, creating *multiple* versions of the variable KBRANCH, so that if you subsequently see, for example: KBRANCH_qemux86_append = " whatever" you're appending to the variable KBRANCH_qemux86 because the ultimate result you're after is the *set* of KBRANCH-related variables, perhaps because you will actually need them all at once. and given that most situations don't require access to all of those variations of that variable, that's why the first approach is by far the most common. that might be an over-simplification, but it seems to at least give an idea of why that second approach would be used in very particular situations. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52660): https://lists.yoctoproject.org/g/yocto/message/52660 Mute This Topic: https://lists.yoctoproject.org/mt/81202306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how often would one use "VAR_someoverride_append = ..."?
On Tue, 9 Mar 2021, Quentin Schulz wrote: > Hi Robert, > > On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote: > > > > bitbake manual, chapter 3, examples of conditional syntax: > > > > https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples > > > > correctly distinguishes between A_foo_append and A_append_foo, but how > > often would one use that first form, anyway? > > > > most uses of conditional appending are either just straight > > appending: > > > > VAR_append = "fubar" > > > > or used with an override thusly: > > > > VAR_append_x86 = "snafu" > > > > is there an actual practical usage of, say: > > > > VAR_x86_append = "huh" > > > > i can't remember the last time i saw something of that form and, > > while it might be worth explaining, it seems that the reader might be > > warned that that form is almost certainly *not* what they want. > > > > Yes, in 99% of the cases, you want VAR_append_foo and not VAR_foo_append. > > VAR_foo_append makes sense when you want to append to VAR_foo which > is a way to override completely VAR for builds matching the foo > override. This happens in kernel-yocto recipes where branches and > defconfigs are different per machine for example. can you point at an actual example of that? i took a look and all the yocto kernel recipes i see use the first form. am i just looking in the wrong place? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52646): https://lists.yoctoproject.org/g/yocto/message/52646 Mute This Topic: https://lists.yoctoproject.org/mt/81202306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] konrad has officially blessed his new meta-rubygems layer
inspired by my earlier plaintive mewling of "gosh, i wish YP had better ruby support," konrad weihmann put in a ridiculous amount of work and came up with: https://github.com/priv-kweihmann/meta-rubygems while i am listed as a contributor, konrad has done 98% of the work, and i really plan on diving back into that soon, but that layer is effectively all his, and he invited me to let people know about it, if anyone else wanted to play along. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52644): https://lists.yoctoproject.org/g/yocto/message/52644 Mute This Topic: https://lists.yoctoproject.org/mt/81224341/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] what version of YP will next wind river (LTS20) be based on?
i suspect i know the answer, just want to confirm ... friend tells me yesterday he's working with LTS20, i said, "uh, that's not even out yet," he assures he his company has an early release, but he couldn't tell me what version of YP it corresponded to. based on regularity of releases on both sides, i would *guess* it's equivalent to gatesgarth, is that a good guess? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52641): https://lists.yoctoproject.org/g/yocto/message/52641 Mute This Topic: https://lists.yoctoproject.org/mt/81223517/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how often would one use "VAR_someoverride_append = ..."?
On Tue, 9 Mar 2021, Quentin Schulz wrote: > Hi Robert, > > On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote: > > > > bitbake manual, chapter 3, examples of conditional syntax: > > > > https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples > > > > correctly distinguishes between A_foo_append and A_append_foo, but how > > often would one use that first form, anyway? > > > > most uses of conditional appending are either just straight > > appending: > > > > VAR_append = "fubar" > > > > or used with an override thusly: > > > > VAR_append_x86 = "snafu" > > > > is there an actual practical usage of, say: > > > > VAR_x86_append = "huh" > > > > i can't remember the last time i saw something of that form and, > > while it might be worth explaining, it seems that the reader might be > > warned that that form is almost certainly *not* what they want. > > > > Yes, in 99% of the cases, you want VAR_append_foo and not > VAR_foo_append. > > VAR_foo_append makes sense when you want to append to VAR_foo which > is a way to override completely VAR for builds matching the foo > override. This happens in kernel-yocto recipes where branches and > defconfigs are different per machine for example. > > The sneaky thing about VAR_foo_append is that it creates VAR_foo > even if it didn't exist beforehand, meaning you though you > *appended* something to VAR while you actually replaced VAR entirely > with what VAR_foo_append is set too. i remember testing this a few years back, and making sure i appreciated the subtleties. i might take a shot at rewriting that section, since i think it has potential for confusion. mostly, warning the reader that the first form is almost always what they want. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52625): https://lists.yoctoproject.org/g/yocto/message/52625 Mute This Topic: https://lists.yoctoproject.org/mt/81202306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how often would one use "VAR_someoverride_append = ..."?
bitbake manual, chapter 3, examples of conditional syntax: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples correctly distinguishes between A_foo_append and A_append_foo, but how often would one use that first form, anyway? most uses of conditional appending are either just straight appending: VAR_append = "fubar" or used with an override thusly: VAR_append_x86 = "snafu" is there an actual practical usage of, say: VAR_x86_append = "huh" i can't remember the last time i saw something of that form and, while it might be worth explaining, it seems that the reader might be warned that that form is almost certainly *not* what they want. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52623): https://lists.yoctoproject.org/g/yocto/message/52623 Mute This Topic: https://lists.yoctoproject.org/mt/81202306/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] anyone bundled libbpf into a recipe?
colleague wants a recipe for libbpf: https://github.com/libbpf/libbpf would anyone have done that already and is willing to let me steal it? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52417): https://lists.yoctoproject.org/g/yocto/message/52417 Mute This Topic: https://lists.yoctoproject.org/mt/80822120/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how to copy NTP parser files verbatim from 4.2.8p10 to 4.2.8p13?
here's hoping someone has gone through this and can summarize what i need to do; i'll try to keep it short. migrating all sorts of stuff from (effectively) morty project to (effectively) zeus, and currently moving from ntp_4.2.8p10 to ntp_4.2.8p13, the only complication being that, way back when, the p10 parser was extended to recognize two new (proprietary) command-line options; thus, at the time, it's clear that yacc was run to generate new parser files, which have worked just fine all this time, so i have a solution for p10. so far, i've added all the underlying support code for these additional options, and all of that compiles just fine, so everything needed to *support* the two new options is in place -- new structures have been added, existing structures have been extended, new functions are in place, etc etc etc. all that looks good. the only thing missing is the final bit to support the two new run-time options, but i've been told that there is no need to re-run yacc to re-generate the parser files, as i can just take them verbatim from the old p10 recipe (and i don't think i have a choice since i can't get [b]yacc to run anyway, as it simply generates a usage error). so all i'm after is, needing to avoid running yacc again, to know what i need to steal from the p10 patches. i have patches touching all of (and more): * keyword-gen.c * ntp_keyword.h * ntp_parser.[chy] i've tried to selectively copy what look like the appropriate files into the appropriate locations but, no matter what i do, the build process insists on running byacc again, and chokes. so focusing exclusively on the parser component, is there a simple list of what i need to copy in/patch verbatim to effect the same changes without the build trying to regenerate the parser files? once i have that, i can obviously add the final support code that recognizes the new parser tokens. thoughts? am i even looking at this the right way? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52293): https://lists.yoctoproject.org/g/yocto/message/52293 Mute This Topic: https://lists.yoctoproject.org/mt/80556864/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] using SYSTEMD_SERVICE to disable a systemd service?
while the "standard" way to disable a systemd service from
auto-booting is SYSTEMD_AUTO_ENABLE, i just ran across a number of
examples in an existing project that do this:
SYSTEMD_SERVICE_${PN} = ""
ouch. that's a new one on me and, while i'm prepared to believe it
works, it seems like grotesque overkill and mis-application of that
variable.
am i within my rights to suggest that that's not really the way to
do it? or is that considered an acceptable (albeit weird) alternative?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52183): https://lists.yoctoproject.org/g/yocto/message/52183
Mute This Topic: https://lists.yoctoproject.org/mt/80310328/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] oddity: file_5.37 printing unexpected "octet-stream" mime type for ISO
(i asked about this on the OE list a couple days ago, but i have more info and wanted to get a bit wider coverage as i really, really want to de-mystify this issue.) on current project, upgrading from wind river WRL9 to LTS19 (effectively morty to zeus) involves going from file_5.28 to file_5.37 recipe, which is used by various install and upgrade scripts to validate something is an actual ISO image by checking its mime type (not the way i would have done it, but it's done). in WRL9, the mime type of an ISO image as printed by "file -i" included the string "application/x-iso9660-image", and that's what these scripts use to "verify" ISOness. so far, so good. suddenly, in LTS19, the very same "file -i" invocation instead prints "application/octet-stream" -- this very same weirdness was noticed elsewhere, like here in ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1763570 that bug report describes *precisely* the behaviour we're seeing. it's hard to believe the "file" command could have been that broken so i looked around for another explanation, and noticed that any single file could match multiple mime types, and that the file command had a "--keep-going" option, so my colleague tried that and, sure enough: # file -i --keep-going /var/tmp/ptx.iso /var/tmp/ptx.iso: application/x-iso9660-imageapplication/x-dosexec\012- application/octet-stream; charset=binary so now we see both mime types being displayed, but it's not feasible to change all the scripts to add the "--keep-going" option so i'm baffled as to why the newer file command suddenly decides to print "octet-stream" as the mime type rather than the more precise "x-iso9669-image". more puzzlingly, the man page for the command states: -k, --keep-going Don't stop at the first match, keep going. Subsequent matches will be have the string ‘\012- ’ prepended. (If you want a newline, see the -r option.) The magic pat‐ tern with the highest strength (see the -l option) comes first. hang on ... if the pattern with the highest strength is allegedly printed first, in the above, that is "x-iso9660-iamge", so why would that not be the single mime type displayed by a normal invocation? has anyone else seen this? can it be reproduced? i'll try the latest version of file later this weekend, but i'm open to assistance since this weirdness is currently breaking all sorts of install and upgrade procedures. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52166): https://lists.yoctoproject.org/g/yocto/message/52166 Mute This Topic: https://lists.yoctoproject.org/mt/80232547/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
On Wed, 27 Jan 2021, akuster wrote: > On 1/27/21 1:29 PM, Robert P. J. Day wrote: > > On Wed, 27 Jan 2021, Armin Kuster wrote: > > > >> > >> On 1/27/21 12:04 PM, Robert P. J. Day wrote: > >>> regarding the proposed "meta-rubygems" layer --- which sounds like > >>> it's going to take off as it can be initialized quite a lot just from > >>> konrad's existing meta-sca layer, what are the options for "official" > >>> YP hosting? > >>> > >>> i notice that quite a number of layers live at git.yoctoproject.org > >>> -- would this proposed layer even be eligible for that and, if so, > >>> what are the benefits of living under the git.YP.org umbrella? > >> Are you a member of the Yocto Project? > > i personally am not, so i suspect github is the option. > > Regardless of its home, there seems to be interest in such a layer. > There is nothing stopping you from registering in the layer in the > layer index and see where it goes from there. > > Ruby was part of meta-openembedded. Maybe OE would want to host such > a layer or include it within meta-openembedded. interesting idea, i hadn't considered that. in the meantime, i think we'll ponder what the structure of the new layer will look like, and put together a first pass. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52132): https://lists.yoctoproject.org/g/yocto/message/52132 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
On Wed, 27 Jan 2021, Armin Kuster wrote: > > > On 1/27/21 12:04 PM, Robert P. J. Day wrote: > > regarding the proposed "meta-rubygems" layer --- which sounds like > > it's going to take off as it can be initialized quite a lot just from > > konrad's existing meta-sca layer, what are the options for "official" > > YP hosting? > > > > i notice that quite a number of layers live at git.yoctoproject.org > > -- would this proposed layer even be eligible for that and, if so, > > what are the benefits of living under the git.YP.org umbrella? > Are you a member of the Yocto Project? i personally am not, so i suspect github is the option. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52125): https://lists.yoctoproject.org/g/yocto/message/52125 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
regarding the proposed "meta-rubygems" layer --- which sounds like it's going to take off as it can be initialized quite a lot just from konrad's existing meta-sca layer, what are the options for "official" YP hosting? i notice that quite a number of layers live at git.yoctoproject.org -- would this proposed layer even be eligible for that and, if so, what are the benefits of living under the git.YP.org umbrella? if not there, then github would be the obvious alternative. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52123): https://lists.yoctoproject.org/g/yocto/message/52123 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] any interest in an official "meta-rubygems" layer?
On Wed, 27 Jan 2021, Jack Mitchell wrote: ... snip ... > Hi Robert, > > This is something I would be interested in. I have a developed a > much more basic rubygems class privately which I had intended to > opensource and create a similar later, so it would be nice to have a > central place to contribute Ruby/RubyGems improvements. As you have > found there are many layers with spotty Ruby support and a > particular copy of an old class that is being banded about which is > often insufficient. cool ... care to share your rubygems.bbclass file? be great to combine the best of both worlds. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52109): https://lists.yoctoproject.org/g/yocto/message/52109 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] any interest in an official "meta-rubygems" layer?
since it appears that i will be diving head-first into messing with ruby in some current YP builds, is there any interest in creating a meta-rubygems layer to start collecting recipes based on what konrad weihmann has done in his meta-sca layer here? https://github.com/priv-kweihmann/meta-sca i've been swapping emails with konrad over the last few days and, first, it seems clear that it's not appropriate to start dumping general ruby recipes into meta-sca as that layer is clearly defined as being for "static code analysis and security hardening", so a new, more general layer is obviously more appropriate. also, konrad focuses on using his own "rubygems.bbclass" class file: https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass to define recipes that pull from rubygems.org exclusively, and he agrees that it would keep things simpler to stick with that model; hence, the proposal of the layer name "meta-rubygems" and not just "meta-ruby". konrad already offered to do the maintenance of such a new layer, as long as there is standard infrastructure support for testing, that sort of thing. and i'm sure that would make his meta-sca layer simpler as all the more generic rubygems-based recipes could be moved into the meta-rubygems layer, leaving his meta-sca layer to focus exclusively on the code analysis and security recipes, however he wants to do that. thoughts? it seems that a new layer could be populated almost instantly with a large chunk of meta-sca, and we could take it from there. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52105): https://lists.yoctoproject.org/g/yocto/message/52105 Mute This Topic: https://lists.yoctoproject.org/mt/80151914/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] #yocto #kernel setting up PREMIRRORS under zeus
On Sun, 24 Jan 2021, Monsees, Steven C (US) via lists.yoctoproject.org wrote: > I added the following to my local.conf: > > INHERIT += "own-mirrors" > > SOURCE_MIRROR_URL = “file:///ede/tms/yocto/zeus/downloads/PATH” > > But this does not appear to retrieve the tar-balls from from my local > repository… not sure why that wouldn't work, it's what i've used for years. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#52076): https://lists.yoctoproject.org/g/yocto/message/52076 Mute This Topic: https://lists.yoctoproject.org/mt/80086836/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #kernel:https://lists.yoctoproject.org/g/yocto/mutehashtag/kernel Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] why would "file" command not print out "ISO 9660" for .iso image?
was just handed this little puzzler and, before i dive into it, perhaps someone has an answer. in working WRL9/morty system, the "file" command (file_5.28.bb) is used to determine whether a file is a valid ISO image, by running "file" against the image file, expecting to get output like: rday.iso: DOS/MBR boot sector ISO 9660 ... etc etc ... and doing a tacky string comparison simply looking for the substring "ISO" and, so far, it's worked just fine. now, moving to an LTS19/zeus system -- same ISO image -- that shell string comparison fails, apparently because the output from file_5.37.bb for precisely the same ISO image file is only: rday.iso: DOS/MBR boot sector as in, that's the entire output, hence no "ISO" substring, hence failed comparison. i'm about to verify that all is as i've been told, then try to figure out why the newer file command is dropping all the rest of that output. (it's even possible that the developers put in a weird, custom magic file but that's just speculation.) does the above sound familiar to anyone? is the newer "file" command sufficiently different as to have dropped that "ISO ..." part of the output? and is there an option to restore it? thanks for any hints. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51952): https://lists.yoctoproject.org/g/yocto/message/51952 Mute This Topic: https://lists.yoctoproject.org/mt/79529725/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Prevent WIC image from being built?
On Tue, 29 Dec 2020, Howard wrote: > Yup, thank you Bruce: > > Using > IMAGE_FSTYPES_remove += "wic" > > Didn't do it for me, but > > IMAGE_TYPES_remove += "wic" > > did the trick. pedantry, but i'm fairly sure "=" would have sufficed; there was no need to use "+=" here. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51856): https://lists.yoctoproject.org/g/yocto/message/51856 Mute This Topic: https://lists.yoctoproject.org/mt/79281573/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] recommendations for (YP-based) linux-powered drones?
friend recently asked me for recommendations for entry-level, linux-based drones whose software is generated by yocto project, so it could be used as a learning experience. as in, the fun would be in the creation and customization of the software, not just playing with the drone. i didn't have an immediate answer ... i recall that qualcomm has linux-based drone components: https://developer.qualcomm.com/hardware/qualcomm-flight-pro and i'm aware of https://www.dronecode.org/, focused on OSS drone projects. any thoughts on linux-based drones where one would build the software using yocto project? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51844): https://lists.yoctoproject.org/g/yocto/message/51844 Mute This Topic: https://lists.yoctoproject.org/mt/79280530/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] obvious(?) ruby error: adding erroneous second ".gemspec" suffix
i'm not fluent enough in ruby to want to submit a patch for this, so
i'll let someone higher up the food chain handle it.
trying to build a number of "native" ruby recipes from
meta-openstack, and getting precisely the same error for various
recipes:
| ERROR: Gemspec file not found: X-native.gemspec.gemspec
the clear bug here is that something is adding a ".gemspec" suffix to
a string that *already* has that suffix. that error is acknowledged
here ("Append '.gemspec' extension only when it is not present"):
https://github.com/voxik/rubygems/commit/6c3f0dc798966a6474f6d694da05a15d620760d6
so someone who is more comfortable with ruby is invited to deal with
that.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51833): https://lists.yoctoproject.org/g/yocto/message/51833
Mute This Topic: https://lists.yoctoproject.org/mt/79240071/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] is there a focused place to ask about ruby/gems WRT yocto building?
to prepare for trying to build a number of ruby gems for WR LTS19 (effectively zeus, as always), i thought i'd start simple and begin with building for qemux86-64 with gatesgarth so i could plausibly claim that i have a working basis for comparison, whereupon if that worked for what i was after, i could work backwards. i just now started a build for qemux86-64/gatesgarth with "bitbake ruby", and i'll take it from there. knowing little about ruby, is there a smaller community that would help with issues i run into, or should i keep the discussion here? i want to start by trying to build absolutely stock puppet and chef, and if that turns out to need fixing, i will of course submit patches. if anyone has already gone through this exercise, that would be just ducky. i should have the result of the first build in an hour or two -- given that i'm not trying to do anything out of the ordinary, i would *hope* that a totally generic build would work out of the box, but we'll see. rday p.s. the above recipes involve the layers meta-cloud-services and sub-layer meta-openstack. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51832): https://lists.yoctoproject.org/g/yocto/message/51832 Mute This Topic: https://lists.yoctoproject.org/mt/79231718/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Can a single recipe .bb file be used to generate both Python2 and Python3 packages?
On Sun, 20 Dec 2020, Rob Prowel wrote: > On 12/20/20 8:46 AM, Robert P. J. Day wrote: > > > I asked if that is what she was thinking of, but she was adamant > > that she remembers a single recipe .bb file that could do this. > > Is there such a thing? I suspect one could hack something up, > > but is such an approach considered standard? Or even doable? > > Doable? Yes...Smart to do? IMHO, absolutely not. > > With the recipe class methods that accomplish each stage of the > build you can customize them any way you want, but at the expense of > maintaining clear intent and keeping it maintainable. > > Your initial approach of using common includes and a heirarchical > inheritance for separate recipes makes more sense. i suspected as much, i just wanted to confirm there was no super-clever way to do this. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51817): https://lists.yoctoproject.org/g/yocto/message/51817 Mute This Topic: https://lists.yoctoproject.org/mt/79103004/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Can a single recipe .bb file be used to generate both Python2 and Python3 packages?
Strange request earlier this week -- I was asked how *one* Python recipe file could be used to generate both Python2 and Python3 packages to be installed in the final image. I had never heard of such a thing, but the colleague asking this was convinced she had seen this before somewhere (but couldn't remember where). My immediate response was that the standard approach was to define two recipe files -- say, python-fubar.bb and python3-fubar.bb -- where the entire difference was "inherit setuptools" in the former and "inherit setuptools3" in the latter. I mentioned that it used to be common to have just that, and for both recipes to then include all the common content in the file "python-fubar.inc" (I do see how a couple folks are cleaning all that up since, if there is now only the Python3 version being supported, it's pointless to still have a ".inc" file). I asked if that is what she was thinking of, but she was adamant that she remembers a single recipe .bb file that could do this. Is there such a thing? I suspect one could hack something up, but is such an approach considered standard? Or even doable? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51814): https://lists.yoctoproject.org/g/yocto/message/51814 Mute This Topic: https://lists.yoctoproject.org/mt/79103004/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how to install/package debug version of library *not* in /usr/lib64/.debug?
just got an interesting request from a colleague ... for reasons i
will explain shortly, it's necessary to build both the normal and
debug versions of a library, but for the debug version to be installed
in any directory other than one where the final pathname component is
".debug".
the reason is that yocto is used for the first part of the build
process, but the final result is then grabbed by an internal packaging
system that promptly untar's the YP-generated rootfs, and does a bunch
more proprietary post-processing, and one of those unskippable steps
is to manually delete the directory /usr/lib64/.debug/, so the request
is, if the recipe is for "fubar-dbg", then it's fine if that
debug-enabled shared library is installed under, say,
/usr/lib64/fubar-dbg/ (or whatever they choose to call that last
pathname component, as long as it's not ".debug").
i'm sure there are simple do_package_append() or do_install_append()
functions that would do it; i took a look at package.bbclass, and
noticed the split_and_strip_files() routine, with the snippet:
if d.getVar('PACKAGE_DEBUG_SPLIT_STYLE') == 'debug-file-directory':
# Single debug-file-directory style debug info
debugappend = ".debug"
debugstaticappend = ""
debugdir = ""
debugstaticdir = ""
debuglibdir = "/usr/lib/debug"
debugstaticlibdir = "/usr/lib/debug-static"
debugsrcdir = "/usr/src/debug"
with the setting of "debuglibdir", but in our case, the dest dir is
/usr/lib64 (although symlinks might make that distinction irrelevant,
i'd have to check).
am i overthinking this? what's the cleverest way to do this? (hoping
i've described this sufficiently clearly.)
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51800): https://lists.yoctoproject.org/g/yocto/message/51800
Mute This Topic: https://lists.yoctoproject.org/mt/79041846/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] "cleanest" way to resolve python2/python3 recipe file install conflicts?
was recently presented with the following issue involving a
zeus-based (actually, wind river LTS19-based -- effectively much the
same) issue.
group wants to move many python2 recipes to python3, but there is
apparently a need to keep python2, including quite a number of the
same recipes that will also be installed as python3 versions, which is
causing the following problem.
as a single example, in trying to install both versions of
"python{2,3}-chardet", it's entirely unsurprising for there to be a
file install conflict as both recipes want to install the same file
"/usr/bin/chardetect":
Error: Transaction check error:
file /usr/bin/chardetect conflicts between attempted installs of
python-chardet-3.0.4-r0.core2_64and python3-chardet-3.0.4-r0.core2_64
until now, there were very few examples of that, and it was
"resolved" by do_install_append()ing one of the recipes to simply
delete its copy of that executable, leaving the other one. yuck.
given the many more examples of that now showing up, i don't want to
have to start doing that for every recipe conflict. my initial
reaction was to grumble, "are you really, really sure you need both
versions of the same recipe? really? seriously?"
am i overlooking something here? it seems that there are going to be
many dozen examples of that shortly, and i don't want to have to
bbappend every one of them in such a hacky way.
thoughts?
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#51668): https://lists.yoctoproject.org/g/yocto/message/51668
Mute This Topic: https://lists.yoctoproject.org/mt/78775343/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Using OVERRIDES to set variables from outside the recipe file
On Thu, 3 Dec 2020, Quentin Schulz wrote: > Hi Andrew, > > On Thu, Dec 03, 2020 at 03:45:41AM +, Andrew Loader wrote: > > In the bitbake user manual it has an example of how to set the variable > > value using the OVERRIDE variable > > > > OVERRIDES = "architecture:os:machine" > > TEST = "default" > > TEST_os = "osspecific" > > TEST_nooverride = "othercondvalue" > > > > Lets say this is in the recipe called "test_0.1.bb" and we remove the > > OVERRIDES line from it > > > > If we want to the OVERRIDES value to configure the recipe externally say in > > local.conf as I do not want to change the recipe how would I do that? > > OVERRIDES is set in configuration files usually (always?). It can be > either in a distro if you use DISTROOVERRIDES, in a machine if you > use MACHINEOVERRIDES, and you might be able to add manually to it > from local.conf or other ways but I think you should go with > DISTROOVERRIDES or MACHINEOVERRIDES. > > Then, the OVERRIDES (which contains MACHINEOVERRIDES:DISTROOVERRIDES > among other things) will be used in all recipes you can find and it > should just work. > > You can use bitbake -e my-recipe | grep -e "^OVERRIDES=" to check > the content of the OVERRIDES variable. Note that righmost "OVERRIDE" > is the one which takes precedence over all others. i'm going to weigh in on this, as it *seems* that andrew has the same misunderstanding i had when, lo those many years ago, i read that section in the BB manual, and read this: OVERRIDES = "architecture:os:machine" TEST = "default" TEST_os = "osspecific" TEST_nooverride = "othercondvalue" my initial problem with that section was that it wasn't clear that entities like "architecture" and "os" and so on were *replaceable*, in that one was supposed to put *examples* of those values in those places. (laugh if you like, but if one is totally new to overrides, that section can be misinterpreted in a truly tragic way on first reading.) i recall extending that section to attempt to make it more understandable, but i think, over the holidays, i'm going to rewrite it again with a simpler introduction and more examples straight from the code base. (i believe i was the one who added the example involving overriding the value of KBRANCH based on the target arch.) in any event, i can easily see a much longer and involved introduction to overrides. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51628): https://lists.yoctoproject.org/g/yocto/message/51628 Mute This Topic: https://lists.yoctoproject.org/mt/78677907/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to add Python3 json module in Yocto
On Wed, 25 Nov 2020, vijayrakeshmunga...@gmail.com wrote: > Hi, can anyone please guide me on adding json module to my python > library in yocto. I had download .bb file from OE Layer and placed > it under recipe-devtool/python folder, but it is not including to > the build. Also guide me how to select a suitable .bb file as there > are many recipes available on json. simply adding a recipe to your layer is not sufficient ... you need to specifically say you want a package added to your image with, perhaps, adding the line: IMAGE_INSTALL_append = " ..." to your local.conf file. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51555): https://lists.yoctoproject.org/g/yocto/message/51555 Mute This Topic: https://lists.yoctoproject.org/mt/78497680/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] OE/YP equivalent to 'mtree'?
colleague wants to know if there is something available in an OE/YP layer equivalent to mtree: https://linux.die.net/man/8/mtree i'm looking at a few possibilities right now but nothing seems really equivalent. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51531): https://lists.yoctoproject.org/g/yocto/message/51531 Mute This Topic: https://lists.yoctoproject.org/mt/78461199/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] strange meta-security bbappend file with two percent signs
while the bitbake user manual insists: "The use of the ” % ” character is limited in that it only works directly in front of the .bbappend portion of the append file’s name. You cannot use the wildcard character in any other location of the name." i just ran across this in the meta-security layer: recipes-kernel/linux/linux-%_5.%.bbappend what is one supposed to make of that? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51518): https://lists.yoctoproject.org/g/yocto/message/51518 Mute This Topic: https://lists.yoctoproject.org/mt/78420582/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Best convention for FILES variable
On Sat, 21 Nov 2020, Chuck Wolber wrote: > > > On Sat, Nov 21, 2020 at 12:21 AM Chuck Wolber wrote: > > %< SNIP %< > > And finally, I have adjusted to using the following pattern, and found > that it > has improved maintainability a great deal. It applies to DEPENDS and > RDEPENDS > as well. Yes, it is a bit tedious, but the benefits far outweigh the > cost > (IMHO). > > FILES_fooz += " lib/foozlib.so" > FILES_fooz += " /usr/lib/foozlib-2.so" > FILES_fooz += " /usr/bin/fooz" > FILES_fooz += " /bin/fooz" > FILES_fooz += " /usr/share/fooz" pedantically speaking, since you're using "+=", you don't need those leading spaces. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51517): https://lists.yoctoproject.org/g/yocto/message/51517 Mute This Topic: https://lists.yoctoproject.org/mt/78404917/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] is there a way to centralize numerous BBCLASSEXTEND settings?
related to something i asked a while back, i have a layer in front of me wherein dozens and dozens of .bbappend files exist for no other purpose than to contain the single line: BBCLASSEXTEND += "nativesdk" AFAIK, there is no way to centralize all of that, which would be delightful. it's daunting to look at such a layer for the first time, be intimidated by the number of bbappends, only to realize that 80% of them have a single purpose. personally, i'm tempted to create a new directory structure, recipes-nativesdk/whatever/, and populate it with just those bbappend files, just to clean out the other directories. is there a way to do something like this cleanly? or would it be considered poor design? rday x -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#51385): https://lists.yoctoproject.org/g/yocto/message/51385 Mute This Topic: https://lists.yoctoproject.org/mt/78288331/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] File collision: same path from 2 recipes
Quoting Laurent Gauthier :
Hi Mauro,
From my experience there should be an error reported during the image
creation as long as the two *packages* that contain a file with the same
name are BOTH installed in the root filesystem.
If you don't receive an error I would suspect that for some reason the file
is really only installed by one of the two packages.
Another source of your issue is that there can be more than one package
created by one recipe, and maybe you are not installing the package which
contains the contentious file.
Kind Regards, Laurent.
On Tue, Sep 29, 2020 at 2:08 PM Mauro Ziliani wrote:
Hi all.
There is a QA to test if 2 recipes try to install a file with the same
path?
In my BSP 2 recipes try install the file
${D}/etc/network/if-up,d/hostapd_restart
I'd like receive an error from bitbale
I was just about to weigh in on this as I was just educated by
Richard Purdie as to the (im)proper use of SSTATE_DUPWHITELIST.
If two packages were truly trying to install the same file, I would
have assumed that you would have received an error to that effect,
so the fact that you aren't suggests one of:
* they're not really trying to install the same file
* you're installing only one of the packages
* perhaps there is a do_install_append() that is manually
removing the conflicting file from one of the recipes
My opinion, FWIW.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50869): https://lists.yoctoproject.org/g/yocto/message/50869
Mute This Topic: https://lists.yoctoproject.org/mt/77194296/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to *properly* use SSTATE_DUPWHITELIST?
Quoting "Robert P. J. Day" : Never had cause to dig into SSTATE_DUPWHITELIST until now, so a couple questions. (Side Note: This variable is not listed in the YP Reference Manual variable glossary -- should it be?) Ran across this as current project incorporates recipes grpc-python and python-grpcio, which is problematic as the latter is simply the renamed version of the former so, yeah, that's definitely going to generate a ton of file install conflicts. The solution selected (and, yes, I know this is tacky and gross and this should be fixed the right way) was to add the line: SSTATE_DUPWHITELIST = "/" to python-grpcio.inc, which *seemed* to fix the problem, until I started playing this morning to clarify what different variations of this solution would do. First oddity was that, after I added or deleted that line, it seemed it made no difference in the rebuild of the incorporating image, until I noticed this in sstate.bbclass: sstate_install[vardepsexclude] += "SSTATE_DUPWHITELIST ..." which suggests that the sstate doesn't check dependency based on SSTATE_DUPWHITELIST, so to get the change to kick in, I did a "bitbake -c cleanall ..." on those recipes first, and that seemed to do it. But even that showed some weirdly non-deterministic behaviour, as there seemed to be a difference based on which recipe I added that line to, and which recipe I cleaned. So the obvious question is, if I have two recipes that clash in terms of installed files like these two, does one add that line to either or both of the recipes? What does it mean to add it to only one, and if that happens (as it did here), how does that affect the eventual install? Does ordering then matter? In a general case, if I have, say, 5 recipes all of which clash in the same place, do I add that line to all 5 recipes? And if I don't, do I get undefined behaviour? Oh, wait, I think I misunderstood this variable entirely -- it's not a per-recipe variable, is it? Its value represents the combination over all recipes in the image, is that right? So by adding the line: SSTATE_DUPWHITELIST = "/" I've effectively de-activated file conflict errors across the entire rootfs and all recipes in the image, do I have that right? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50774): https://lists.yoctoproject.org/g/yocto/message/50774 Mute This Topic: https://lists.yoctoproject.org/mt/77021783/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] How to *properly* use SSTATE_DUPWHITELIST?
Never had cause to dig into SSTATE_DUPWHITELIST until now, so a couple questions. (Side Note: This variable is not listed in the YP Reference Manual variable glossary -- should it be?) Ran across this as current project incorporates recipes grpc-python and python-grpcio, which is problematic as the latter is simply the renamed version of the former so, yeah, that's definitely going to generate a ton of file install conflicts. The solution selected (and, yes, I know this is tacky and gross and this should be fixed the right way) was to add the line: SSTATE_DUPWHITELIST = "/" to python-grpcio.inc, which *seemed* to fix the problem, until I started playing this morning to clarify what different variations of this solution would do. First oddity was that, after I added or deleted that line, it seemed it made no difference in the rebuild of the incorporating image, until I noticed this in sstate.bbclass: sstate_install[vardepsexclude] += "SSTATE_DUPWHITELIST ..." which suggests that the sstate doesn't check dependency based on SSTATE_DUPWHITELIST, so to get the change to kick in, I did a "bitbake -c cleanall ..." on those recipes first, and that seemed to do it. But even that showed some weirdly non-deterministic behaviour, as there seemed to be a difference based on which recipe I added that line to, and which recipe I cleaned. So the obvious question is, if I have two recipes that clash in terms of installed files like these two, does one add that line to either or both of the recipes? What does it mean to add it to only one, and if that happens (as it did here), how does that affect the eventual install? Does ordering then matter? In a general case, if I have, say, 5 recipes all of which clash in the same place, do I add that line to all 5 recipes? And if I don't, do I get undefined behaviour? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50773): https://lists.yoctoproject.org/g/yocto/message/50773 Mute This Topic: https://lists.yoctoproject.org/mt/77021783/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Yocto uses older PV instead of newest - how to figure out why?
Quoting Oliver Westermann : Hey, we're porting our yocto from an older NXP iMX release to their newest BSP, upgrading yocto in the process from sumo to zeus. Using their current setup, the layers provide one recipe in two versions - 0.2 and 1.0. imx-boot to be precise. I assumed yocto would use the newer version, but it uses 0.2 for some reason and I can't figure out why: I 'grep'ed' everything and could not find any reference to this package which has some version requirements. Are there any tips to figure out why yocto is not using the 1.0 recipe? Could it have something to do with layer priorities? Use the "bitbake-layers" utility to display where recipes are being pulled from. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50330): https://lists.yoctoproject.org/g/yocto/message/50330 Mute This Topic: https://lists.yoctoproject.org/mt/76383502/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how to combine out-of-tree kernel module with EXTERNALSRC kernel source?
currently have a perfectly functioning zeus-based layer with a small number of out-of-tree kernel modules which build just fine with: $ bitbake kernel-module-fubar against the stock linux-yocto (5.2) kernel provided by zeus. was just asked how to build those same out-of-tree modules against an external kernel identified by (i'm guessing) EXTERNALSRC. i don't need to build the kernel itself, just configure it to the point (a la "make modules_prepare") so that i can build modules against it. specifying an external source for the kernel seems easy enough, but i don't see how to then get the modules to build against that. a quick google showed me: https://wiki.koansoftware.com/index.php/Building_Software_from_an_External_Source "Depending on the type of build (eg, 'inherit module' for out of tree Linux kernel modules) you may or may not need to set EXTERNALSRC_BUILD." that explanation seems a bit on the vague side ... is there an explanation of this somewhere? i can't modify recipes, i need to do this exclusively through local.conf. thoughts? this seems like a useful enough operation that surely others have done it before now. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50268): https://lists.yoctoproject.org/g/yocto/message/50268 Mute This Topic: https://lists.yoctoproject.org/mt/76155801/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] dunfell: what would cause "ERROR: Nothing PROVIDES 'coreutils-native'."?
migrating from zeus to dunfell and, suddenly, some "ndisc"-related recipes no longer build with: ERROR: Nothing PROVIDES 'coreutils-native'. the offending recipe is from meta-networking/recipes-support, ndisc6_git.bb, clearly at the line: DEPENDS = "coreutils-native" whereupon "git blame" informs me that that line comes from here: commit 51272d11594e8609237e0e049b1f97ff95ab7d19 Author: Sumit Garg Date: Tue Jan 21 14:26:11 2020 +0530 ndisc6: fix coreutils-native tool dependency coreutils-native tool dependency was implicitly met while building with source GCC tool-set which isn't the case with external tool-set. Signed-off-by: Sumit Garg Signed-off-by: Khem Raj i've examined dunfell's coreutils recipe and i see nothing that suggests i shouldn't be able to bitbake the native recipe -- BBCLASSEXTEND clearly extends the recipe to include "native." so now i'm looking at the local layer to see if there is something in a .conf file that deactivates the native building of coreutils but i don't see anything suspicious. i'm sure i'm missing something obvious but i'm at a loss. thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50251): https://lists.yoctoproject.org/g/yocto/message/50251 Mute This Topic: https://lists.yoctoproject.org/mt/76084670/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] does yocto "LTS" stand for "Long Term Support" or "Long Term Stable"?
i've seen two different wiki pages suggest each of the above ... it would be nice to be consistent. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50249): https://lists.yoctoproject.org/g/yocto/message/50249 Mute This Topic: https://lists.yoctoproject.org/mt/76082931/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] when is it appropriate to push recipe enhancements (eg., class-nativesdk) upstream?
based on recipe from an existing (zeus-based) project, colleague asks
about a bbappend file, and whether it's appropriate that it be submitted
upstream as a patch -- this example involves "pciutils" recipe from
oe-core, but the question more generally covers any number of recipes.
this particular code base has the following pciutils_%.bbappend file:
=== start ===
PACKAGECONFIG_class-nativesdk = ""
DISABLE_STATIC_pn-nativesdk-pciutils = ""
# Need nativesdk-specific do_install due to ${sbindir} being set to usr/bin
do_install_class-nativesdk () {
oe_runmake DESTDIR=${D} install install-lib
oe_multilib_header pci/config.h
}
BBCLASSEXTEND += "nativesdk"
=== end ===
i'm looking at this for the first time and, sure, it appears to
extend the pciutils recipe for nativesdk. but if that's true, then
would it not make sense to submit that as a patch?
the current zeus "pciutils_3.6.2.bb" recipe doesn't extend the
recipe for nativesdk, so if this bbappend file actually correctly
does that, would it not make sense to contribute that enhancement
back?
in general, there appear to be numerous recipes in this code base
that do little more than extend the recipe for native and nativesdk
because the oe-core (or meta-oe) recipes don't do that.
am i thinking about this correctly? it seems that, if local bbappend
content fixes or enhances a recipe, it would make sense to push that
fix so as to not have to carry around the bbappend files.
thoughts? i'm not passing any judgment on the correctness of this
particular bbappend file, i'm more interested in the general
philosophy of pushing improvements to not have to keep carrying
them around in the local code base.
rday
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50208): https://lists.yoctoproject.org/g/yocto/message/50208
Mute This Topic: https://lists.yoctoproject.org/mt/76005073/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] Python compile error: "The 'wheel' distribution was not found and is required by the application"
Colleague hands me build error wherein a Python2 recipe (grpc-python) fails to compile with: ... pkg_resources.DistributionNotFound: \ The 'wheel' distribution was not found and is required by the application ... This is a new one for me, and is in the context of a recipe added to "morty", so I examine the checked-out source and, sure enough, in the requirements.txt file, the final line reads: wheel>=0.29 But this doesn't look like a normal dependency failure, and I'm not sure what to make of this ... can anyone advise on how to resolve that error above? I can see there is a python3-wheel recipe, and I used "pipoe" to create a python-wheel recipe, but none of that helped. What exactly is the compile step in this recipe looking for that generates that error? Thoughts? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49985): https://lists.yoctoproject.org/g/yocto/message/49985 Mute This Topic: https://lists.yoctoproject.org/mt/75612523/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] simplest way to disable all shared state cache for a build?
what is the simplest way to disable any use of sstate for a new build? i see bitbake has a "--no-setscene" option that would appear to do that: Do not run any setscene tasks. sstate will be ignored and everything needed, built. i've also seen some solutions that involve setting to empty strings various variables like SSTATE_DIR, SSTATE_MIRRORS and so on. so if all i want is to make sure everything is fetched, configured and built with no use of sstate cache whatsoever, is "--no-setscene" the way to go? rday p.s. is this mentioned anywhere in the bitbake or a YP manual? seems like this would be useful information for rigorous testing purposes. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49960): https://lists.yoctoproject.org/g/yocto/message/49960 Mute This Topic: https://lists.yoctoproject.org/mt/75519075/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how does the recipe search resolve a recipe name? eg., "opencryptoki"?
i've run across this on occasion -- using http://layers.openembedded.org/ to find a given recipe sometimes produces answers that don't actually point to the recipe (this seems to be a good entry for a FAQ). went looking for "opencryptoki", and got here: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=opencryptoki none of which actually take one to a recipe for that software. granted, the summary explains that, "the package contains commands to utilize some of the capabilities available in the TPM PKCS#11 interface implemented in the openCryptoki project," but that's not the same thing. is there some sort of rationale for the search results one might get for a given recipe name? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49886): https://lists.yoctoproject.org/g/yocto/message/49886 Mute This Topic: https://lists.yoctoproject.org/mt/75334535/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how does "bitbake meta-toolchain" map to a particular "image" when generating SDK?
Quoting Richard Purdie : On Sun, 2020-07-05 at 15:24 -0400, Robert P. J. Day wrote: Quoting Ross Burton : > On Sun, 5 Jul 2020 at 11:50, Robert P. J. Day wrote: > >however, one can also generate a standard SDK with the generic > > (image-independent): > > > >$ bitbake meta-toolchain > > > > which clearly does not identify an image (all that recipe does, > > really, is "inherit populate_sdk"), so i *guessed* that using that > > command will generate a standard SDK based only on what can be found > > in the various .conf files and associated variables (MACHINE, DISTRO, > > etc.) without being tied to a particular image. > > > >just about to dive into the details, but is the above at least a > > simplistic way of looking at it? > > At the most fundamental level, you've asked bitbake to build > 'meta-toolchain'. Looking in meta-toolchain.bb will show you what > that entails. It's basically just the compilers and a few other tools > that were added as needed over the years. i'd assumed as much, but is there a reason that the meta-toolchain target is not mentioned at all in the SDK manual? Would that not be the right place to mention it, even briefly? meta-toolchain is really old, from the days before the populate_sdk task for images existed. It was created as a compatibility artefact and as an example to show you could do standalone SDKs like that without images. I'd imagine its not mentioned as we envisaged the populate_sdk tasks taking over from meta-toolchain. I'm not even sure we test meta- toolchain on the autobuilder. It probably continues to work as its so similar to buildtools-tarball and friends. Should it be mentioned? Maybe... that actually clears things up. i'll let others higher up the food chain decide if the meta-toolchain target should be documented, or if it's entirely superseded by the populate_sdk tasks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49878): https://lists.yoctoproject.org/g/yocto/message/49878 Mute This Topic: https://lists.yoctoproject.org/mt/75311311/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] how does "bitbake meta-toolchain" map to a particular "image" when generating SDK?
Quoting Ross Burton : On Sun, 5 Jul 2020 at 11:50, Robert P. J. Day wrote: however, one can also generate a standard SDK with the generic (image-independent): $ bitbake meta-toolchain which clearly does not identify an image (all that recipe does, really, is "inherit populate_sdk"), so i *guessed* that using that command will generate a standard SDK based only on what can be found in the various .conf files and associated variables (MACHINE, DISTRO, etc.) without being tied to a particular image. just about to dive into the details, but is the above at least a simplistic way of looking at it? At the most fundamental level, you've asked bitbake to build 'meta-toolchain'. Looking in meta-toolchain.bb will show you what that entails. It's basically just the compilers and a few other tools that were added as needed over the years. i'd assumed as much, but is there a reason that the meta-toolchain target is not mentioned at all in the SDK manual? Would that not be the right place to mention it, even briefly? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49875): https://lists.yoctoproject.org/g/yocto/message/49875 Mute This Topic: https://lists.yoctoproject.org/mt/75311311/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] how does "bitbake meta-toolchain" map to a particular "image" when generating SDK?
colleague asked what should have been an easy question, but as i've never spent a lot of time digging into the intricacies of generating SDKs (i guess i will now), i didn't have an immediate answer. current SDK manual in section 3 regarding standard SDKs states that, "The Standard SDK provides a cross-development toolchain and libraries tailored to the contents of a specific image." ok, saying the SDK is tailored to the contents of a specific image makes sense if one generates the SDK by selecting a particular image, say: $ bitbake -c populate_sdk core-image-minimal $ bitbake -c populate_sdk core-image-sato in those cases, one is identifying an image to use as the basis for the generated SDK, and i'm assuming that those image definitions can affect the final SDK generation by, perhaps, defining TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK and so on. however, one can also generate a standard SDK with the generic (image-independent): $ bitbake meta-toolchain which clearly does not identify an image (all that recipe does, really, is "inherit populate_sdk"), so i *guessed* that using that command will generate a standard SDK based only on what can be found in the various .conf files and associated variables (MACHINE, DISTRO, etc.) without being tied to a particular image. just about to dive into the details, but is the above at least a simplistic way of looking at it? rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49862): https://lists.yoctoproject.org/g/yocto/message/49862 Mute This Topic: https://lists.yoctoproject.org/mt/75311311/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
