ndec changed the topic of #yocto to: "Welcome to the Yocto Project | Learn more: https://www.yoctoproject.org | Join us or Speak at Yocto Project Summit (2022.11) Nov 29-Dec 1, more: https://yoctoproject.org/summit | Join the community: https://www.yoctoproject.org/community | IRC logs available at https://www.yoctoproject.org/irc/ | Having difficulty on the list or with someone on the list, contact YP community mgr ndec"
florian_kc has quit [Ping timeout: 256 seconds]
gsalazar has quit [Ping timeout: 252 seconds]
sakoman has quit [Ping timeout: 255 seconds]
nemik has quit [Ping timeout: 255 seconds]
nemik has joined #yocto
nemik has quit [Ping timeout: 260 seconds]
nemik has joined #yocto
sakoman has joined #yocto
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #yocto
shoragan has quit [Quit: quit]
OnkelUlla has quit [Read error: Connection reset by peer]
shoragan has joined #yocto
OnkelUlla has joined #yocto
argonautx[m] has joined #yocto
davidinux has quit [Ping timeout: 252 seconds]
davidinux has joined #yocto
prabhakarlad has quit [Quit: Client closed]
seninha has quit [Quit: Leaving]
seninha has joined #yocto
amitk has joined #yocto
jclsn has quit [Ping timeout: 252 seconds]
jclsn has joined #yocto
gho has quit [Ping timeout: 265 seconds]
rsalveti has quit [Quit: Connection closed for inactivity]
gho has joined #yocto
PhoenixMage has quit [Ping timeout: 256 seconds]
PhoenixMage has joined #yocto
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #yocto
seninha has quit [Ping timeout: 268 seconds]
Wouter0100670 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670 has joined #yocto
xmn_ has quit [Ping timeout: 256 seconds]
alessioigor has joined #yocto
chep has quit [Read error: Connection reset by peer]
chep` has joined #yocto
chep` is now known as chep
davidinux has quit [Ping timeout: 268 seconds]
davidinux has joined #yocto
sakoman has quit [Quit: Leaving.]
demirok has joined #yocto
olani- has quit [Ping timeout: 252 seconds]
alicef_ is now known as alicef
goliath has joined #yocto
rob_w has joined #yocto
marek44 has joined #yocto
thomasd13 has joined #yocto
frieder has joined #yocto
amitk_ has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
Schlumpf has joined #yocto
goliath has quit [Quit: SIGSEGV]
rfuentess has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
rfuentess has quit [Remote host closed the connection]
rfuentess has joined #yocto
zpfvo has joined #yocto
gho has quit [Quit: Leaving.]
zpfvo has quit [Client Quit]
zpfvo has joined #yocto
amitk has joined #yocto
zpfvo has quit [Ping timeout: 264 seconds]
leon-anavi has joined #yocto
zpfvo has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
Jham has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
* alessioigor waves all
invalidopcode1 has joined #yocto
prabhakarlad has joined #yocto
Payam has joined #yocto
goliath has joined #yocto
nemik has quit [Ping timeout: 268 seconds]
nemik has joined #yocto
zpfvo has quit [Ping timeout: 260 seconds]
zpfvo has joined #yocto
ptsneves has joined #yocto
<qschulz> o/
<abelloni> \o
<landgraf> (^_^)/
rob_w has quit [Ping timeout: 260 seconds]
tomzy_0 has joined #yocto
<ptsneves> what is the reason that adding a package to RDEPENDS without the lib32- prefix leads to bitbake trying to install the lib32- prefixed version?
<RP> ptsneves: it probably remapped the RDEPENDS to the lib32 version if it was a lib32 package?
<ptsneves> RP: in the recipe i do not see any indication of this remapping. What can cause this remapping?
florian_kc has joined #yocto
<qschulz> ptsneves: I'm wondering if it's not the same mechanism more or less than what happens to recipes when you use the native version of it
<qschulz> native- gets prepended to all packages
<ptsneves> basically i have 'qemu-wrlinux-image-core' becomes 'lib32-qemu-wrlinux-image-core' just by adding a single package that is not lib32
<ptsneves> if i call the recipe manually it also does not seem to build the lib32 version
<qschulz> ptsneves: bitbake -g <your-image> to see what brings it in?
<ptsneves> it fails. I think it has to do with a COMPATIBLE_HOST declaration..
Bardon_ has joined #yocto
<ptsneves> which led me to read about what exactly is the difference between COMPATIBLE_HOST and COMPATIBLE_MACHINE
Bardon has quit [Ping timeout: 260 seconds]
seninha has joined #yocto
rfuentess has quit [Read error: Connection reset by peer]
rfuentess has joined #yocto
<alessioigor> If I add 'api-documentation' in the DISTRO_FEATURES on dunfell I obtain this error:
<alessioigor> ERROR: ec-sdk-1.0-r0 do_populate_sdk: Postinstall scriptlets of ['util-linux-doc'] have failed. If the intention is to defer them to first boot,
<alessioigor> then please place them into pkg_postinst_ontarget_${PN} ().
Schlumpf has quit [Ping timeout: 260 seconds]
<alessioigor> Deferring to first boot via 'exit 1' is no longer supported.
<alessioigor> What did I do wrong?
mvlad has joined #yocto
florian_kc is now known as florian
andrewzaza[m] has joined #yocto
d-fens_ has joined #yocto
Wouter0100670 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670 has joined #yocto
<d-fens_> re, new task at hand is to add a user "pi" to the build and clone a git repo into a subdir "source" of pi's homedir, i searched layer.openembedded for add user and found adduser 3.118 with perl deps and not for raspi i guess, what whould be agood approach to look for such stuff that certainly has already working solutions somehwre?
<LetoThe2nd> d-fens_: its a combination of two things. first, adding a user. an example would be https://github.com/TheYoctoJester/meta-containerization/blob/master/recipes-core/payload-user/payloaduser.bb
ptsneves1 has joined #yocto
<LetoThe2nd> d-fens_: secondly, adding the source stuff. that would be a recipe that incorporates this user creation, pulls the source (please use SRC_URI), and copies it over. see https://stackoverflow.com/questions/39980145/how-to-install-recursively-my-directories-and-files-in-bitbake-recipe/47084404#47084404 for the copying part.
<d-fens_> ah should taht be two receipts with the second being run only after the first or go into one file?
<LetoThe2nd> d-fens_: you can probably put it into one recipe unless you have more stuff that also relies on the user to be present.
<LetoThe2nd> d-fens_: extra brownie points fot making it an allarch recipe and properly making compile and configure tasks no-op
<d-fens_> LetoThe2nd: thx! will do my best :)
<LetoThe2nd> d-fens_: have fun!
alex88_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
alex88 has joined #yocto
yann has quit [Ping timeout: 260 seconds]
seninha has quit [Remote host closed the connection]
rob_w has joined #yocto
gsalazar has joined #yocto
Schlumpf has joined #yocto
demirok has quit [Quit: Leaving.]
Schlumpf has quit [Quit: Client closed]
Schlumpf has joined #yocto
invalidopcode1 has quit [Remote host closed the connection]
invalidopcode1 has joined #yocto
<kayterina[m]> Hello, is it logical that bitbake --no-setscene will read from dependency cache? What is dependency cache, I did not find it in documentation.
demirok has joined #yocto
florian_kc has joined #yocto
xmn has joined #yocto
demirok has quit [Ping timeout: 256 seconds]
demirok has joined #yocto
louis has joined #yocto
louis is now known as louson
<ptsneves> kayterina[m]: setscene is about task caching while dependency cache is likely about parsing cache.
<kayterina[m]> I am testing MIRRORS, so I build without sstate. Parsing cache should not concern me in this context, correct?
davidinux has quit [Ping timeout: 260 seconds]
davidinux has joined #yocto
ptsneves1 has quit [Ping timeout: 252 seconds]
<rburton> correct
<rburton> its just a cache of parsed recipes
lamm_ is now known as lamm
<andrewzaza[m]> hi in my porject
<andrewzaza[m]> the kernel provider deploys the kernel images both as files in boot (via the boot files deployment mechanism) and in the root partition (via the packing system in yocto). so we are having duplication
<andrewzaza[m]> I'm interested in removing the kernel image from the boot partion on my efi-systems (since its not needed for booting)
<andrewzaza[m]> as first hint i looked into oe/meta/kernel-recipes but I wasn't able to locate what is installing the kernel image into the boot partition. not even in the classes
<andrewzaza[m]> maybe WIC is installing it ?
<andrewzaza[m]> anyone knows about this ?
d-fens has joined #yocto
Wouter01006704 has joined #yocto
<andrewzaza[m]> for example if I build for MACHINE=qemux86-64 runqemu oniro-image-base wic ovmf slirp nographic... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/be37010877e2ceb2c471af210371281674fd0e56>)
pbsds6 has joined #yocto
alinucs has joined #yocto
jamestperk_ has joined #yocto
ptsneves1 has joined #yocto
schtobia_ has joined #yocto
agrue_ has joined #yocto
kscherer has joined #yocto
yann has joined #yocto
derRicha1d has joined #yocto
polprog_ has joined #yocto
|Xagen has joined #yocto
marex_ has joined #yocto
dlan_ has joined #yocto
mckoan_ has joined #yocto
qschulz_ has joined #yocto
jclsn_ has joined #yocto
v0n has joined #yocto
erik__ has quit [Quit: Leaving]
d-fens_ has quit [*.net *.split]
Wouter0100670 has quit [*.net *.split]
florian has quit [*.net *.split]
ptsneves has quit [*.net *.split]
pbsds has quit [*.net *.split]
jclsn has quit [*.net *.split]
tangofoxtrot has quit [*.net *.split]
alinucs_ has quit [*.net *.split]
dlan has quit [*.net *.split]
qschulz has quit [*.net *.split]
mckoan has quit [*.net *.split]
agrue has quit [*.net *.split]
schtobia has quit [*.net *.split]
Xagen has quit [*.net *.split]
jamestperk has quit [*.net *.split]
polprog has quit [*.net *.split]
marex has quit [*.net *.split]
derRichard has quit [*.net *.split]
pbsds6 is now known as pbsds
vvn has quit [*.net *.split]
ptsneves1 is now known as ptsneves
Wouter01006704 is now known as Wouter0100670
jamestperk_ is now known as jamestperk
florian has joined #yocto
tangofoxtrot has joined #yocto
florian_kc has quit [Ping timeout: 252 seconds]
rsalveti has joined #yocto
vladest1 has joined #yocto
<d-fens> hmm is there any special trick to make SRC_URI = "git://git@bitbucket.org/projectname/repository.git;user=usename:app_password;protocol=https;" work?, it fails with : could not read Password for 'https://git@bitbucket.org': No such device or address
florian_kc has joined #yocto
vladest has quit [Ping timeout: 268 seconds]
<rburton> its probably ignoring the user= as you specify the user git@ at the beginning
vladest1 has quit [Ping timeout: 246 seconds]
sakoman has joined #yocto
dmoseley has joined #yocto
dmoseley_ has quit [Ping timeout: 260 seconds]
<d-fens> seems that this just doesn't work with bitbucket app_passwords https://stackoverflow.com/questions/71014333/using-bitbucket-app-password-in-yocto-recipe-for-git-repo-over-https and they are moveing from ssh key which are also not easy to use in avi pieline
<d-fens> s/avi/CI
<d-fens> seems i have to drop SRC_URI and do a git clone https://username:app-password@bitbucket.org/dir/repo.git
amitk has quit [Ping timeout: 252 seconds]
dmoseley has quit [Ping timeout: 246 seconds]
dmoseley_ has joined #yocto
<KareemZarka[m]> hi qschulz:
<KareemZarka[m]> I'm not able to use the script you provided... https://paste.ack.tf/6c6926
<KareemZarka[m]> > <@kzarka:matrix.org> hi qschulz:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/caec01bbbb04e4a54c4f5d5eff227c8637c79ccd>)
<KareemZarka[m]> it fails as the source is bootimg-efi and not rootfs
<qschulz_> KareemZarka[m]: your current wks has nothing in common with what I suggested so I'm quite confused?
qschulz_ is now known as qschulz
dmoseley_ has quit [Ping timeout: 252 seconds]
yann has quit [Ping timeout: 268 seconds]
dmoseley has joined #yocto
<KareemZarka[m]> <qschulz_> "Kareem Zarka: your current wks..." <- so I replaced... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/b7df8612f0016956117e38e1121a603dcd7623e0>)
<KareemZarka[m]> qschulz_:
dmoseley has quit [Excess Flood]
dmoseley has joined #yocto
dmoseley has quit [Ping timeout: 260 seconds]
marek44 has quit [Quit: Client closed]
dmoseley has joined #yocto
rob_w has quit [Remote host closed the connection]
marex_ is now known as marex
seninha has joined #yocto
<dacav_> Hi. I was wondering if it is normal for everyone that bitbake will spend minutes in "Parsing recipes". Is it something broken in my setup, or is it everyone's everyday experience?
dacav_ is now known as dacav
<dacav> (it is quite problematic, since I'm writing a bbclass. Syntax errors in python will make me wait minutes...
<qschulz> dacav: it depends on your PC configuration and how many recipes are available in your layers
<qschulz> dacav: inherit your bbclass only in one recipe for starters
<ptsneves> @dacav it can also be that you are trying to reach a state cache server or hashserv which is very slow
<qschulz> ptsneves: IIRC dacav is writing a bbclass that is added in INHERIT, so all recipes need to be reparsed for every change in the bbclas
<rburton> you can still inherit it in one recipe for experimenting unless you're doing something very special
<ptsneves> even so a reparse of several minutes should not be a usual thing
<ptsneves> rburton: yeah it is a good suggestion.
<rburton> several minutes is feasible if you have a very slow machine
<rburton> if the class is large you can just put the code in a python module in lib/ and have a minimal class that just calls into it
<sudip> dacav: I have "several minutes" delay while parsing recipe on a machine which has ipv6.
goliath has quit [Quit: SIGSEGV]
<rburton> do you have autorev recipes?
<rburton> they'll need a network op
<rburton> otherwise the sockets are all local so you shouldn't have problems with ipv6
<rburton> if you can replicate hangs and can isolate it to v6 causing problems and you're confident its not your network then do file a bug
Schlumpf has quit [Quit: Client closed]
Wouter0100670 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01006704 has joined #yocto
<vvmeson> dacav: $ time bitbake -p -k world -> real 1m14.303s -- 74 layers in conf/bblayers.conf not including some layers that are download layers. -- 24 core box that is ~ 10 years old.
<vvmeson> same box, just poky: 0m14.079s
thomasd13 has quit [Ping timeout: 246 seconds]
<vvmeson> finally: 192 vCore box, 74 layers: real 0m43.522s
<vvmeson> A few weeks ago, I ran a test to vary BB_NUMBER_PARSE_THREADS on this 192 core system and from what I recall, every cpu helped.
dgriego has quit [Quit: dgriego]
<dacav> thank you all. It happens regardless of my bbclass. I will check the state cache server. Learn what that is first.
<dacav> my computer is not so old
<dacav> but I suspect our yocto set up is poorly made. I wish I could start over fresh
<sudip> rburton: yes, I am confident its ipv6. I have done a strace on it and verified.
<sudip> also on the same machine if I disable ipv6 its very fast
<rburton> sudip: what is it connecting to?
<KareemZarka[m]> > <@kzarka:matrix.org> so I replaced... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/9a74083d8243bbdee764e9f225e8a630b2df4cb8>)
florian_kc has quit [Ping timeout: 260 seconds]
alessioigor has quit [Quit: alessioigor]
rfuentess has quit [Remote host closed the connection]
<moto-timo> jonmason: -vga std: Standard VGA card with Bochs VBE extensions. If your guest OS supports the VESA 2.0 VBE extensions (e.g. Windows XP) and if you want to use high resolution modes (>= 1280x1024x16) then you should use this option. (This card is the default since QEMU 2.2)
<jonmason> moto-timo: does exist for qemu for arm machines
<jonmason> err...doesn't
<jonmason> I'm walking through all the machines now to see which ones need it (as I've removed it from the kernel recipes)
<sudip> rburton: I will try again tonight (after $dayjob) and paste you the strace output
<rburton> netstat would work
Jham has quit [Quit: Leaving]
<sudip> ok
<jonmason> I think it's just riscv, x86, and mips; and I think some of those can be coverted
<moto-timo> based on those comments in the docs, it certainly feels like it needs a revisit in 2023
jamesreid[m] has quit [Quit: User was banned]
dmoseley has quit [Ping timeout: 252 seconds]
<jonmason> moto-timo: thanks, I probably need to test vrgl too
<moto-timo> jonmason: I'm just trying to do an archeological dig to figure out "why?"
<jonmason> ichanged from bochs to virtio when fixing qemuarm* a while ago
<jonmason> I might've forgot to update something, like docs
<jonmason> and the patch adding it to the kernel was probably just following the docs and something I missed
<jonmason> that is my assumption
goliath has joined #yocto
dmoseley has joined #yocto
manuel__ has quit [Ping timeout: 248 seconds]
dgriego has joined #yocto
manuel1985 has joined #yocto
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
mckoan_ is now known as mckoan|away
florian has quit [Quit: Ex-Chat]
dmoseley has joined #yocto
yann has joined #yocto
dmoseley has quit [Ping timeout: 256 seconds]
zpfvo has quit [Ping timeout: 246 seconds]
dmoseley has joined #yocto
<dacav> sudip: my machine does have ipv6. How do you suggest to disable ipv6?
<rburton> personally i don't see how having v6 would make the parse slow
<rburton> the parse is just parsing files on disk
frieder has quit [Remote host closed the connection]
<sudip> dacav: iirc, "sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1"
<dacav> rburton: I do have autorev recipes for sure. So maybe the problem is network related. But if parsing is on-disk then it could be something else.
<dacav> thanks sudip, I can try to see if it fixes anything
Payam has quit [Quit: Leaving]
<rburton> autorev recipes means it does a network operation to get the latest revision
leon-anavi has quit [Quit: Leaving]
<dacav> rburton: Yes, but then I should see delay after the "Parsing recipes" step?
<dacav> sudip: disabling ipv6 doesn't do much. Worth trying, since it's easy to do :)
<sudip> :)
<dacav> top(1) shows me a number of Parser processes, but they're not CPU intensive, all of them have 0.3 of %CPU
PhoenixMage has quit [Ping timeout: 252 seconds]
<sudip> dacav: can you please do strace on any one of them
<sudip> rburton: I have just started one and my delays are from "connect(42, {sa_family=AF_INET6, sin6_port=htons(443), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "2607:f8b0:4004:c06::80", &sin6_addr), sin6_scope_id=0}, 28) = -1 ETIMEDOUT (Connection timed out)"
<sudip> then it tries the next address and again timeout until it finds a working address
<dacav> I can try, sure. In the meanwhile here's some stats:
<dacav> bitbake -c do_xr_license_data lib32-xr-image
<dacav> Parsing recipes: Time: 0:04:13, Initialising tasks: Time: 0:00:03, Checking sstate mirror object availability: Time: 0:00:11
PhoenixMage has joined #yocto
<rburton> sudip: sounds like the recipes which you're doing autorev on have broken ipv6
<rburton> easily checked by disabling your autorevs and seeing what happens
<sudip> ok, so I will find out which recipe is that, this is with AGL, I will also try just a Yocto build and see
PhoenixMage has quit [Ping timeout: 264 seconds]
PhoenixMage has joined #yocto
<dacav> I've straced all the Parser threads, and throw all results in a directory. I can grep ETIMEOUT | wc -l -> 13
<dacav> all of them on a futex
<dacav> I'm not inclined to think it has to do with network, especially given that the time is spent in parser, and parsing is on local files only.
<dacav> the most common syscall is lstat
<dacav> follows stat, futex, read,...
<rburton> fwiw, bitbake has profile and parse-only options specifically to get profiles of the parse step
PhoenixMage has quit [Ping timeout: 248 seconds]
<dacav> rburton: that might be an interesting direction to take, in order to figure out!
<dacav> I'll have to close now. Any recommended read on the topic?
<rburton> bitbake --help :)
<dacav> Ok :) Thanks. And thank you all for the support! :)
PhoenixMage has joined #yocto
<dacav> (fuuuuuck, I gave a try, I immediately found about `bitbake -p -P`, and the parsing took 1 second! Come on!)
<dacav> heh, time to log off :) thank you again. Cheers
dmoseley_ has joined #yocto
florian has joined #yocto
dmoseley has quit [Ping timeout: 256 seconds]
PhoenixMage has quit [Ping timeout: 252 seconds]
PhoenixMage has joined #yocto
florian has quit [Ping timeout: 252 seconds]
Minvera has joined #yocto
PhoenixMage has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
<khem> abelloni: regarding elfutils ptest fails can you extract tests/test-suite.log file or point me to the node and workdir
PhoenixMage has quit [Ping timeout: 246 seconds]
PhoenixMage has joined #yocto
tomzy_0 has quit [Quit: Client closed]
florian has joined #yocto
<vvmeson> actually, the parsing time on the 192 core system, is flat after 96 cores. 28.9 sec @ 64, 25.3 @96, 25.2 @ 192 . We should probably cap it.
Haxxa has quit [Quit: Haxxa flies away.]
prabhakarlad has quit [Quit: Client closed]
Haxxa has joined #yocto
goliath has quit [Quit: SIGSEGV]
olani- has joined #yocto
ptsneves has quit [Ping timeout: 265 seconds]
azcraft has joined #yocto
<dacav> I found that bitbake has a ncurses ui. How does that work? Can I have it persistent maybe?
<dacav> The documentation just mentions it as a command line option.
<dacav> btw, no much luck with the profiling (bitbake -Pp). It looks like the most time is spent in epoll, which matches the low cpu work. If the cache is not clear, I get a decent speed. I'll use the suggestion above, that is I'll inherit my class with a single recipe, hoping I can make better use of the cache.
seninha has quit [Quit: Leaving]
seninha has joined #yocto
<sudip> rburton: just tried the kirkstone branch in that same host with ipv6 and there was no delay. I will try to find out which recipe in AGL was causing the delay and will take it to them.
<abelloni> khem: I've started a new build with the patches on https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/4593
<abelloni> this is debian11-ty-2
prabhakarlad has joined #yocto
tilman[m] has joined #yocto
azcraft has quit [Remote host closed the connection]
Minvera has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
Wouter01006704 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter01006704 has joined #yocto
kscherer has quit [Quit: Konversation terminated!]
seninha has quit [Quit: Leaving]
demirok has quit [Quit: Leaving.]
gsalazar has quit [Ping timeout: 260 seconds]
gsalazar has joined #yocto
roussinm has quit [Quit: WeeChat 3.0]
florian has quit [Ping timeout: 260 seconds]