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.
<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?
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
<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
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
<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
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
<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:
<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.