ederibaucourt has quit [Ping timeout: 240 seconds]
LocutusOfBorg has quit [Read error: Connection reset by peer]
ederibaucourt has joined #yocto
LocutusOfBorg has joined #yocto
GillesMM has joined #yocto
GillesM has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
sakman has quit [Ping timeout: 264 seconds]
amitk has joined #yocto
xmn has joined #yocto
davidinux has quit [Ping timeout: 255 seconds]
davidinux has joined #yocto
xmn has quit [Ping timeout: 272 seconds]
xmn has joined #yocto
pabigot has quit [Ping timeout: 264 seconds]
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
Guest98 has joined #yocto
pabigot has joined #yocto
xmn has quit [Ping timeout: 258 seconds]
<mcfrisk>
RP: the boot prompt search is bad, I think better to ditch the utf-8 conversion of boot log and convert the prompt search string to bytes() instead. in qemurunner.py 486: if bytes(self.boot_patterns['search_reached_prompt'], 'utf-8') in bootlog:
<mcfrisk>
testing this in local build with qemu now..
GNUmoon has quit [Remote host closed the connection]
goliath has joined #yocto
GNUmoon has joined #yocto
wooosaiiii has quit [Quit: wooosaiiii]
Guest98 has quit [Ping timeout: 245 seconds]
wooosaiiii has joined #yocto
prabhakarlad has joined #yocto
<RP>
mcfrisk: when you say it is bad, how do you mean?
<RP>
mcfrisk: Interestingly I've run the changes in master-next twice now and only one failure which looks to be a genuine login timeout :/
<mcfrisk>
RP: as the logs show, python utf8 conversion eats the last lines sometimes
<RP>
mcfrisk: so it isn't that the search itself is bad, the underlying data is. The trouble is the logs show bootlog as being empty, not just the last line eaten
<mcfrisk>
I did not see an empty bootlog. maybe missed something
<mcfrisk>
I saw raw data including login prompt but the partial reads and utf8 decoding failing to detect it
<RP>
WARNING: Last 25 lines of processed bootlog (1):
<RP>
WARNING: Last 25 lines of msg (651):
<RP>
i.e. bootlog was empty it would seem
brrm has quit [Ping timeout: 240 seconds]
mvlad has joined #yocto
rfuentess has joined #yocto
<RP>
mcfrisk: note that the latest in master-next doesn't seem to break so I could have accidentally "fixed" this somehow
<mcfrisk>
RP: line 508 overwrites bootlog with the utf-8 decoded output?
<mcfrisk>
if utf8 decoding is broken, then data is lost
<mcfrisk>
I saw this when comparing do_testimage log to the raw bootlog in one of the cases. do_testimage was logging after utf8 decoding and was missing login prompt. raw data had it.
brrm has joined #yocto
<mcfrisk>
and all data comes from the same read(1024) call and data is appended to previous read()
<RP>
mcfrisk: maybe, but the worry was that the "raw" log actually has the conversion run on it a lot more
<RP>
mcfrisk: one change I have in my test commit is changing the logging to actually be the raw data
mckoan|away is now known as mckoan
<mcfrisk>
RP: I'm looking at master-next, there "Partial boot log" will print utf-8 decoded strings. when login not reached, the warnings will include only utf-8 decoded strings (python complains if not utf8 decoded)
<mcfrisk>
RP: but if master-next works, then I'm happy to be wrong. I'd hope the bytes to utf-8 string conversion would work on partially read data from serial console
<RP>
mcfrisk: but it also changes the file on disk to be binary and writes that file without conversion.
<RP>
mcfrisk: I'm not sure what is going on, just that the changes on -next appear to have stopped it reproducing
<mcfrisk>
the raw boot log has always been raw, not utf-8 converted
<RP>
mcfrisk: see the msg = self.decode_qemulog(msg) in log()
<mcfrisk>
test build is just taking for ever after cargo stuff again..
chat89 has joined #yocto
<RP>
mcfrisk: yes, I agree. I'm just worried I don't quite understand what is breaking here
<mcfrisk>
RP: Yes, something isn't adding up. But, if there is suddenly more carbage on serial logs due to kernel changes, then python utf-8 conversion can fail in odd ways.
<mcfrisk>
also timing, when strings get written over serial, there may be unexpected pauses now, which will eventually be in the buffer we read, but the partial utf8 conversions may be missing the lines with with issues
<RP>
mcfrisk: I still don't understand why bootlog would end up empty though :/
radanter has joined #yocto
slimak has joined #yocto
<Ablu>
> mcfrisk: I wonder if the msg = self.decode_qemulog(msg) destroys msg instead of doing something function localit _should_ not
<mcfrisk>
could it be that msg is both both global and local?
luc4 has joined #yocto
<RP>
mcfrisk: it may be the bytes objects behave differently to strings
<yocton>
Hi, how do you handle sending multiple patches across different repos (e.g. oe-core and yocto-docs or oe-core and autobuilder) ? CCing all MLs on the patch series ? Splitting the series for each repo?
<RP>
yocton: usually patches per repo but it depends how closely related they are
<yocton>
I do have "code and its documentation" and "code that will not work if this other patch is not merged first" relations
<RP>
yocton: you'd usually note a dependency in the commit.
<yocton>
I plan to send patches walking the dependency graph but reviewer will lack the big picture :(
<RP>
yocton: then copy the different lists?
<yocton>
Ok, thanks!
slimak has quit [Ping timeout: 272 seconds]
pabigot has quit [Ping timeout: 255 seconds]
<RP>
yocton: I've been meaning to mention, a report of what the new test reports for both OE-Core would be helpful to see how things look
<RP>
s/both// I was thinking for OE-Core at least, I'm assuming you also have one for meta-oe which is being worked on
<yocton>
Yes, I'll gather the info and reply to the series with it :)
<RP>
yocton: "QA, ptest" isn't really correct in the commit message shortlog either :/
<yocton>
*GASP*
<yocton>
I'll fix this in the v2
<RP>
yocton: I'm guessing you were avoiding the "insane"? :/
<RP>
We probably should rename that class really
<RP>
much as I like the history it will be lost on most now
pabigot has joined #yocto
amsobr has quit [Quit: Konversation terminated!]
* yocton
also like "insane" ^^
mario-goulart has quit [Remote host closed the connection]
mario-goulart has joined #yocto
WinstonSmith2600 has joined #yocto
Tyaku has joined #yocto
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #yocto
mckoan is now known as mckoan|away
<luc4>
Hello! Is there a way to understand why bitbake is building libs in debug mode? For some reason I cannot disable this anymore.
sakman has joined #yocto
<RP>
mcfrisk: what we might be missing here is the threading. I bet this needs locking or rewriting
pabigot has quit [Ping timeout: 252 seconds]
<mcfrisk>
RP: ouch
<RP>
mcfrisk: I can't quite work out how that results in bootlog being empty
Daanct12 has quit [Ping timeout: 260 seconds]
pabigot has joined #yocto
<RP>
mcfrisk: I wonder if the getty appears on the wrong serial interface
florian_kc has joined #yocto
<mcfrisk>
RP: like you said, two threads calling into decode_qemulog() and getting each others content
<RP>
mcfrisk: no, I think what might be happening is the output going to the wrong socket. The kernel may be mixing them up "randomly"
<mcfrisk>
kernel or qemu?
<RP>
bootlog was empty as there was no log output on that socket, it went to the threadlog instead
<RP>
mcfrisk: change in kernel behaviour with the serial ports?
<RP>
we just start qemu with -serial tcp:127.0.0.1:46745 -serial tcp:127.0.0.1:41183
<RP>
who says which is ttyS0 and which is S1
GillesMM has quit [Ping timeout: 272 seconds]
<RP>
still doesn't entirely add up but...
<mcfrisk>
for qemurunner.py, data came from self.runqemu.stdout. that's for sure
<RP>
mcfrisk: not sure about that
<bhstalel>
Why bitbake lib disables stdin when running ?
<RP>
mcfrisk: see the filelist.append(qemusock) line
<RP>
bhstalel: it stops things hanging waiting for input that will never arrive
<bhstalel>
Like what ?
<RP>
bhstalel: we execute multiple things in parallel so where would any input go anyway?
<RP>
bhstalel: kernel config waiting on input was the classic
<bhstalel>
Because I tried to develop a CLI shell-like application using bitbake lib directly to create and manage layers/recipes/... and I found stdin was disabled
<RP>
bhstalel: using cooker?
<bhstalel>
RP Yes using cooker and tinfoil lib (I am not familiar with the lib details, but I remember tinfoil)
<RP>
I'm unclear which piece of code is disabling stdin. I'd not have expected tinfoil to do that
<Guest98>
do_kernel_metadata: A KBUILD_DEFCONFIG 'tegra_defconfig' was specified, but not present in the source tree (../tegra-demo-distro/build/tmp/work-shared/p3768-0000-p3767-0000/kernel-source/arch/arm64/configs/)
<Guest98>
trying to build a custom kernel and it is a bit different from the kernel's structure. I'm having problems with paths. how can i fix this?
<bhstalel>
RP I do not remember what I tried to do, but I will try again for sure.
<bhstalel>
RP I am currently developing a kas-like framework in Rust that supports lot of features and different input files types (JSON, YAML and RON)
<RP>
the main bitbake server process isn't expected to have input, it is meant to be handled by the UI modules (like knotty/toaster or whatever is connecting via tinfoil). stdin is also disabled in task execution context since those should never be depending on stdin without setting up their own terminal
<qschulz>
PhoenixMage: what a coincidence! Your patch to add --no-table to the wks on meta-rockchip... turns out this fixes an OOM in U-Boot SPL in my very downstream U-Boot :D
<bhstalel>
RP Can you give me quick discription of the Bitbake server ? TCP server ? it accepts commands from tinfoil ? It is responsible for running the build ?
<qschulz>
would have taken me much more time if you hadn't posted this recently :)
<RP>
bhstalel: I'm deep in debugging something so no, I'm not able to do that at the moment, sorry
<bhstalel>
RP No worries, thanks any ways
pabigot has quit [Ping timeout: 255 seconds]
<rburton>
luc4: bitbake just does what the recipe tells it to do. if the actual build doesn't do what you want then you need to understand the makefiles/etc and figure out how to change the recipe.
Kubu_work has joined #yocto
pabigot has joined #yocto
<luc4>
rburton: which recipe? The entire image was in debug. I probably found the reason: the package group packagegroup-core-tools-debug. I thought those were only debugging applications but maybe it is something more.
<rburton>
what do you mean "entire image was in debug"
<luc4>
rburton: every library or binary
<rburton>
that's unrealted to the packagegroup
<luc4>
rburton: 13GB of image was the result
<rburton>
i still don't know what you mean by "in debug"
<luc4>
"built in debug mode", like -g
<rburton>
we always build with -g
<luc4>
not stripped, with symbols etc...
<rburton>
but the symbols are split out to PN-dbg packages
<rburton>
if the binaries are _unstripped_ then you turned off stripping
<luc4>
rburton: yes, I did that some days ago to debug a crash in chromium, but now I removed it.
<rburton>
easier to just install the dbg packages
<luc4>
rburton: however maybe I solved, now the image is 1GB
<luc4>
rburton: ah... didn't know that
<luc4>
rburton: I thought it was the package group... but I won't try to add it back... I'm afraid it tried to rebuild everything
<rburton>
that packagegroup is just a set of tools that is useful for debuggibg
<rburton>
how did you turn off stripping?
<luc4>
rburton: eh... I thought it was the packagegroup, cause I removed it
<luc4>
rburton: maybe I also removed something else at this point...
<rburton>
sounds like you set INHIBIT_PACKAGE_STRIP
<rburton>
globally
<luc4>
rburton: some days ago I added these: DEBUG_BUILD = "1"; INHIBIT_PACKAGE_STRIP = "1"; INHIBIT_PACKAGE_DEBUG_SPLIT= "1"
<rburton>
yeah don't do any of that
<rburton>
you didn't achieve anything apart from a big rebuild
<rburton>
DEBUG_BUILD can be useful for _specific recipes_
<rburton>
setting it globally will obviously mean a rebuild of everything
<luc4>
rburton: yes, that is what I wanted. I didn't want just one recipe. I also wanted glibc and all chromium deps. However, hopefully, I won't need it anymore.
<luc4>
rburton: I should probably learn to try a dry-run before doing anything. It happens too frequently that a rebuild takes place...
<luc4>
rburton: chromium really is giving me headaches :-(
GNUmoon has quit [Remote host closed the connection]
bhstalel has quit [Ping timeout: 245 seconds]
JerryM has joined #yocto
alessioigor has quit [Quit: alessioigor]
alessioigor has joined #yocto
Guest57 has joined #yocto
Guest98 has quit [Ping timeout: 245 seconds]
Tyaku has quit [Quit: Lost terminal]
Guest57 has quit [Ping timeout: 245 seconds]
Xagen has joined #yocto
<tgamblin>
RP: in your email from yesterday you mentioned that x86 image tests were failing. Is this just testimage runs, or something else?
* tgamblin
is trying not to ask how to reproduce it
Guest98 has joined #yocto
<yates_work>
i see various places where <recipe-stem>.bb is defined as well as a <recipe-stem>-native.bb. What is the -native version about?
<yates_work>
e.g., the meta-qt5 has qtbase and qtbase-native
<tgamblin>
yates_work: -native is for building host versions of the recipe, if it's needed as a dependency or as a tool during building of other recipes for target
<RP>
tgamblin: it is various uses of runqemu from selftest and testimage as far as I can tell. I think I might have a lead on what is going on (see my runqemu patch earleir)
<tgamblin>
RP: Alright. I'm working on setting up to test it, but I seem to be running into an error with the use of INHERIT += "testimage" today...
<tgamblin>
bitbake seems to be trying to inherit classes/testimage.bbclass when it should be classes-recipe/testimage.bbclass
<RP>
tgamblin: with modern code that needs to be IMAGE_CLASSES += "testimage"
<RP>
zeddii: could you have a look at that log and see if you can understand what "min_free_kbytes" is as a process? :/
rfuentess has quit [Remote host closed the connection]
FabienThomas has joined #yocto
<zeddii>
RP: it seems like a version/variant of a message we've seen in the past, I tried to fix it incorrectly on the qemu boot line in the past. I'll go check 6.5 a bit more closely.
vladest1 has joined #yocto
<zeddii>
also some lost interrupts. interesting. I wonder if rcu or something else is starving.
<rburton>
vvmeson: the firmware comes as a self-extracting sh. user 'agrees' to the license by setting a variable, if its set then the unpack runs the script
<rburton>
RP: doesn't look like an oom to me
<rburton>
ah there's an oom too
<rburton>
but it ends with an oops
Kubu_work has joined #yocto
<zeddii>
rburton: I suspect it is only arm64. I can OOM arm64 on a target build. but not ARM32 bit.
<vvmeson>
rburton: thanks
<landgraf>
Is there a way how to mark testcase as "known failure" in oeqa?
<zeddii>
rburton there's a proc/sysfs tunable as well for min_free_kbytes
Skinny79 has joined #yocto
MrFrank has quit [Remote host closed the connection]
<qschulz>
tlwoerner: sorry, <life> happening right now, ping me tomorrow if I haven't answered your mails
Guest98 has quit [Ping timeout: 245 seconds]
radanter has quit [Remote host closed the connection]
florian_kc has quit [Ping timeout: 240 seconds]
GillesMM has joined #yocto
geoffhp has joined #yocto
bhstalel has quit [Ping timeout: 245 seconds]
flom84 has quit [Ping timeout: 240 seconds]
leon-anavi has quit [Quit: Leaving]
<RP>
zeddii, rburton: ltp has a binary called min_free_bytes ./opt/ltp/testcases/bin/min_free_kbytes
Skinny79 has quit [Ping timeout: 245 seconds]
jetm_ has joined #yocto
jetm_ has quit [Client Quit]
<zeddii>
that's interesting.
speeder has joined #yocto
<JerryM>
RP: when you add commits from e.g. oe-core to poky do you use something to get the oe-rev in the commit message?
florian_kc has joined #yocto
<JaMa>
JerryM: see combo-layer script in oe-core
<rburton>
JerryM: if you want to combine multiple git repos into one, i recommend using something like git subtrees instead of combo-layer.
speeder_ has joined #yocto
<JerryM>
rburton: it's for a mixin layer, I'm really just backporting files from master to kirkstone but I'd like to get an OE-rev in the commits so I can more easily track the stuff
<JerryM>
JaMa: the hook script seems to contain that part thanks :)
speeder has quit [Ping timeout: 272 seconds]
speeder_ is now known as speeder
speeder_ has joined #yocto
speeder has quit [Ping timeout: 260 seconds]
speeder_ has quit [Ping timeout: 260 seconds]
speeder has joined #yocto
speeder has quit [Ping timeout: 255 seconds]
PhoenixMage has quit [Ping timeout: 255 seconds]
PhoenixMage has joined #yocto
JerryM has quit [Quit: Konversation terminated!]
florian_kc has quit [Ping timeout: 272 seconds]
flom84 has joined #yocto
flom84 has quit [Remote host closed the connection]
chat89 has quit [Quit: Client closed]
mvlad has quit [Remote host closed the connection]
<sveinse>
I'm trying to build kirkstone on wsl2 and it is stuck at burning 100% CPU during parsing. I'm not sure it is able to finish. Its bash processes running git ls-remote that hangs. Its only the bash, as git is not running any more. Is this a known issue?
<RP>
sveinse: I've not heard any report of it
prabhakarlad has joined #yocto
MrFrank has joined #yocto
behanw has joined #yocto
alessioigor has quit [Remote host closed the connection]
<sveinse>
RP: I found the culprit and fixed it. bitbake doesn't play nice with a loded pyenv (and possibly a more recent python). Vanilla poky kirkstone without any changes to the default MACHINE parsed ok thou, so I presume it's a specific git ls-remote command operation that croaked.
<JPEW>
moto-timo: Any chance you could help me figure out the recipe to install a pip module that uses poetry & cython (if that's even possible): https://github.com/long2ice/asyncmy
<JPEW>
Most of the time, the python modules are so easy I can just copy-pasta them :D
<sveinse>
Not to interfere, but is cython-native able to generate code for target?
Guest11 has joined #yocto
<JPEW>
I... don't actually know. Weirdly, when I run the same build command on my local machine, it also produces no wheel :/
<sveinse>
Building complete images take time.. But ooof, ever tried cross compiling nodejs? It's do_compile takes in well excess of an hour
<moto-timo>
lists of things that take forever: webkit, rust, nodejs...
PhoenixMage has quit [Ping timeout: 240 seconds]
<JPEW>
Hmm, I think they make their releases using poetry, so I'm guessing something is wrong in their config
* tgamblin
lurks
<moto-timo>
well gee, that do_compile is 100% useless
<tgamblin>
I went and tried an --editable install with pip... it states that it generated the wheel and where it put it, but neither of those things seems to exist?
<tgamblin>
what is going on with this module?
* moto-timo
thinks tgamblin will just try to convert it to hatchling
prabhakarlad has quit [Quit: Client closed]
<tgamblin>
bow to the serpent god
* moto-timo
thinks tgamblin has serpent god blood
<moto-timo>
yeah... this smells like bad/missing config
<moto-timo>
tgamblin: seems like it wants full blown poetry? this is a weird one
<tgamblin>
JPEW: worth a try
<moto-timo>
the python ecosystem just keeps getting stranger and stranger
<JPEW>
`poetry build` does seem to do the thing. I'm guessing that's how they do all the releases so they don't notice it's not quite right
* moto-timo
goes to write a new "moto-timo" build backend that is no different than anything else
<tgamblin>
moto-timo: 1. clone repo; 2. setup virtualenv; 3. pip install poetry; 4. poetry build --> get sdist dir with .whl and .tar.gz
<JPEW>
`inherit python3_dwim`
PhoenixMage has joined #yocto
<moto-timo>
I started down a path of full poetry recipe, but I didn't have a need (this was back in the pre-kirkstone release madness)
<tgamblin>
moto-timo: so you are correct, it seems
<moto-timo>
`inherit make_bitbake_psychic`
<moto-timo>
heavy sigh
<moto-timo>
so that poetry.core backend is a lie then it appears
<JPEW>
On the bright side, I've almost got the hash equivalence server (with my patches) building in OE as a container image you can run in podman
<moto-timo>
🎉
<JPEW>
bitbake building a bitbake recipe is trippy
<tgamblin>
bitbroil?
<JPEW>
twice-bitbaked?
* JPEW
suddenly wants potatoes
<tgamblin>
I was about to say the same
<sveinse>
bitcremate if left spinning too long
<JPEW>
Well, patching the < 7 out of aiomysql works just fine, so I think I'll just do that for now so that I have _a_ MySQL driver and worry about the more efficient one later if necessary
* tgamblin
wonders what percentage of module maintainers would accept the pulls if he sent patches to transition them all to hatchling
<moto-timo>
JPEW: 👍
<moto-timo>
Now I want potatoes
<RP>
JPEW: twice brewed. Which is the name of a good pub!
<JPEW>
Is there a standardized way to handle alternate dependencies in python modules; like `pip install sqlalchemy[async]`
rsalveti has quit [Quit: Connection closed for inactivity]
<JPEW>
Ok, I've built a container image and it works but it's not loading into podman how I would expect
<JPEW>
When I do `podman load -i <IMAGE>.tar` it makes an image named `localhost/1.0:latest` when I would have expected `localhost/<IMAGE>:1.0`... seems OCI_IMAGE_TAG is not working as expected maybe?
Kubu_work has quit [Quit: Leaving.]
Danct12 has quit [Ping timeout: 272 seconds]
goliath has quit [Quit: SIGSEGV]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]