sakman_ has quit [Remote host closed the connection]
sakman has quit [Ping timeout: 272 seconds]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
brazuca has quit [Quit: Client closed]
Ablu has quit [Ping timeout: 260 seconds]
Ablu has joined #yocto
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #yocto
amitk has joined #yocto
jclsn has quit [Ping timeout: 272 seconds]
jclsn has joined #yocto
amitk has quit [Quit: Lost terminal]
tgamblin has quit [Ping timeout: 258 seconds]
WinstonSmith2600 has joined #yocto
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #yocto
sgw has quit [Ping timeout: 248 seconds]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #yocto
sgw has joined #yocto
amitk has joined #yocto
florian has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
amitk has joined #yocto
slimak has joined #yocto
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #yocto
alessioigor has joined #yocto
amitk has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
<PhoenixMage>
Afternoon all
Guest98 has joined #yocto
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
mvlad has joined #yocto
goliath has joined #yocto
mckoan|away is now known as mckoan
<mckoan>
good morning
<Guest98>
morning
<WinstonSmith2600>
So... I was wondering... why does it take longer to do a minimal yocto build than a minimal buildroot build?
<mcfrisk>
WinstonSmith2600: don't know much about buildroot but yocto compiles the toolchain needed to cross-compile the SW. The linux distro is bootstrapped from scratch. And those dependencies are quite complex.
<Guest98>
I'm trying to get a build for a custom board on the yocto side. I asked for the kernel sources from the company i bought the board from but there is no documentation in it. Is it normal not to have documentation? Should there be? I dont know since i'm a rookie trying to do something on my own.
<Guest98>
How should i proceed to implement it on the yocto side? Is there any documentation, video or something i can follow about preparing a custom board?
<Guest98>
mckoan I'll take a look and try to understand. Thank you.
mdb977 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<Guest98>
mckoan i used dtb's as you shared, but i also have kernel image. I need to override it too. But, Leto told this is illegal. So, i got all the source from the company. I guess, i need to build the kernel as well.
amitk has joined #yocto
florian_kc has joined #yocto
xmn has quit [Ping timeout: 248 seconds]
amitk has quit [Ping timeout: 248 seconds]
khem has quit [Quit: Connection closed for inactivity]
<mdb977>
Hello together, may I ask what is the binary 'recipe-sysroot-native/usr/bin/nativepython3 'for? Is this the binary for the python3-native package, and if yes, why is it named nativepython3?
prabhakarlad has joined #yocto
<rburton>
WinstonSmith2600: a default yocto has more turned on than a default buildroot. you can easily turn stuff off, but we want to be sure things work so they're on by default.
<Tilltheman>
Hi all, is it possible to have a recipe depend on a task of a bbclass, e.g. such that when this recipe is built, all of the recipes inheriting the bbclass also are progressed up to that task (e.g. fetched, configured)?
<rburton>
RP: re numpy, that's just enraging
<rburton>
RP: and fwiw, whilst upstream moved to meson for the top-level build, that file is still in the tree
<RP>
rburton: it was a bit crazy!
<RP>
rburton: I think I'm going to need help with the 6.5 kernel stability issues
<RP>
rburton: arm has jitterentropy issues but x86 is randomly crashing or something
<RP>
also see arm LTP OOM
tct is now known as jbo
<rburton>
ok i'm about to walk the dog but can you sling bugs at me?
<RP>
rburton: no bugs yet but see the discussion with Bruce on list
<rburton>
ok
Kubu_work has joined #yocto
leon-anavi has joined #yocto
dacav has joined #yocto
<dacav>
Hi. I've got a recipe that I'd like to build for the SDK. As part of the do_compile task, the build system creates a binary which is later used to generate some code. Everything works fine for a -native build, but with -nativesdk I end up with many "No such file or directory". It looks like the code-generating tool expects the ld.so to exist under the installation path of the SDK, which is of course not
<dacav>
the case.
<dacav>
Chicken & Egg problem.
<dacav>
I assume that the -nativesdk should depend on the -native to provide the tools.
<LetoThe2nd>
yo dudX
<rburton>
yes
<mcfrisk>
dacav: split the recipe into -native and target one
<rburton>
dacav: remember a nativesdk is still cross-built, you need to depend on native recipes for native tools
<dacav>
mcfrisk: if by target you mean -nativesdk, then it is already split
<dacav>
I believe I should force the build system of the software I'm packaging to search the executable in the sysroot that provides the dependencies.
<rburton>
dacav: its probably trying to run the binary it just build, instead of the native binary
<dacav>
Yes, this is the same conclusion I reached
<mcfrisk>
no a -native to build the tooling/code generator which runs on build host, then that is used to compile target and nativesdk recipe
<dacav>
Also the build system is CMake, and it uses NO_DEFAULT_PATH to avoid searching under the "normal" /usr/lib
<mcfrisk>
sigh, CMake is really painful to work with and developers frequently mess it up and extend its use to mix host and target build parts
<rburton>
cmake makes it more fun because it doesn't support "build this binary for the build or find it on the host" so everyone reimplements it, or doesn't even bother, themselves
<dacav>
mcfrisk: roger :) Then I'm in the right direction.
<dacav>
(hope no user is named 'roger')
<dacav>
rburton: I can try applying a patch conditionally, to tweak the cmake configuration. Is there a variable which points to the sysroot of the dependencies? I will try to inject that.
<mcfrisk>
dacav: CMake builds must use the yocto/bitbake/cmake.bbclass generated toolchain file for all paths
<dacav>
mcfrisk: I'm using cmake.bbclass. Is that enough or should I do something more?
Kubu_work has quit [Quit: Leaving.]
Danct12 has joined #yocto
<mcfrisk>
dacav: you need to review all the CMakeFiles and scripts that they use the variables from the generated toolchain file correctly to find binaries, CMake modules, shared libraries, headers and also set the target install paths using variables defined there.
Danct12 has quit [Remote host closed the connection]
<mcfrisk>
with luck things will work, with some more luck QA checks will find worst offenders too
<dacav>
QA checks do not seem to find much. I think I found the culprit in the CMake using NO_DEFAULT_PATH when using find_program
<dacav>
I'm trying to rewire that so it will force the search to the yocto-provided paths.
Danct12 has joined #yocto
vladest1 has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<mischief>
down with cmake, go meson
<dacav>
haha, yes, I can totally ask upstream to change it.
Guest98 has quit [Quit: Client closed]
<dacav>
What is the "opposite" of do_populate_sysroot? That is, when does the recipe take in all the sysroots populated by dependencies?
Guest98 has joined #yocto
<dacav>
Ah, found it! :D do_prepare_recipe_sysroot. Sorry
amitk has joined #yocto
vladest1 has quit [Ping timeout: 260 seconds]
mbulut has joined #yocto
mbulut has quit [Client Quit]
rfuentess has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
mckoan is now known as mckoan|away
<rburton>
i found a use for bitbake -b!
<rburton>
dare not count how many years its taken
* dacav
learns about -b
<dacav>
rburton: what is the use for it?
<dacav>
*that you found
<rburton>
extracting variables from many recipes for post-processing, especially when there's multiple versions
<rburton>
specifically, getting _all_of the kernel versions that are in core
<rburton>
don't use -b
<rburton>
you (almost) never need -b
<dacav>
The "WARNING" in the usage text makes me think it is a somewhat plumby tool
<ernstp>
happened when I built a kernel module before the kernel was built
<ernstp>
if I built the kernel and then the module again it worked
WinstonSmith2600 has quit [Ping timeout: 240 seconds]
<ernstp>
(that was with Kirkstone)
WinstonSmith2600 has joined #yocto
WinstonSmith2600 has quit [Ping timeout: 240 seconds]
bhstalel has joined #yocto
dvergatal has quit [Read error: Connection reset by peer]
dvergatal has joined #yocto
Guest98 has quit [Quit: Client closed]
Guest98 has joined #yocto
WinstonSmith2600 has joined #yocto
<RP>
mcfrisk: We're seeing some weird issues on the autobuilder where with the 6.5 kernel, it doesn't detect the login prompt appearing in the 1000s window despite it clearly being present in the log on disk :(
* RP
just wondered if you'd seen anything like this? :/
<RP>
I've added more logging in master-next to see if we can catch anything there
<mcfrisk>
RP: was there a way to get to the task log files from main stdio? I'm really missing that
amitk has joined #yocto
lars31 has quit [Quit: Client closed]
Guest43 has joined #yocto
lars20 has joined #yocto
amitk__ has quit [Quit: Lost terminal]
Guest98 has quit [Ping timeout: 245 seconds]
lars20 has left #yocto [#yocto]
<mcfrisk>
RP: well there is the ^M on login prompt line, but I doubt that is causing this. could be a timeout to start the actual login shell.
amitk has quit [Ping timeout: 248 seconds]
bhstalel has quit [Ping timeout: 245 seconds]
tgamblin has joined #yocto
amitk has joined #yocto
Minvera has joined #yocto
Guest43 has quit [Quit: Client closed]
amitk has quit [Ping timeout: 255 seconds]
<mcfrisk>
RP: with latest code I've not seen failures like this on qemu. The data pipe to serial console has been reliable and login detection has worked, read() calls have not been blocking.
<RP>
mcfrisk: there isn't one in this case as it was run outside bitbake
<mcfrisk>
RP: the partial serial read logs don't show the login prompt, as if the last line was eaten by some buffering
<RP>
mcfrisk: that was what I was thinking too. How does it make it into the log eventually I wonder? I wonder if qemu needs to do something differently with serial flushing
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
<mcfrisk>
utf8 decoding issue due to ^M in the stream?
<mcfrisk>
both partial logging and login detection happens after utf8 encoding, raw logging without. there is an issue with utf8 decoding of the stream from serial console
<RP>
mcfrisk: I'm trying surrogateescape in my test branch. It is hard to know which one we should use
<mcfrisk>
RP: hope this helps. This is poorly documented if it does :(
<ernstp>
JPEW: yes. Seems reproducible
<ernstp>
JPEW: I guess out of tree modules are not super common... ?
<JPEW>
ernstp: They happen sometimes
WinstonSmith2600 has quit [Ping timeout: 255 seconds]
florian_kc has quit [Quit: Ex-Chat]
khem has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
goliath has quit [Quit: SIGSEGV]
<JPEW>
RP, mcfrisk: Maybe it would be helpful to print the raw hex data in the partial boot log?
sakman has joined #yocto
<LetoThe2nd>
zeddii: just doing some simple experiments with docker, and "docker run --rm hello-world" fails with "http: invalid Host header". environment is qemux86-64. as some people on the web suggested go 1.20.7 is the problem, i rolled back to 1.20.6 but it seems to persist. any pointer?
<mcfrisk>
JPEW: possibly, but there was some resistance to increasing logging data.
<JPEW>
mcfrisk: Ah. Or maybe the qemu_boot_log could be the raw data instead of decoded
<JPEW>
We
<mcfrisk>
LetoThe2nd: switch to docker-moby and update to latest from master branch
<LetoThe2nd>
mcfrisk: master of?
<zeddii>
LetoThe2nd. It's a docker/moby version issue. what release are you on ? I have two pending moby patches for mickledore, but I've been tied up with the kernel uprev last week.
<LetoThe2nd>
zeddii: all mickledore.
<mcfrisk>
LetoThe2nd: meta-virtualization
<JPEW>
We've had trouble with the kernel interrupting the login sequence before. We ended up silencing the kernel on init on the platforms where it was a problem (not QEMU though)
<mcfrisk>
or cherry-pick the patches to docker-moby in master branch. backport has been proposed on mailing list
<zeddii>
LetoThe2nd. yah, you need a couple of bumps, I'm doing them today and also a final round of version bumps shortly.
* zeddii
gives up.
<mcfrisk>
JPEW: the boot log is already raw, which is good
mdb977 has quit [Quit: Leaving]
<JPEW>
mcfrisk: If it's the self.log() call, it is not raw
<LetoThe2nd>
zeddii: np. if its known and not something wrong on my end, then I'm all fine with it. no need to hurry, this is not a blocker.
<JPEW>
(unless that was changed recently)
<zeddii>
LetoThe2nd. yep. known. will be cherry-picked shortly. Just a few more things to test on my end.
<LetoThe2nd>
zeddii: great! thanks a lot man
<mcfrisk>
JPEW: in this case the raw from qemu socket is logged to separate file and shows correct content which even passes as utf8, but when it is read by python select/read loop it seems to get garbled for a while
<JPEW>
mcfrisk: Hmm, how is it garbled?
<mcfrisk>
JPEW: not clear, but python3 decode('utf-8', errors='ignore') is missing the last crucial line for login prompt
Guest19 has joined #yocto
<JPEW>
mcfrisk: That sounds like a line buffering problem
<mcfrisk>
JPEW: exactly but where...
<mcfrisk>
a single read(1024) has the data, conversion to utf8 misses few last lines, raw log data has the login prompt
<JPEW>
mcfrisk: Where is the raw log?
<JPEW>
ernstp: Hmm, is your recipe around that I can see it?
<tlwoerner>
qschulz: i've been simply appending to the end of the list the most recent one(s) added (in the README)
<tlwoerner>
thanks for the review, does the earlier rock-pi-s look okay too?
slimak has quit [Ping timeout: 248 seconds]
<Saur>
khem, armpit: What's the plan for the nanbield branch in meta-openembedded? Will it remain as is even though it branched long before the actual Nanbield release, or will it sync up with master?
<qschulz>
tlwoerner: rock-pi-s patch series has some issues
geoffhp has quit [Remote host closed the connection]
chep has quit [Read error: Connection reset by peer]
<RP>
rburton: not sure how much you're looking at the logging issue but the above log is very puzzling :/
chep has joined #yocto
florian has quit [Ping timeout: 255 seconds]
Guest19 has quit [Quit: Client closed]
<rburton>
well clearly it read that last line
<rburton>
oh its not doing something stupid like not considering the last line because it doesn't get a newline?
<RP>
rburton: why does it think bootlog is empty but self.msg has everything?
<RP>
rburton: the issue is that bootlog is empty but looking at the code, I can't see why
<ernstp>
JPEW: is really exactly like the kernel mod from meta skeleton, except it's in a git repo
radanter has quit [Remote host closed the connection]
<khem>
RP: I sent a patch for python3-docutils which would be needed with kernel 6.5 if/when we upgrade
<khem>
kernel-selftest package needs it
leon-anavi has quit [Quit: Leaving]
<RP>
khem: ok, thanks for the heads up. I was wondering what it was connected to so that info helps
<khem>
yeah I have fixed meta-openembedded to work with 6.5 kernel and it came out of that
amitk has joined #yocto
florian has joined #yocto
amitk_ has joined #yocto
<landgraf>
JPEW: Hi. Around? I'm figthing with SDK generation bugs and hit something I've never seen before ' Unable to find package with name 'perl' in SPDX file' . perl is provided by dummy sdk package, should it be in the spdx file target-sdk-provides-dummy.spdx.json?
<JPEW>
landgraf: Ya, this has been floating around. I've been looking into it, but it's been hard because I cannot reproduce locally
<JPEW>
What branch are you on
<landgraf>
JPEW: master. latest greatest
<landgraf>
JPEW: but I've modified dummy-sdk-package because of the bug 14995 . I can either share diff with you or file bugreport...
amitk has quit [Remote host closed the connection]
<JPEW>
If you can share you diff that would be helpful
<JPEW>
I need to go eat before I can look though
<landgraf>
JPEW: Enjoy. I'll try to simplify the reproducer
florian has quit [Ping timeout: 272 seconds]
l3s8g has joined #yocto
l3s8g has quit [Remote host closed the connection]
<ad__>
is there a way to set a precedence of a recipe over another of the same layer ?
<JaMa>
ad__: DEFAULT_PREFERENCE
<ad__>
JaMa: thanks, trying it
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #yocto
<ad__>
seems not helping. So i have 2 different recipes inside same meta-layer, both "install" a same file
<ad__>
trying to figure out if i can define a precedence, but order of recipe processing seems not changable
<ad__>
dpendences may be involved
<JaMa>
is it the same component with 2 different versions?
<ad__>
no, 2 different recipes
<ad__>
different names
<ad__>
both are installing iptables.rules
<JaMa>
aha, then DEFAULT_PREFERENCE nor P_V will work
<ad__>
yeah, isee
<ad__>
thanks anyway
goliath has joined #yocto
Vonter has quit [Ping timeout: 264 seconds]
Vonter has joined #yocto
<ente>
hi
alessioigor has quit [Quit: alessioigor]
<ente>
so I have go-1.14 included in poky (dunfell) and I'm trying to replace it with 1.20.7
<ente>
if I remove the files from poky and replace the directory with the new files, everything works fine
<ente>
however poking around in poky feels like bad practice so I would rather replace them in my own layer
<ente>
so if I back out my change to poky and put them in my own layer, "inherit go" always pulls in go 1.14
<ente>
I tried adding the new bbclasses to my own layer but that didn't help
<ente>
any hints about how to completely replace a recipe?
<rburton>
ente: check the layer priority, it should be the same as oe-core so that bitbake just looks at recipe versions. or set PREFERRED_VERSION for the go pieces. Worth checking that it's actually reading your layer...
<ente>
the package that pulls in go via "inherit go" is in the same layer as the go recipe
<ente>
this layer has priority 20, poky has 5
<rburton>
oh have a look at tcmode-default.inc. There's a GOVERSION which controls what version is preferred.
<rburton>
honestly, i'd set priority to the same as oe-core. anything else is painful.
<ente>
generally or in this particular case?
<rburton>
generally
<rburton>
layer priority is madness
<ente>
layers are madness if you ask me :)
<ente>
I inherited the project like this
<rburton>
i think i prefer layers to the olden days where 1000+ recipes where in a single folder
<ente>
we have a bunch of layers at different priorities and no one told me why, let's say meta-qt5 has prio 7, poky has 5, meta-freescale has 5 and meta-oe has 6
<ente>
feels like someone rolled dice
<ente>
aha! thanks for the tip about GOVERSION, I had found that before and then forgotten all about it
<JaMa>
that's why (LGE) we set all priorities in generated bblayers.conf, so that we have control over all of them (instead of depending on the default set in layer.conf)
<JaMa>
keeping them all uniq and generating BBLAYERS in matching order is additional benefit of that
<rburton>
ente: for layers which add software (like meta-oe or meta-qt5) i'd say the priority should be _identical_ to core
<JaMa>
and as long as they don't do any funny bussiness with BBPATH, then order of BBPATH is matching the layer priorities as well
<ente>
rburton: good to know, will mention this to the other people on the project
amitk_ has quit [Ping timeout: 255 seconds]
florian has joined #yocto
<Crofton>
WHy did we create pseudo again>
<Crofton>
?
<JPEW>
Crofton: I think the requirements were such that nothing existed that would work