NishanthMenon has quit [Ping timeout: 260 seconds]
lamm has joined #yocto
Crofton has quit [Ping timeout: 260 seconds]
rhadye has quit [Ping timeout: 260 seconds]
\dev\ice has quit [Ping timeout: 260 seconds]
olof has quit [Ping timeout: 260 seconds]
olof has joined #yocto
\dev\ice has joined #yocto
ernstp has joined #yocto
Crofton has joined #yocto
NishanthMenon has joined #yocto
tangofoxtrot has joined #yocto
\dev\ice has quit [Client Quit]
mckoan|away is now known as mckoan
<mckoan>
good morning
\dev\ice has joined #yocto
Tartarus has joined #yocto
rmmr has joined #yocto
mithro has joined #yocto
rhadye has joined #yocto
PobodysNerfect has joined #yocto
<LetoThe2nd>
yo dudX
Thorn has joined #yocto
rob_w has joined #yocto
rfuentess has joined #yocto
amitk_ has quit [Quit: leaving]
florian has joined #yocto
alejandr1 has quit [Ping timeout: 268 seconds]
alejandr1 has joined #yocto
frieder has joined #yocto
mvlad has joined #yocto
<jclsn>
Morning
gsalazar has joined #yocto
AdrianTheFirst has joined #yocto
<AdrianTheFirst>
Good morning!
<AdrianTheFirst>
I have a question regarding the Yocto build, I hope this is the right channel and I am not breaking any netiquette or rule. If I do, kindly let me know.
<jclsn>
AdrianTheFirst: We are not such an overly critical channel here. Feel free to ask what is on your mind :)
Guest98 has joined #yocto
<Guest98>
hi, morning.
<Guest98>
I can use "devtool modify linux-raspberrypi" successfully while using devtool, but when i do "devtool reset linux-raspberrypi", getting:
<Guest98>
NOTE: Starting bitbake server...
<Guest98>
ERROR: No recipe named 'linux-raspberrypi' in your workspace
<Guest98>
What could be the reason for this?
Thorn has quit [Ping timeout: 256 seconds]
<AdrianTheFirst>
My build fails due to version-going-backwards error, even though I have added this exemption to INSANE_SKIP of my .bb file (actually a colleague of mine did a few weeks ago).
<AdrianTheFirst>
The strange thing is that those version-going-backwards errors disappear when I retry the build several time, or build the packages individually.
<AdrianTheFirst>
Also, when investigating this build failure, I saw that the error come from the functionbuildhistory_emit_pkghistory' from poky/meta/classes/buildhistory.bbclass. To my surprise, this quite long function does NOT honor or check the INSANE_SKIP variable. So it emits this version-going-backward error.
<AdrianTheFirst>
My question would be: doesnt this functionbuildhistory_emit_pkghistory function ought to check the INSANE_SKIP var before emitting the error?
<JaMa>
AdrianTheFirst: it's shown only once, because once the version went backwards (in buildhistory), it doesn't go backwards again
<JaMa>
AdrianTheFirst: if you don't care about version-going-backwards errors anywhere you can remove it from ERROR_QA or WARN_QA
<JaMa>
it's rarely recipe specific decision, either you want package manager to do the upgrades correctly or you don't care (e.g. with ostree or similar upgrade mechanisms with on-terget package management disabled)
<AdrianTheFirst>
I see. I our case, the version of our packages are set to PV = "1.0+git${SRCPV}", so we use the git commit hash as version and that can go up and down impredictably. So checking the version-going-backwards does not make sense for our version scheme, but we would like to keep it for all the other recipes... hence we added the INSANE_SKIP exemption.
<JaMa>
you should use PRserv to make sure SRCPVs are always increasing
<AdrianTheFirst>
Thanks for the hint, can you point me to the doc for PRserv?
<AdrianTheFirst>
Also, adding "version-going-backwards" to INSANE_SKIP seems to be a good match for our usecase. Why does it not work all the time?
<JaMa>
because it doesn't make sense to set it only for some recipes
bps2 has joined #yocto
<JaMa>
package-manager either can work or cannot, why would you want to install random versions of packages built from git on target?
<AdrianTheFirst>
It is not that one would want random versions, as I see it. But for flexibility, the build allows to skip the version check (could be because the version is not always increasing (our case) or that one want to temporarilly build with an older version, or any other project/recipe specific version...).
<AdrianTheFirst>
Thanks for the PR_Service link, I am reading it :-)
<JaMa>
yes, but it's not specific to this recipe, if you're not using PRserv for always increasing SRCPV than any recipe with SRCPV in PV has this issue
leon-anavi has joined #yocto
Thorn has joined #yocto
silbe has joined #yocto
Guest98 has quit [Quit: Client closed]
<frosteyes1>
Hi folks. I noticed that when trying to add gcc-arm-none-eabi to our SDK (using the meta-arm-toolchain layer from meta-arm), and adding TOOLCHAIN_HOST_TASK:append = "nativesdk-gcc-arm-none-eabi" that it fails with RPM packages
<frosteyes1>
With kirkstone (gcc 10) it is missing python2.7, and with master it is missing libcrypt.so.1
<frosteyes1>
nothing provides libcrypt.so.1()(64bit) needed by nativesdk-gcc-arm-none-eabi-12.2.rel1-r0.x86_64_nativesdk
frosteyes1 is now known as frosteyes
<frosteyes>
Anyone who have worked with meta-arm-toolchain, who have seen this and have some inputs. Else will properly need to dig deeper into it :)
vladest has joined #yocto
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #yocto
<rburton>
frosteyes: we've never tested that. obviously there's some python bits in there and the crypt thing is just annoying. as a meta-arm maintainer, i hate the binary toolchains.
<rburton>
frosteyes: try setting SKIP_FILEDEPS="1" in the gcc-arm-none-eabi recipe
<rburton>
if that works, please send a patch
frieder has quit [Ping timeout: 240 seconds]
<frosteyes>
rburton: will test send a patch if it works..
Guest36 has joined #yocto
<Guest36>
khem I got successfully build with https://github.com/mirzak/meta-coral(master). But, the device tree configuration for Coral Camera(OV5645) is missing. The camera is working with "zeus" branch, not working with "master" branch. How should i proceed to gain access to the camera. I'm not capable of typing device tree, i'm a rookie.
frieder has joined #yocto
Thorn_ has joined #yocto
Thorn has quit [Ping timeout: 240 seconds]
kpo has joined #yocto
AdrianTheFirst has quit [Quit: Client closed]
seninha has joined #yocto
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<frosteyes>
rburton: you got a patch for meta-arm
<rburton>
cheers
tgamblin has joined #yocto
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
<jbo>
hey guys. I'm working off a microchip (meta-atmel) example for the SAMA5D27-SOM1. I'd like to figure out how I can modify the device tree. How does one do that in yocto?
<jbo>
i.e. how would I locate the original/used DTS?
<tomzy_0[m]>
jbo: hey, you would like to customize the one you already use?
<jbo>
tomzy_0[m], yes. I'd just like to add an i2c device.
<jbo>
alright, time to understand the entire devtools workflow then :D
<tomzy_0[m]>
or just clone linux-mchp sources, checkout to the same commit used in Yocto which should be 5aedde3bc33b1337144f4db5d12204993d291b35 (taken from linux-mchp recipe - SRCREV), then modify that DTS, create patch and apply to your build
<jbo>
that... sounds easier
<jbo>
I just need to test some custom board
<tomzy_0[m]>
by adding bbappend for linux-mchp
<jbo>
I already created a custom layer to modify some of the linux-mchp stuff (mainly just adding packages like usb-utils)
<tomzy_0[m]>
for some it is easier, others may want to work with devtool :)
<tomzy_0[m]>
That's nice, so you are familiar of adding custom changes to already existed recipes by bbappends?
<jbo>
I wouldn't say that I am familiar by any means. I just successfully created an overlay with a bbappend for core-image-minimal to have some IMAGE_INSTALL:append in there
<tomzy_0[m]>
so what you would need after creating a patch, is bbappend to linux-mchp with DTS patch
<jbo>
my main problem is basically that I created a custom board for the SAMA5D27-SOM1. u-boot runs fine and the kernel starts loading stuff. even detects the on-board Quectel EC-25 modem. But once it wants to mount rootfs it fails. on a fast microSD card it kernel panics and on a slow one it shows either error -84 or error -110
<Entei[m]>
What's the difference between the rust recipes provided by yocto vs the one provided by meta-rust layer?
<tomzy_0[m]>
jbo: yeap that does not look good, maybe you need to diagnose the mmc driver and try the debug it - in this case Yocto is not necessary, just working with Linux driver, recompilation and checking what goes wrong - in case you would have some patch that fix this behavior, then you would need to apply it in Yocto
<jbo>
tomzy_0[m], I'm afraid it's more likely to be a PCB signal integrity issue
<tomzy_0[m]>
I do not have lot of experience with that, but well.. good luck with your project :) hopefully everything will end up fine
camus has quit [Ping timeout: 268 seconds]
<jbo>
jup
<jbo>
overall trace length is ~50mm on the SDIO interface tho
<jbo>
as in < 50mm
AndreRicardo has joined #yocto
frieder has quit [Ping timeout: 268 seconds]
d-s-e has joined #yocto
camus has joined #yocto
camus has quit [Ping timeout: 240 seconds]
Guest36 has quit [Ping timeout: 245 seconds]
camus has joined #yocto
xmn has joined #yocto
<jbo>
tomzy_0[m], I'm working on the DTS patching now. I think I understand the basics of it. I created a corresponding patch file. is there a way to check whether yocto/bitbake actually uses/applies the patch?
Chocobo has joined #yocto
<Chocobo>
has anyone ever experienced the "do_kernel_checkout" step taking around 40 minutes?
<Chocobo>
I am doing it in a docker image, running in a VM. Probably not ideal, but 40 minutes seems excessive.
<LetoThe2nd>
Chocobo: if its a large repo and the connection is slow, yes, it happens. Which kernel, specifically?
<Chocobo>
An analog devices fork of the Linux Xilinx kernel. :/ fork on fork
sakoman has joined #yocto
davidinux has quit [Quit: WeeChat 3.5]
<Chocobo>
I wish there was a way to cache the checkout - I wonder if I can fudge it by cloning the repo and pointing the recipe to my local repo.
<rburton>
JaMa khem don't merge those meta-oe g-i changes, they're bandaids for a trivial fix in core
davidinux has joined #yocto
<zeddii>
Chocobo. downloads are already cached, so unless you are doing a cleanall, it won't fetch each time. If it really is the file i/o on the checkout that is slowing things down, of course the local fetch won't help.
<Chocobo>
zeddii: It must be the file i/o ... I didn't do a cleanall. hrm, I guess I need to identify if it is docker or the vm doing it. The VM shows almost 0 disk activity which seems wrong.
<jbo>
Hey guys, I'm created a custom DTS patch which I'd like to include in my layer. After creating the patch and addit it to the bbappend file bitbake does not show any warning/error (anymore, after fixing some paths). However, after building the image the dts in my-build/tmp/work-shared/... does not show the changes. what can I do to figure out what is going wrong?
<jbo>
how can I figure out whether bitbake actually applies the patch?
<mcfrisk>
jbo: devshell in the recipe build tree, or "bitbake -e recipe" output to check that SRC_URI and tasks contain your changes
<jbo>
mcfrisk, what I do now is that my layer is being applied. I am just not sure about the DTS patch I created. would "bitbake -e recipe" show that explicitly?
davidinux has joined #yocto
goliath has quit [Quit: SIGSEGV]
user3924839 has joined #yocto
<user3924839>
Just wanted to point out the following which I've found on theyoctojester.info "Lets be honest, about nobody gets into YP technology “just for fun”. Its just not meant for it. So if you have a question or problem, then the chances are close to 100% that you are either doing this because it is your job, or - in a lower number of cases - some
<user3924839>
form of learning assignment." -> I'm doing it for fun :)
<user3924839>
cause the yp is fun!
frieder has joined #yocto
user3924839 has quit [Quit: Client closed]
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
targetdisk has joined #yocto
<kergoth>
Hmm, the Mojo language looks interesting. ML-focused, but the attributes that make it good for that would also make it potentially good for systems programming and embedded
<LetoThe2nd>
kergoth: did it get lost by Austin Powers?
frieder has quit [Ping timeout: 268 seconds]
<kergoth>
hah. It's pretty interesting in that it uses a capable IR, but it's a superset of python, not new syntax, and can opt-in to higher performance and the other features by adding strong type checking, using struct to pack types, etc. Skeptical, but seems promising. https://docs.modular.com/mojo/notebooks/HelloMojo.html#basic-systems-programming-extensions
ilunev has joined #yocto
Andre has joined #yocto
Andre is now known as Guest6310
Guest6310 is now known as AndreRicardo
bps2 has quit [Ping timeout: 240 seconds]
kscherer has joined #yocto
AndreRicardo has quit [Ping timeout: 245 seconds]
rfuentess has quit [Remote host closed the connection]
<rburton>
anything that talks about introspection in meta-oe, i have strong opinions on and will be sending patches to core
<JaMa>
khem: yes, both libblockdev and libpeas changes aren't needed with that oe-core change reverted (already tested that before sending them to meta-oe and reporting on that oe-core change)
<Chocobo>
I am trying to add an out-of-tree kernel module and this is what I get for an error, without any additional information in the log: ERROR: Task (/work/project/components/yocto/layers/core/meta/recipes-kernel/make-mod-scripts
<jbo>
Hey guys, I could really use some help. I am despreately trying to patch a DTS for the SAMA5D27-SOM1. Howeer, I seem to fail. What I have working is a custom overlay (meta-custom) which already adds some packages to the image. In the same layer, I created recipes-kernel/linux/linux-mchp_5.15.68.bbappend as well as recipes-kernel/linux/sama5d27-som1-ek-sd/0001-dts-mmc0.patch
<jbo>
however, I fail to verify that yocto is actually applying the patch.
seninha has quit [Remote host closed the connection]
seninha has joined #yocto
<jbo>
the only thing I do after adding that append/patch is bitbake core-image-minimal
<zeddii>
jbo: checking the kernel source isn't showing you your change as applied ? There's also a do_patch log in the kernel build directories, so you can see what quilt (or git) is showing
<jbo>
zeddii, I had a look at the build log and I don't see anything regarding applying of the DTS patch. How can I investigate this?
<zeddii>
a patch is a patch, it doesn't matter what you are patching.
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<zeddii>
so it will just be in the built/tmp/<yourmachine>/<your kernel>/temp/log.do_patch
<zeddii>
s/built/build/
<jbo>
hmm, that log doesn't show anything regarding my own patch.
<jbo>
how can I figure out which kernel _version_ I am using? I know about "oe-pkgdata-util lookup-recipe kernel" but that just prints linux-mchp lacking any kind of version information
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
<jbo>
duuuh. the patch was applied now. I was using the wrong linux kernel version in the bbappend file name
nemik has quit [Ping timeout: 240 seconds]
<rburton>
bitbake-layers has a show appends command to verify the right thing is happening easily
nemik has joined #yocto
<jbo>
thanks!
<zeddii>
:wq
<zeddii>
no exit for me!
nemik has quit [Ping timeout: 240 seconds]
<jbo>
heh :)
nemik has joined #yocto
Net147 has quit [Ping timeout: 265 seconds]
whuang0389 has joined #yocto
<whuang0389>
does yocto use wget to fetch tarballs? if so, how can I supply additional options to the fetch? I need to download artifacts behind a company server that requires passing in authorization token
<jbo>
whuang0389, some fetchers allow passing credentials
<whuang0389>
ty
<jbo>
> "If a username and password are specified in the SRC_URI, a Basic Authorization header will be added to each request, including across redirects."
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Net147 has quit [Ping timeout: 268 seconds]
florian__ has joined #yocto
xmn has quit [Ping timeout: 240 seconds]
florian__ has quit [Ping timeout: 256 seconds]
seninha has quit [Remote host closed the connection]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
bps2 has joined #yocto
<Chocobo>
I am trying to build an out-of-tree kernel module, and it is failing because it can't find the makefile on the do_compile mode. Is there a way I can stage up everything for compiling and see what is going wrong? I don't really know a good way to debug what is happening.
<Chocobo>
I think I figured why it is failing, but I don't know how to fix it. It looks like all the source files are stored in directory named "git" but the Make command is being executed one directory up.
<rburton>
Chocobo: sounds like your recipe sets S=WORKDIR
<rburton>
Chocobo: set S="${WORKDIR}/git" to tell it that sources were checked out in a directory called git (which is where the git fetcher puts a clone unless told otherwise)
florian__ has joined #yocto
prabhakarlad has joined #yocto
<Chocobo>
Let me give it a shot. That is probably it. Thanks
<Chocobo>
ugh. That did it. Thanks
sakoman has quit [Quit: Leaving.]
mvlad has quit [Remote host closed the connection]
nemik has quit [Ping timeout: 256 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 240 seconds]
nemik has joined #yocto
whuang0389 has quit [Quit: Client closed]
<Chocobo>
So, if I wanted to override where sources were unpacked (${WORKDIR}/git) to something else how could I do that? I want to modify the recipe for development to point to the filesystem
<rburton>
the answer to what you *want* is to use externalsrc, look it up in the docs
<Chocobo>
rburton: I did it a bit different... I did "inherit externalsrc" and then set EXTERNALSRC and EXTERNSRC_BUILD in the recipe itself. It works like a charm though
vladest has quit [Quit: vladest]
vladest has joined #yocto
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
florian__ has joined #yocto
<kergoth>
paulg: if you set WKS_FILE to a .wks.in you can use bitbake variable references in the file, simplistic templating mechanism using a bitbake variable intermediate
<kergoth>
other than that i'd check the kickstart file documentation for the syntax.. hmm
<paulg>
yeah I went down the kickstart docs rathole for a while.
<paulg>
I think I might have found an alternate way - hacking it together now.
<paulg>
Of course I fully expect it to catch fire and completely leave me frustrated and back at Square One.