<mckoan>
shoragan: let's wait the timezone for the admin Michael Halstead
<mckoan>
schurig: not shoragan, sorry :-)
mvlad has joined #yocto
mbulut has joined #yocto
<schurig>
I wanted to create a bug about bitbake itself. https://0x0.st/XMmm.txt is an excerpt where I run it. One can clearly see the "exit 0" of the do_install method. But bitbake still says that do_install had an error.
<schurig>
I traced this back to runqueue.py, but --- even when I designed the original runqueue some 12-15 years ago, when we still had bitbucket and not git --- I'm now after so many years of not using bitbake a bit at lost of what's going on here. Probably some race around runqueue_process_waitpid()
<schurig>
runqueue_process_waitpid() can set a non-zero status as well, it doesn't need to come from the task
<schurig>
or it comes from the pickle
berton has joined #yocto
enok has joined #yocto
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #yocto
sotaoverride has quit [Server closed connection]
sotaoverride has joined #yocto
<RP>
schurig: is there a way to reproduce that at will?
<RP>
schurig: it does sound like it would be worth a bug report
<RP>
schurig: the bugzilla is running very slowly for some reason :(
enok has quit [Ping timeout: 240 seconds]
<schurig>
RP: currently I can reproduce it. However, it happens with recipes for a non-linux embedded project, which I cannot share. So I'm unsure if I can make this reproducible to others. So maybe getting guides here on how to fix it by myself might be the way to go.
<schurig>
RP: I assume no one on Poky-land experienced it so far
<schurig>
I use bitbake from git HEAD and a few of openembedded-core's classes (maybe 10%), but zero of it's recipes
<RP>
schurig: I'm not aware of anyone seeing something like that, no
wooosaiiii has quit [Ping timeout: 246 seconds]
<RP>
schurig: can you create a smaller test case just using bitbake and some dummy classes which you could share? I sometimes find reducing something to a smaller test case makes the issue more apparent
xmn has quit [Ping timeout: 246 seconds]
<mario-goulart>
Regarding bugzilla's slowness: a shot in the dark, but in a project I contribute to we had severe performance problems with trac due to the amount of HTTP session-related entries in the database that for some reason did not get cleaned up.
<RP>
schurig: I guess if it were me I'd put more logging around it, something like print statements and bb.warn() calls and try and pin down exactly what code path is happening
<RP>
schurig: also into build.py and runqueue.py
<RP>
mario-goulart: could be. I've emailed helpdesk@yoctoproject.org about it...
<RP>
schurig: I'm kind of curious how you find bitbake these days. A lot has changed in the last 12-15 years, I hope on the most part for good :)
<schurig>
When I look into log.do_install.591600 I don't see an error (the pid is from the pastebin above)
<schurig>
When I call the log.do_install.591600 from the command line "sh -x ...path.../run.do_install.591600" then I don't see an error and $? is 0
<schurig>
HOWEVER; there is also another run file there, a python snippet: run.extend_recipe_sysroot.591600 I'm unsure if that plays a role?
<RP>
schurig: that is probably a task prefunc and it could well be that which fails
<RP>
schurig: I'd suggest putting an echo "xxx" into your shell before the exit 0 just to confirm it does reach there
<RP>
schurig: you could also add some bb.warn() in to build.py exec_task* to see which functions it actually executes
<RP>
I think there is logging there so you could just make those warn instead of debug
<schurig>
RP: "in kind of curious" ... in the last 12-15 years I still made embedded devices with Linux, but I simply used Debian x86 or Debian armhf on them. The reason was that I wanted customers to be able to install any of the many already compiled Debian packages. I made a "build" system around deboostrap + dpkg that created a new image from scratch in 2 minutes --- assuming all the .debs have been downloaded already. So I had no reason to
<schurig>
use Bitbake. Not even on i.MX6Q projects.
<schurig>
However, now I work on a project that involves a very non-linuxy-kernel. And the existing build system they have is quite ... arg, I don't want the word to be censored! :-)
<schurig>
so I thought I revisit bitbake because now again I'm clearly in the fetch-patch-configure-compile cycle
<RP>
schurig: fair enough, it certainly should be able to do that!
<schurig>
when I stopped working on bitbake, it was still dead slow with higher number of packages. Zecke improved from there, if I recall right. But now it's even faster, so I cannot complain about this.
<schurig>
I think the logic around sstate might be nice, but I'm unsure if I like the heavily increased complexity around package creation. I might write my own MUCH simpler package_ipk class (or surrect a very old one) instead
<RP>
schurig: when I started it didn't execute more than one task at a time so speed has improved a bit! :)
<RP>
schurig: sstate is generic so you should be able to wrap any task in that storage functionality FWIW
<schurig>
my code was quite slow on parsing... I mean, I adopted ideas from gentoo's ebuilds for the .bb files, but with all the override possibilities it became a bottleneck.
<schurig>
Fun thing: for the "MNCI" device where I used it, I didn't even need overrides. The requirement came from the many slightly different Sharp Zaurus devices people had
<RP>
schurig: zecke did great work in sorting some of the memory usage and speed issues and we've optimised the datastore a lot over the years with things like copy-on-write functionality
<RP>
schurig: ironic given I was one of the key sharp zaurus kernel people :)
<schurig>
btw, I made a (german language) blog post of my original work on Bitbake: https://holgerschurig.github.io/de/mnci/ --- but there are some nice photos of the device I worked on, so that might be also for english speakers
<RP>
schurig: google translate works :). That device looks fun, I can see many of the trends of the time. At least you could have a 3.x kernel!
<RP>
schurig: shame it ended the way it did but the device and software sounded good
<RP>
schurig: one other thoughts btw. kernel do_install may be the first place where fakeroot is coming into play. Are you using pseudo for that?
<RP>
LD_PRELOAD errors can be weird
<schurig>
no, modified some variabled to use fakeroot
<schurig>
(in my projects I never had issues with fakeroot)
<RP>
schurig: ok, just keep in mind we gave up on it long ago
<schurig>
Ultimately I might want to remove fakeroot/pseudo completely, as the filesystem of this devices isn't linuxy (or even completely posixy). Unsure on that.
<RP>
that exit code could come from fakeroot rather than your script
<schurig>
I'll looking into this
<schurig>
BTW, things will get fun in a month or so... I'm going to evaluate of bitbake itself works nicely on macOS. Since I don't use it to build Linux, it might be able to run there successfully. openembedded-core or poky is, as far as I understand, depending on various Linux features. But maybe I can isolate the Linuxisms in bitbake
<RP>
schurig: it hopefully isn't too bad. I did drop the inotify code in bitbake recently which should help. pseudo was the main issue for macOS
eminboydak has quit [Quit: Client closed]
Guest2593 has quit [Server closed connection]
ctraven has joined #yocto
<rburton>
schurig: pseudo is definitely the main blocker, i started making bitbake work on my mac but then macOS introduced the system protection stuff and suddenly LD_PRELOAD wasn't available, which is somewhat of a blocker... if you can ignore fakeroot entirely then there shouldn't be much in bitbake that is actually linux-specific
<schurig>
RP: it was fakeroot. After I modified base.bbclass (which I adopted from OE-core) to not do fakeroots, the build worked as expected.
<schurig>
rburton: good to know
linex has joined #yocto
<linex>
hi
<linex>
copying from the matrix room since bridge seems to be disabled:
<linex>
hello,
<linex>
I have been having issues building m4-native (stack smashing detected when running the configure script). I could not find other instances of this issue on the web,
<linex>
Is there any sane way I can skip building m4-native and tell yocto to use the host package for all packages requiring it ? or can you think of any other solution, thanks
<linex>
I have also trired rebuilding from the grounds up many times to no avail, etc.
<linex>
Buidling on Ubuntu 22, on a VM, poky nanbield
<rburton>
linex: can you replicate with a fresh checkout of poky on the nanbield branch?
<rburton>
(nanbield is eol so we recommend you upgrade)
alessioigor has joined #yocto
Saur_Home81 has quit [Quit: Client closed]
Saur_Home81 has joined #yocto
enok has joined #yocto
<rburton>
linex: fwiw m4-native built fine for me on ubuntu 2204 for nanbield
enok has quit [Ping timeout: 268 seconds]
jmiehe has joined #yocto
ablu has quit [Read error: Connection reset by peer]
<RP>
schurig: glad you found the issue. We need to try and make that more obvious somehow...
ablu has joined #yocto
yocton has quit [Server closed connection]
yocton has joined #yocto
tlwoerner has quit [Ping timeout: 264 seconds]
<schurig>
RP: thanks for pointing me into the right direction
<schurig>
I guess my use-case is so special that this doesn
<schurig>
doesn't mandate a BB change
sakoman has quit [Ping timeout: 256 seconds]
<schurig>
btw, speaking of old times: I had also contact to mickeyl (Michael Lauer). He's now doing CAN apps for Android. However, kergoth and zecke ... never heard again from them.
tlwoerner has joined #yocto
<rburton>
schurig: kergoth is in #oe still, as of last year he was definitely still doing some OE stuff at work
<schurig>
cool
<RP>
schurig: kergoth is still around now and again. I've seen zecke online occasionally in other places but not on irc for a long time
linex has quit [Quit: Client closed]
davidinux2 has quit [Ping timeout: 252 seconds]
davidinux2 has joined #yocto
alessioigor has quit [Remote host closed the connection]
sakoman has joined #yocto
alessioigor has joined #yocto
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
demirok999 has quit [Server closed connection]
demirok has joined #yocto
linex has joined #yocto
<JaMa>
rburton: there is typo in subject in both yocto-autobuilder series meta-webose -> meta-webosose (if you need to update them)
lexano has joined #yocto
<RP>
JaMa: I just applied it, too late :/
* RP
should have looked here first!
<RP>
ah, no, I can fix that one
<linex>
okay so building in a container seems to fix the issue, I think it's an environment propagation issue of some sort, as I expected
linex58 has joined #yocto
linex has quit [Quit: Client closed]
adrianp has joined #yocto
amitk has joined #yocto
linex58 has quit [Quit: Client closed]
MattWeb___ has quit [Quit: Client closed]
jmiehe has quit [Quit: jmiehe]
<JaMa>
RP: thanks, no big deal otherwise I would have replied on ML
jmd has joined #yocto
<RP>
JaMa: np, I hadn't got to the helper patches so it was easy to tweak
alessioigor has quit [Remote host closed the connection]
alessioigor has joined #yocto
jmd has quit [Remote host closed the connection]
fabatera has joined #yocto
fabatera has quit [Client Quit]
MattWeb has joined #yocto
MattWeb is now known as MattWeb__
tgamblin has quit [Remote host closed the connection]
tgamblin has joined #yocto
adrianp has quit [Quit: Client closed]
fabatera has joined #yocto
<fabatera>
Hi, I'm still trying to figure out this, any hint? It's a rebuild in nanbield, after updating my/other-driver recipes. It doesn't happen in previous yocto versions. Last time I saw was in hardknott
<fabatera>
mydriver-mfg : Depends: my-driver
<fabatera>
kernel-module-jailhouse-6.6.3-lts-next-gd1973916e4d7 : Depends: kernel-6.6.3-lts-next-gd1973916e4d7 but it is not installable
<fabatera>
packagegroup-mydrivers : Depends: my-driver but it is not installable
<fabatera>
Depends: other-driver but it is not installable
<fabatera>
E: Unable to correct problems, you have held broken packages
rob_w has quit [Remote host closed the connection]
alessioigor has quit [Remote host closed the connection]
fabatera has quit [Ping timeout: 250 seconds]
<jclsn>
How to mask a systemd unit? Is there a list for it?
<jclsn>
Don't want to run a ROOTFS_POSTPROCESS_COMMAND for it
<rburton>
JaMa: goddamit every time
Xagen has joined #yocto
dgriego has quit [Quit: Computer going to sleep]
dgriego has joined #yocto
<JaMa>
rburton: should we rename it? :)
<rfs613>
how does one get python standard library into the target rootfs? for example the json and socket modules?
<rfs613>
googling suggests python3-json but I can't find that recipe... nor python3-modules for the kitchen sink
fabatera has joined #yocto
<JaMa>
rfs613: it's package built by python3 recipe
<rfs613>
ah, so i can add it to IMAGE_INSTALL, but I can't bitbake it?
<JaMa>
you bake recipes which produce packages, package manager installs packages into images
<rfs613>
right, i see the .deb file for python3-json... got sidetracked looking for a recipe
MattWeb__ has quit [Quit: Client closed]
<rfs613>
JaMa: did the trick, thanks!
<jclsn>
Btw I found out that chronyd.service does not always stop systemd-timesyncd.service from loading. Actually they should conflict by default, but I have cases where both are loaded
<jclsn>
Had to add a drop-in config to add a Before=systemd-timesyncd.service
<jclsn>
Think this is worth a patch? I don't the solution is pretty, but works at least. Maybe you guys have better ideas
<jclsn>
s/I don't/I don't think/
xmn has joined #yocto
goliath has quit [Quit: SIGSEGV]
<rburton>
rfs613: if you just want "all of python" then depend or image_install 'python3'
<rburton>
jclsn: if they conflict then surely there's a systemd unit keyword for that, _and_ package conflicts can be used too.
<rfs613>
rburton: thanks, also useful to know. Currently we have python3-core, presumably to keep size down...
frieder has quit [Remote host closed the connection]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
CrazyGecko has quit [Quit: Konversation terminated!]
<jclsn>
This does not work for me though. I had to take more measures. I think this should be upstreamed.
fabatera has quit [Quit: Client closed]
jmd has joined #yocto
jmiehe has joined #yocto
smooge has quit [Quit: I have resigned. I will not be pushed, filed, stamped, indexed, briefed, debriefed, or numbered! My life is my own.]
smooge has joined #yocto
Xagen has joined #yocto
Minvera has quit [Ping timeout: 268 seconds]
florian_kc has joined #yocto
<halstead>
schurig: The new account page was supposed to be replaced with instructions for requesting an account after recent spam attacks. I'll track down what happened. In the meantime please email it-coreprojects-helpdesk@linuxfoundation.org asking for a bugzilla account and we'll add it for you.
<rburton>
jclsn: please do
fabatera has joined #yocto
fabatera has quit [Client Quit]
Saur_Home81 has quit [Quit: Client closed]
Saur_Home81 has joined #yocto
mckoan is now known as mckoan|away
jmiehe has quit [Quit: jmiehe]
zpfvo has quit [Remote host closed the connection]