invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
amitk has joined #yocto
sakoman has quit [Quit: Leaving.]
BoJalling has quit [Ping timeout: 265 seconds]
BoJalling has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
thomasd13 has joined #yocto
lexano has quit [Ping timeout: 268 seconds]
lexano has joined #yocto
yssh has joined #yocto
yssh has quit [Client Quit]
yssh has joined #yocto
BoJalling has quit [Ping timeout: 268 seconds]
BoJalling has joined #yocto
goliath has joined #yocto
<landgraf>
fray: window is wrong but the message is proper one :)
<landgraf>
fray: window is wrong but the message is proper one :)
<landgraf>
\
goliath has quit [Quit: SIGSEGV]
alessioigor has joined #yocto
yssh77 has joined #yocto
yssh77 has quit [Client Quit]
yssh has quit [Ping timeout: 260 seconds]
yssh has joined #yocto
BoJalling has quit [Ping timeout: 264 seconds]
BoJalling has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
frieder has joined #yocto
goliath has joined #yocto
<LetoThe2nd>
yo dudX
olani- has quit [Ping timeout: 268 seconds]
olani- has joined #yocto
lars_ has joined #yocto
AKN has quit [Ping timeout: 265 seconds]
<mckoan>
good morning
zpfvo has joined #yocto
<jclsn>
Morgään
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #yocto
BoJalling has quit [Ping timeout: 250 seconds]
xmn has quit [Ping timeout: 250 seconds]
BoJalling has joined #yocto
xmn has joined #yocto
me73 has joined #yocto
Xagen has quit [Ping timeout: 246 seconds]
leon-anavi has joined #yocto
AKN has joined #yocto
olani- has quit [Ping timeout: 255 seconds]
frwol has joined #yocto
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #yocto
BoJalling has quit [Remote host closed the connection]
rob_w has joined #yocto
<michaelo>
./hello
Guest68 has joined #yocto
prabhakarlad has joined #yocto
<me73>
'llo. yocto newbie question, this is my first yocto project. I have an error that ends in "The variable dependency chain for the failure is: do_fetch[file-checksums]". I suspect I should somehow specify the checksum(s). Based on this error : is this correct ?
<me73>
this is while downloading some python module.
<me73>
my problem is that I have 2 files to download, so how should I calculate (and specify) "the" checksum ?
mischief has quit [Ping timeout: 246 seconds]
yssh has quit [Ping timeout: 260 seconds]
florian has joined #yocto
mischief has joined #yocto
<RP>
me73: you'd have two entries in SRC_URI and a checksum for each file?
<me73>
yes, that's my plan
<me73>
(unless this wouldn't be possible, of course)
<me73>
well, now that I see your question, it's actually not 2 files, but rather packages
<qschulz>
me73: do you have a recipe tyou can share?
<me73>
2 packages (pyserial and pyserial-asyncio), bot downloadeed from git
<me73>
yes
<qschulz>
me73: create one recipe for each I believe
<me73>
is it good practice to paste it here (suspect not) ?
<qschulz>
me73: thanks for asking, no, please use a pastebin
<me73>
so to be split it in 2 recipes, you already mentioned ?
xmn has quit [Quit: ZZZzzz…]
d-s-e has joined #yocto
<qschulz>
me73: a recipe is for anything related to a specific piece of sw
<qschulz>
usually needing to specify multiple sources is a good tell it should be split into more recipes
<qschulz>
and have one depend on the other for example
<qschulz>
it seems to me those are separate projects, so a separate recipe makes sense
Guest68 has quit [Ping timeout: 260 seconds]
<qschulz>
me73: to answer your earlier question, you don't need SRC_URI checksum for sources gotten via git fetcher
<qschulz>
me73: the URL for git repo should start with git:// and not https://
<qschulz>
because it is technically NOT a URL
<qschulz>
https:// (or git://) is the prefix for a "fetcher"
<qschulz>
so https tells bitbake to use wget
<qschulz>
and git:// to use git
<qschulz>
you want to use git, so use git://
<qschulz>
second, if you have multiple git repos to get in one recipe (pretty rate)
<me73>
OK. does the fetcher checksum the data then ? Or how is the mechanism behind this checksumming thing ?
<qschulz>
you need to give each git URI its own name
<qschulz>
me73: it's part of git to guarantee the data is sane
<qschulz>
me73: that would be github.com/pyserial/pyserial.git;branch=master;name=pyserialgit
<qschulz>
then, use SRCREV_pyserialgit = "<pyserialcommithash>"
<qschulz>
finally, use branch or tag but not both (use the former)
<me73>
OK. So the version I need is in the master branch, and of that master branch, git takes the commit with that specific SRCREV_pyserialgit. Correct ?
<qschulz>
me73: correct, but I'm explaining the case where you have two git repos (which you won't have anymore)
<qschulz>
so it's simply SRCREV
<me73>
Yes, these recipes have been split already :]
<mischief>
pyserial is already in meta-openembedded layer btw
<qschulz>
mischief: I was about to point this out :)
<qschulz>
me73: there already exists a recipe for pyserial
<qschulz>
and pyserial-asyncio
<me73>
so I am doing superfluous things here :/
<qschulz>
for a very long time for pyserial, only since kirkstone for asyncio
<qschulz>
me73: yes :)
<qschulz>
but maybe you need to update it or backport to your version of yocto
<mischief>
depends if you want to use that layer or not.
<me73>
yes, we do
<me73>
so on the target, a python statement "import pyserial" or "import pyserial-asyncio" should already work ...
zpfvo1 has joined #yocto
<me73>
good to know
<me73>
how could I have found this out (it's a whole lot of files out there) ?
<mischief>
the layer index is a good start
<me73>
bblayers.conf yo umean ?
<mischief>
the link from qschulz above
<mischief>
you need to actually depend on that recipe for it to be in the target image.
zpfvo has quit [Ping timeout: 255 seconds]
<me73>
I missed that link while typing, I'll have a look. Thank you both for the inputs. I am at sea level +100ft now, climbing the Everest... :)
pope has joined #yocto
<pope>
Hi all, I strugling for days now set get my raspberry pi 3b to boot the kernel image I've created with yocto though tftp and I don't know why. Anyone who might could help?
<pope>
None actually, kernel is just not booting and the green led is constantly flashing twice...
<pope>
I'm not sure if I'm using the right image, but it seems as it's booting exactly the same image from the sd card successfully
<LetoThe2nd>
pope: do you get "uncompressing kernel"? is earlyprintk enabled and all that?
<pope>
I think the kernel is already uncompressed, right?
<pope>
Where would I enable the earlyprintk?
<LetoThe2nd>
pope: no, the kernel is almost always compressed, and the line "Uncompressing kernel..." is usually the first sign of life that it gives on the terminal
<LetoThe2nd>
pope: earlyprintk is a kernel config option, respectively command line flag
gsalazar has joined #yocto
<pope>
Okay, thought only uImage and zImage are compressed, cause when booting from sd card I also don't see the "uncompressing kernel" message
<pope>
Can I check if the kernel that is used by yocto has the earlyprintk option enabled?
<LetoThe2nd>
pope: but you're on a serial terminal?
<pope>
yes
<LetoThe2nd>
pope: so how did you actually "build the kernel with yocto"?
<polprog>
how do i go about troubleshooting why yocto is not using my recipe? It was working yesterday and now i re-run the build and my recipe is clearly not being used
<pope>
I think I didn't explicitely build the kernel, I just run "bitbake core-image-base" and use the Image.bin that is located in the build artifacts
<mckoan>
pope: edit config.txt with a text editor At the bottom, last line, add enable_uart=1 on it's own line
<LetoThe2nd>
polprog: how do you diagnose "not using"?
<pope>
mckoan: but Uart is working fine I think...
<polprog>
LetoThe2nd: i have a recipe that puts a file in /etc/dropbear and i know it works, now when i re-ran the build /etc/dropbear is empty again
<mckoan>
pope: not after kernel started
<polprog>
i suspect it might have to do with IMAGE_INSTALL, im not sure where exactly local.conf should be placed
<LetoThe2nd>
polprog: huh?
<polprog>
i know as
<pope>
mckoan: you're refering to config.txt that is located on the boot partition of the sd card?
<polprog>
i know as much that last time i fonally got it to work and create the files. Today i re-run the build and the directory in rootfs.cpio.gz is empty again
<LetoThe2nd>
pope: no mass pasting in here, please.
<pope>
sorry
<pope>
but the amount of bytes is correct
<pope>
and the address should be fine as well...
olani- has joined #yocto
<pope>
Can you confirm that the Image.bin that yocto (or bitbake) created in my deploy/images/raspberry/ folder actually is the kernel image?
<LetoThe2nd>
pope: if iminfo fails, then your problem is somewhere earlier. is 200000 a known good memory location? i've never needed such for the raspi, so somebody else please check.
<pope>
Cause on the sd card I also have a kernel8.img but I don't know what that is...
<pope>
hmmm... that's the loadaddr which is defined in the default uboot env created by yocto, so I assumed it's correct
<polprog>
you can run the file command on these images and it should tell you what they are
<pope>
polprog: what "file command" do you mean?
<polprog>
just run "file /deploy/images/raspbperry/whatever.bin"
<polprog>
file is a unix command that tells you what the file has inside
<pope>
ah, sorry, was not sure if you're talking host or target, I'm not yet too deep into linux :/
<pope>
Yes, thees to be a linux kernel arm64 boot executable
<pope>
*seems
Xagen has joined #yocto
<pope>
I'll try to figure out if it's a problem with the addr, but don't see why this could be an issue...
Xagen has quit [Ping timeout: 260 seconds]
amsobr has joined #yocto
me73 has quit [Quit: Client closed]
davidinux has quit [Ping timeout: 265 seconds]
davidinux has joined #yocto
Guest68 has joined #yocto
Guest68 has quit [Ping timeout: 260 seconds]
d-s-e has quit [Ping timeout: 255 seconds]
Xagen has joined #yocto
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #yocto
Xagen has quit [Ping timeout: 268 seconds]
kergoth has quit [Ping timeout: 252 seconds]
kergoth has joined #yocto
<pope>
Could it be that iminfo only works for uImage format?
Xagen has joined #yocto
xmn has joined #yocto
florian_kc has joined #yocto
lars_ has quit [Quit: leaving]
<landgraf>
WARNING: linux-yocto-6.1.14+gitAUTOINC+e8d08fc4c0_b05ca3429c-r0 do_fetch: Failed to fetch URL git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=v5.15/standard/bcm-2xxx-rpi;, attempting MIRRORS if available
<landgraf>
and it takes few hours
d-fens_ has joined #yocto
<paulg>
the kernel is a giant blob of data download, and it sucks if you aren't well connected. :-(
<LetoThe2nd>
paulg: it also sucks if you are well connected.
<paulg>
LetoThe2nd, true.
<rburton>
landgraf: its the mirror download that takes forever, if it hits that just abort
<rburton>
that branch does exist though...
<landgraf>
paulg: usualy it works... in that case I've tried few times and it aborts after 2-3 hours
<landgraf>
fetcher reports 1.2 M/s
<ptsneves>
what is the reason that the kernel recipes are not shallow cloning by default?
<rburton>
ptsneves: you can't expand a shallow clone so you'll need to refetch on every sha bump
<rburton>
or some other limitation
<rburton>
can't remember
<rburton>
its in the git log :)
me65 has joined #yocto
<me65>
which is the best/suggested way to use another keymap with runqemu ? Looked into it, but I doubt if tweaking the script itself is clean enough...
<me65>
I think I'd need to use the -k parameter...
<ptsneves>
rburton: assuming the bump is forward in time wouldnt I need to fetch anyway most of the times?
<rburton>
ptsneves: sure but you just fetch the new objects
<ptsneves>
rburton: the same as in the shallow case.
<ptsneves>
My point is that very few people actually need to download the whole repo in the context of bitbake builds. I guess that is the reasoning why we prefer tarballs
<rburton>
the kernel is a problematic example for sure
d-s-e has joined #yocto
sakoman has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
florian_kc has quit [Ping timeout: 265 seconds]
d-s-e has quit [Ping timeout: 246 seconds]
<RP>
ptsneves: mirroring in particular gets really hard with shallow clones
<ptsneves>
RP: Ah, that is something i never considered.
florian has quit [Quit: Ex-Chat]
starblue has quit [Ping timeout: 264 seconds]
yssh has joined #yocto
starblue has joined #yocto
<RP>
ptsneves: basically it becomes a mirror tarball per revision, which has pros and cons
<ptsneves>
Indeed. Has anybody ever benchmarked what would be the speedup if shallow was globally set?
<RP>
no, we don't tend to benchmark fetching as it is so network dependent
<ptsneves>
But if all the fetching would happen through local file mirror, i would expect shallow extraction speed up to be measurable. Maybe i will come to it one day
AKN has quit [Read error: Connection reset by peer]
<RP>
ptsneves: we clone by reference iirc so I doubt it would help much
<fneddy>
hello. is there a possibillity to run `make scripts_gdb` in a `devtool modify virtual/kernel` enviroment?
pope has quit [Quit: Client closed]
<fneddy>
or as an alternative. is it possible to run devshell in an devtool modify enviroment
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<fneddy>
ok nevermind. i can run bitbake virtual/kernel -c devshell and it will enter the devtool enviroment. i was misslead to belive that after i use devtool modify i cannot use bitbake anymore until i finish or reset the devtool evniroment
fneddy has quit [Quit: fneddy]
lamm has quit [Ping timeout: 255 seconds]
prabhakarlad has joined #yocto
seninha has joined #yocto
<fury>
i'm trying to build a custom image for a raspberry pi 0w that can act as a bluetooth source and sink. i've added pulseaudio modules bluetooth-discover and bluetooth-policy to the image (via packagegroup-tools-bluetooth) and confirmed they are loaded in via pacmd list-modules. however, systemctl status bluetooth does not indicate that it is creating the A2DP endpoints, and bluetoothctl connect or pair fails. any ideas?
<fury>
kinda lost, and googling this on the bing is about useless because of all the tutorials on how to set up bluetooth on conventional OSes like raspbian
<fury>
normally when those modules start up on something like raspbian, the bluetooth service indicates that A2DP source and sink endpoints are created
starblue has quit [Ping timeout: 246 seconds]
<fury>
raspbian just sorta "works" out of the box for this purpose, but i have other issues like it's not staying connected to my sink device (a custom "soundbar" board built around an esp32), so i figured i'd try building everything from scratch on just about the newest yocto i could get working, which was honister, using boot2qt 6.3
florian has joined #yocto
<fury>
all attempts at building 6.4 or 6.5 (kirkstone / langdale) failed miserably, and i already had to hack up 6.3 quite a bit to get it built, i'm gonna be so sad if the bluetooth doesn't wind up working any better than raspbian buster :(
<fury>
if i can even get to that point
zpfvo has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
lamm has joined #yocto
<kanavin_>
fury, any particular reason you need to use boot2qt?
<kanavin_>
if you just want a rpi compatible image use poky + meta-raspberrypi
<fury>
kanavin_: I have a companion app that controls the Bluetooth devices once they're connected, it's written in Qt, it seemed to make sense to use boot2qt but after fighting with it for a couple weeks I now realize it was probably a mistake to start there
<fury>
I can probably just skip out on all the boot2qt fun, and figure out on my own how to put all the necessary qt things in there
kscherer has quit [Quit: Konversation terminated!]
alessioigor has joined #yocto
olani- has quit [Ping timeout: 264 seconds]
alessioigor has quit [Quit: alessioigor]
roussinm has quit [Quit: WeeChat 3.0]
amitk_ has quit [Ping timeout: 250 seconds]
<RP>
I meant to ask about the mesa changes on the call today. I'm leaning to merging them before release FWIW...
invalidopcode1 has quit [Read error: Connection reset by peer]
invalidopcode1 has joined #yocto
florian has joined #yocto
<JaMa>
RP: I don't have strong opinion about mesa, but are the selftest fixes postponed to next release as well?
<JaMa>
I wouldn't mind, just curious as they were in master-next and before that in abelloni's staging branch for a while and I was waiting with the next batch until they are merged
<RP>
JaMa: I'm still thinking about them, I wanted to check a couple of things
goliath has quit [Quit: SIGSEGV]
<RP>
JaMa: I merged the ptest pieces as my criteria for accepting those was much easier/clearer and the patches were simpler given the amount of staring at ptests I've done recently
<JaMa>
RP: OK, fair enough, FWIW: I have few more improvements for runqemu.* tests and for the esdk I've verified that if I build my own uninative-tarball with gcc-13 (and enable uninative on my host with gcc-13) than esdk tests pass as well, so it's really just broken whenever uninative is disabled (for whatever reason) it seems, I'll continue to debug this one
<RP>
JaMa: I was noticing one of the bbtests was failing for me locally but passes on the autobuilder :/
<RP>
JaMa: disabling uninative shouldn't break the tests so that is something we need to look into and try and fix
<JaMa>
but will re-trigger it again just in case I can reproduce it
davidinux has quit [Ping timeout: 268 seconds]
<RP>
JaMa: I guess the other things about the patch series I wanted to look into was whether we could make uppercase modules hard fail
<JaMa>
that's part of the next batch
<JaMa>
or at least I didn't forget about you wanting it :)
<RP>
JaMa: ok, cool, thanks
<JaMa>
Parsing recipes...ERROR: /OE/build/poky/build-bbtests/build-st/meta-selftest/recipes-test/gitunpackoffline/gitunpackoffline.bb: AUTOREV/SRCPV set too late for the fetcher to work properly, please set the variables earlier in parsing. Erro
<JaMa>
ring instead of later obtuse build failures.
<RP>
which is what it is supposed to fail with iirc
<RP>
it is entirely possible I've corrupted my local build somehow
<JaMa>
I mean the test is failing now
<RP>
JaMa: ah, interesting. I wonder if it works the first time but not subsequently
<JaMa>
got 2 failures in row (using separate build dirs for each) so either that's the reproducer or I'm just the "lucky" one (FML)
<JaMa>
:)
<JaMa>
will have a look tomorrow, still have few chromiums to build today
<JaMa>
it was really stupid idea to finally remove a "temporary work around" from 12 years ago, EVERYBODY got used to the work around being there and now I'm fixing 80th component depending on it (while 12 years ago there was presumably 1 last component to migrate)
florian has quit [Ping timeout: 255 seconds]
<RP>
JaMa: temporary things like that are a nightmare. I'm sure bitbake has a few :/
<RP>
JaMa: vmeson introduced me to the concept of chromium mines which I now picture anytime someone mentions chromium work :)