Monday, 2021-06-28

*** alejandr1 <alejandr1!> has joined #yocto00:10
*** nerdboy_ is now known as nerdboy00:43
*** sakoman <sakoman!~steve@> has quit IRC (Read error: Connection reset by peer)00:49
*** jpuhlman__ <jpuhlman__!> has joined #yocto01:00
*** jpuhlman_ <jpuhlman_!> has quit IRC (Ping timeout: 258 seconds)01:04
*** sakoman <sakoman!~steve@> has joined #yocto01:06
*** sakoman <sakoman!~steve@> has quit IRC (Quit: Leaving.)01:36
*** camus <camus!~Instantbi@> has joined #yocto02:00
*** georgem <georgem!> has quit IRC (Quit: Connection closed for inactivity)02:20
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 265 seconds)02:30
*** camus1 <camus1!~Instantbi@> has joined #yocto03:46
*** camus <camus!~Instantbi@> has quit IRC (Remote host closed the connection)03:47
*** camus1 is now known as camus03:47
*** paulg <paulg!> has quit IRC (Ping timeout: 272 seconds)04:29
*** davidinux1 <davidinux1!~davidinux@> has joined #yocto05:27
*** davidinux1 is now known as davidinux05:27
*** manuel_ <manuel_!~manuel198@2a02:1748:dd5c:f290:8556:c345:51b7:4aae> has quit IRC (Ping timeout: 246 seconds)05:30
*** rob_w <rob_w!> has joined #yocto05:42
*** jonah1024 <jonah1024!> has joined #yocto05:46
*** goliath <goliath!~goliath@user/goliath> has joined #yocto06:09
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto06:25
*** camus1 <camus1!~Instantbi@> has joined #yocto06:26
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)06:26
*** camus1 is now known as camus06:26
*** Guest32 <Guest32!~Guest32@> has joined #yocto06:26
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 265 seconds)06:30
Guest32I tried to upgrade the Yocto version from Dunfell to Hardknott.  But after upgrading to hardknott I don't see the libpcre2 package under /usr/lib/. Below are the missing so files with hardknott installed:06:32
*** mckoan|away is now known as mckoan06:33
mckoangood morning06:33
*** davidinux <davidinux!~davidinux@> has joined #yocto06:34
Guest32good morning06:34
Guest32any input on this?06:38
*** frieder <frieder!> has joined #yocto06:39
*** Guest3216 <Guest3216!~Guest32@> has joined #yocto06:45
*** Guest3216 <Guest3216!~Guest32@> has quit IRC (Client Quit)06:45
*** RKBH <RKBH!~RKBH@> has joined #yocto06:45
*** Guest32 <Guest32!~Guest32@> has quit IRC (Ping timeout: 246 seconds)06:48
*** rfried <rfried!> has quit IRC (Quit: The Lounge -
*** rfried <rfried!> has joined #yocto06:52
*** cquast <cquast!~cquast@> has joined #yocto06:54
*** florian <florian!> has joined #yocto07:00
*** zpfvo <zpfvo!~fvo@> has joined #yocto07:00
*** prabhakarlad <prabhakarlad!> has joined #yocto07:01
*** manuel_ <manuel_!~manuel198@> has joined #yocto07:12
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)07:13
*** tnovotny <tnovotny!> has joined #yocto07:15
*** RKBH <RKBH!~RKBH@> has quit IRC (Quit: Client closed)07:15
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)07:35
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:36
*** manuel_ is now known as Manuel198507:39
*** ant__ <ant__!> has quit IRC (Remote host closed the connection)07:39
*** Manuel1985 is now known as manuel198507:39
*** leonanavi <leonanavi!~Leon@> has joined #yocto07:42
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Ping timeout: 258 seconds)07:44
*** leonanavi is now known as leon-anavi07:45
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Client Quit)07:45
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto07:45
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto08:06
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Remote host closed the connection)08:10
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto08:10
*** mihai <mihai!~mihai@> has joined #yocto08:23
RPpaulbarker: that patchset makes things worse I'm afraid:
RPpaulbarker: looks like it is on the older distros08:24
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Remote host closed the connection)08:27
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto08:29
paulbarkerRP: At least it's a quick failure now!08:35
paulbarkerRP: Is there a quick way to tell which python version bitbake is running under?08:40
paulbarkerAs Debian 8 will be using the buildtools tarball I guess older distro actually means newer python08:43
*** frieder <frieder!> has quit IRC (Ping timeout: 268 seconds)08:51
kanavinwhy is debian 8 builder even active still?09:04
*** frieder <frieder!> has joined #yocto09:04
RPpaulbarker: right, a lot of those (all?) would be using buildtools, yes09:05
paulbarkerRP: I'll see if I can grab the latest buildtools tarball and run a build with that locally09:11
RPpaulbarker: you can see which one it is using from the helper09:18
RP(it says which hosts at the end too(09:19
paulbarkerRP: Thank you! I'll grab that and set it up here09:19
paulbarkerIt'll be on opensuse-15.3 but I think the issue here may be due to the Python version so as long as that matches I should hopefully see it fail09:20
paulbarkerIf it all works fine I guess it's time for a Debian 8 VM, though that will take longer09:20
RPpaulbarker: I'm not sure what the trigger was but that seems the logical place to start...09:20
RPpaulbarker: could be as simple as something missing from buildtools :/09:21
paulbarkerRP: Just to confirm - is the hashserv instance running from the same commit of bitbake during these tests? Or is that running from a known-good commit?09:21
RPpaulbarker: the hashserve is a single instance autobuilder wide and unchanged during these tests  -that would be upgraded separately as it is standalone09:22
RPunless tests use a local one09:22
paulbarkerRP: Ok, that will narrow down where the failure could be09:23
*** zyga-mbp <zyga-mbp!> has joined #yocto09:26
*** gourve_l <gourve_l!> has quit IRC (Ping timeout: 258 seconds)09:34
*** zyga-mbp <zyga-mbp!> has quit IRC (Read error: Connection reset by peer)09:39
*** zyga-mbp <zyga-mbp!> has joined #yocto09:40
*** gourve_l <gourve_l!> has joined #yocto09:47
*** florian <florian!> has joined #yocto09:55
*** frieder <frieder!> has quit IRC (Ping timeout: 272 seconds)09:58
kanavinrburton, RP: zstd decompresses 10 times faster than xz. I'll look into switching rpm compression to that in 4.17 timeframe, as we could get drastically faster do_rootfs and do_populate_sdk from it.10:12
kanavin(rpm 4.17 that is, currently in rc)10:13
*** camus1 <camus1!~Instantbi@> has joined #yocto10:14
kanavincompression times are similar10:14
RPkanavin: sounds nice! :)10:16
kanavinRP, rburton : I tested with 2.5 Gb tarball, 6 Gb uncompressed10:16
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 272 seconds)10:16
*** camus1 is now known as camus10:16
RPrburton: I just did some stats collection. 18 ptest AB-INT failures, 8 only ever seen on arm host :/10:16
kanavinxz took 110 seconds, zstd 10 seconds (!!!)10:16
rburtonRP: ouch10:17
rburtonRP: load, i imagine? weaker host?10:17
RPrburton: the stats are deceptive as where it occurred once on x86 I didn't mark as arm specific but the arm failures are much more frequent :/10:17
RPrburton: I'm not sure of the cause, we did back off the load on the arm worker but it didn't seem to improve things10:18
RPkanavin: that is pretty neat.10:18
RPrburton: we need some kind of a plan for the ptest issues as they're about 40% of the open AB-INT issues10:19
rburtonglancing at the list i half debugging 14244 so i'll finish that off10:20
perdmann_I want to create a Lib from the min protocol. ERROR: libmin-1.0-r0 do_install: oe_soinstall: is missing ELF tag 'SONAME'.10:25
rburtonyour makefile is broken10:26
*** frieder <frieder!> has joined #yocto10:26
* RP has closed 11 of the AB-INT bugs, down to 46 of them now10:28
perdmann_rburton: i dont have a makefile ...
RPrburton: in the interests of closing bugs - - the remaining issue is overlap of files. Does the sstate code not detect that? Maybe it didn't due to the quoting issue?10:37
rburtonperdmann_: please write a makefile, and delete most of that recipe10:42
rburtonperdmann_: there's a perfectly good cmakelists in the repo you're cloning, why are you building by hand?10:43
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 272 seconds)10:43
rburtonperdmann_: your recipe can most likely be just  SRC_URI/S assignments, and inherit cmake10:44
*** davidinux <davidinux!~davidinux@> has joined #yocto10:45
*** bunk <bunk!~bunk@debian/bunk> has joined #yocto10:56
RPrburton: hmm, you're right about the directory race :/10:59
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)11:00
RPrburton: code even says "        # We can race against another package populating directories as we're removing them so we ignore errors here." :/11:02
*** florian_kc <florian_kc!> has joined #yocto11:02
RPthat isn't enough :(11:02
rburtonwhat race?11:02
rburtonobviously, i'm always right11:03
RPrburton: - sstate can be running sstate_clean_manifest whilst another task extracts files11:03
RPrburton: always :)11:03
rburtonoh that, yeah11:03
rburtonjust bite the bullet and put a read/write lock on pkgdata11:04
rburtonor sstate in general11:04
RPrburton: its a general sstate problem though :(11:04
RPrburton: the read/write locks are painful on performance11:04
rburtonworth benchmarking though?11:05
RPrburton: I have before a long time ago11:05
RPrburton: imagine a build where all the setscene tasks end up serialised :/11:05
*** zyga-mbp <zyga-mbp!> has joined #yocto11:13
*** camus1 <camus1!~Instantbi@> has joined #yocto11:22
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)11:23
*** camus1 is now known as camus11:23
perdmann_rburton: that cmake file does not create a so11:28
perdmann_rburton: ohhh it is . i see... iam sorry. i will inherit cmake and try again, thank11:29
zeddRP: 5.13 dropped, so I'm finalizing the libc-headers and reference recipes now ... I'll triple check that our LTP and rcu stall changes are there (I've been testing them on 5.13 already), since they won't be mainline quite yet.11:29
rburtonperdmann_: delete 99% of the recipe in the process, most of that recipe is redundant or actively hardful11:29
RPzedd: thanks. We managed to close a lovely number of AB-INT bugs with those :)11:31
RPzedd: 58 down to 4611:32
rburtonis that rcu lock the core problem?  and now it will stall on load but not crash and die?11:32
zeddawesome. and I hope the remaining are less annoying, :D hopefully no more kernel ones.11:32
zeddbut we obviously should document those as "why the yocto AB stress testing helps the world"11:33
RPrburton: we'll get warnings now but not hangs, the hang was the problem11:33
rburtonas the stalls are not massively unexpected when on heavy load, that's fine11:34
RPrburton: exactly11:34
RPwe can live with the odd stall. Locking up the VM is antisocial though11:34
perdmann_rburton: so i dont need SOFILE and these SO related stuff?11:35
RPzedd: it means I can't ignore the "bitbake server timeout" issue for much longer :(11:35
RPzedd: I'd rather debug the kernel than try and fix that :(11:35
rburtonperdmann_: no, that's all default11:35
rburtonand the insane skips were because you were building wrong11:35
RPzedd: I've closed most of the qemu weirdness bugs on the basis we should reopen new ones with "good" data11:36
zeddRP: indeed. I'm thinking it is even harder to reproduce for debugging as in the guts of things11:36
RPzedd: I know what the bitbake server issue is. I could just increase the timeout as it is an IO problem. I just don't like doing that :/11:36
zeddRP: yah, that's the most efficient way to get real ones to pop back up.11:36
RPReally the whole bitbake server thing needs rewriting11:36
RPzedd: torn between hacking around it or doing some nasty rewrite11:37
* zedd is always tempted by rewrites :D11:37
* RP remembers the large number of races we fixed in this code already11:38
perdmann_rburton: thanks...11:39
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)11:50
*** georgem <georgem!> has joined #yocto12:00
*** zyga-mbp <zyga-mbp!> has joined #yocto12:01
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Quit: ZNC 1.8.2 -
*** argonautx <argonautx!> has joined #yocto12:21
perdmann_rburton: ok, i removed evything and added the line "inherit cmake"12:24
perdmann_But then bitbake tells me its missing an install task, so i readded the install task but then i get some SONAME Error12:24
rburtoninherit cmake will provide an install task12:26
rburtonpastebin your recipe?12:26
perdmann_rburton: of course12:26
rburtonmaybe the cmakelists is broken too12:26
rburtonyou just need to respect CC CPPFLAGS CFLAGS LDFLAGS etc,all in the environment12:26
rburtoncmake does that normally, but people can write bad cmakefiles that explicitly don't12:27
rburtononly so much you can do when people actively break stuff12:27
rburtonRP: think i fixed the util-linux one12:27
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto12:28
rburtonperdmann_: you can remove FILESEXTRAPATHS and all your FILES_12:28
rburtoncmake.bbclass definitely has an install task12:28
rburtonunless the cmake doesn't have an install action, which is what you mean12:28
perdmann_rburton: | ninja: error: unknown target 'install'12:29
rburtonyeah their cmake doesn't provide an install then12:29
perdmann_rburton: yes, so do_install just calls this install section, which i dont have12:29
rburtonand they didn't set a soname in the library either12:30
perdmann_Thats why it only build an .a file?12:30
rburtonoh if it only builds a .a then that's exactly why there's no soname, just install the .a12:30
rburtonnot using the soinstall as that's for Shared Objects, not archives12:31
perdmann_ok, i had the idea that i wanted to link that dynamical12:31
rburtonfix the cmakelist to build a shared library then12:31
perdmann_with a patch?12:31
rburtoneasier, and you get to send it upstream too12:31
perdmann_rburton: sounds like a good idea12:32
perdmann_i will, i just need to find out how to do that in cmake12:32
rburtoniirc you just add SHARED in the build library statement12:34
rburtonRP: turns out util-linux ptest wasn't testing most of util-linux12:34
RPrburton: Why am I not surprised :(12:38
rburtonthis was a relatively recent change but it should have been spotted in ptest regressions12:39
perdmann_rburton: yes. Lets see. :)12:39
rburtonooh util-linux can now build with meson12:40
RPrburton: I worry we don't handle regression tests correctly :(12:43
rburtonme too12:43
rburtoni think the lack of a decent machine readable format doesn't help12:44
rburtonqa should be able to generate a table of all the tests and their results12:44
perdmann_rburton: it works12:48
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)12:49
perdmann_install still missing... whats your suggestion: CMake patch file for install or do_install12:49
RPrburton: we have a machine readable format?12:50
rburtonwell, sort of :)12:50
RPrburton: the hard part is finding the one to compare against automatically12:50
rburtonyou do quite often see mangled test names as it got all confused12:50
RPrburton: they should at least get mangled consistently12:50
*** zyga-mbp <zyga-mbp!> has joined #yocto12:51
*** paulg <paulg!> has joined #yocto13:15
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)13:15
*** zyga-mbp <zyga-mbp!> has joined #yocto13:17
RPrburton:  I think is related too13:22
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 268 seconds)13:34
*** davidinux <davidinux!~davidinux@> has joined #yocto13:34
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)13:37
perdmann_rburton: IT WORKED! thanks a lot.13:41
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)13:41
*** camus1 <camus1!~Instantbi@> has joined #yocto13:43
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 272 seconds)13:45
*** camus1 is now known as camus13:45
*** Falital <Falital!> has joined #yocto13:48
jonesv[m]Is it not possible to have recipes point to closed git repos? I was hoping that bitbake would just try to use my user ssh key, but it appears it does not 😕13:54
jonesv[m]Or maybe it does not work with a passphrase-protected key?13:54
jonesv[m]<jonesv[m] "Or maybe it does not work with a"> oooh, if I use `ssh-agent` it works. It just does not want to ask for my password apparently13:54
rburtonyeah, agents work, escaping from several layers of abstraction to ask for a password less so13:57
rburtonalso agents work in automated builds, asking a non-existent user to enter a password doesn't work well13:57
*** otavio <otavio!> has quit IRC (Remote host closed the connection)14:02
*** sakoman <sakoman!~steve@> has joined #yocto14:03
*** otavio <otavio!> has joined #yocto14:04
*** zyga-mbp <zyga-mbp!> has joined #yocto14:05
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)14:21
*** tlwoerner <tlwoerner!> has quit IRC (Remote host closed the connection)14:22
*** tlwoerner <tlwoerner!> has joined #yocto14:22
*** tnovotny <tnovotny!> has quit IRC (Quit: Leaving)14:31
*** sakoman <sakoman!~steve@> has quit IRC (Remote host closed the connection)14:34
*** sakoman <sakoman!~steve@> has joined #yocto14:35
*** jonah1024 <jonah1024!> has quit IRC (Quit: Connection closed for inactivity)14:37
*** jonah1024 <jonah1024!> has joined #yocto14:39
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 268 seconds)14:54
*** davidinux <davidinux!~davidinux@> has joined #yocto14:55
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto14:59
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)15:04
overridemorning, can someone link me to a some systemd service recipe templates? About to write my first one, so need something to go off of.15:07
overridejust a template that'll help me figure out what to inherit and all maybe15:09
overridemckoan: thanks!15:11
overridemckoan: whats a good way to figure out if ive got systemd enabaled by default on my image, as opposed to systemV?15:23
*** zyga-mbp <zyga-mbp!> has joined #yocto15:28
*** argonautx <argonautx!> has quit IRC (Ping timeout: 252 seconds)15:28
mckoanoverride: seen from Yocto build point of vew or from the target system?15:29
*** argonautx <argonautx!> has joined #yocto15:29
overridebuild pov, mckoan:15:29
mckoanoverride: if you have DISTRO_FEATURES_append = " systemd"15:30
overridegot it, thanks!15:30
*** frieder <frieder!> has quit IRC (Remote host closed the connection)15:31
jonesv[m]There is something I don't get yet. An image is a group of packages. I can define multiple different images, and build them with `bitbake flavor1-image` or `bitbake flavor2-image`, right? And I define flavor1 in say `meta-flavor1`, and flavor2 in say `meta-flavor2`. So in my bblayers.conf, I have both those layers included. And if they both contain a `bbappend` (say they both create a config file for hostapd), then those two bbappend conflict15:34
jonesv[m]with each other.15:34
jonesv[m]Is there a way to not have meta-flavor1 look into the meta-flavor2 layer?15:34
jonesv[m]My guess is that they should be both in the same layer, say `meta-myproject`, and there I should define two images: `recipes-flavor1` and `recipes-flavor2`. But in my case, I have images that are quite different from each other (i.e. different projects), so they don't feel like they belong to the same layer. However, I don't want to checkout a new poky setup for each project, because then it will take a ton of disk space and I need to rebuild15:34
jonesv[m]everything from scratch for each new project 😕15:34
*** zyga-mbp <zyga-mbp!> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)15:40
*** frieder <frieder!> has joined #yocto15:58
*** frieder_ <frieder_!> has joined #yocto16:02
*** frieder <frieder!> has quit IRC (Ping timeout: 265 seconds)16:03
*** zpfvo <zpfvo!~fvo@> has quit IRC (Remote host closed the connection)16:03
*** frieder_ <frieder_!> has quit IRC (Remote host closed the connection)16:06
*** mckoan is now known as mckoan|away16:15
*** florian_kc <florian_kc!> has quit IRC (Quit: Ex-Chat)16:22
* paulg is almost afraid to ask if the autobuilder is ok, or still spitting out random RCU implicated spews...16:23
*** florian <florian!> has quit IRC (Ping timeout: 272 seconds)16:25
*** Vineela <Vineela!~vtummala@user/vineela> has joined #yocto16:44
*** jonah1024 <jonah1024!> has quit IRC (Quit: Connection closed for inactivity)16:47
jonesv[m]I tried to formalize my question here, if somebody is interested:
TartarusJPEW: Hey, mingw tangent question.  Is SDK_ARCHIVE_TYPE expected to be set in local.conf ?  It's not in BB_ENV_EXTRAWHITE_OE under scripts/oe-buildenv-internal16:53
Tartarusor is tar.xz really just easy enough to work with in Windows these days it doesn't matter?  I haven't shuffled + rebooted for this quick PoC I built yet :)16:55
JPEWTartarus: It should be set in local.conf... not sure if it should be in EXTRAWHITE16:55
TartarusOK, easy enough, thanks.16:56
JPEWLast I check, tar.gz has some troubles on Windows, but TBH we don't use either that *or* zip and have a self extracting python file.... which I _still_ need to upstream16:57
overrideanyone know what layer oe keeps nginx recipe under?17:03
TartarusJPEW: I was a little surprised there wasn't an installer like Linux, but only a little.  Just doing a PoC for a quote for a customer atm anyhow17:05
RPpaulg: much happier17:06
JPEWTartarus: Ya. I wanted to do a unified replacement for the installer that used python so it would be the same on both MinGW and Linux17:06
JPEWBut still a work in progress17:06
RPpaulg: I closed about 12 open bugs on the basis that several were related...17:06
JPEWTartarus: The basic idea is to create a tar.gz file with the SDK contents, then use Python to extract it and do the pre/post processing17:07
JPEWTartarus: There is a pretty interesting trick that Python has where if the archive is a zip file, it will extract the contents to a temporary directory and execute from them; this would allow you to efficiently package the SDK tar.gz with the extraction script in a single file17:08
overriderbuton: in a service file for systemd, would something like Requires=nginx.service work, or would I have to use a vraiable or soemthing for nginix?17:19
overridethe service im working with has a lot going on for nginx, so Im trying to how that would work17:20
paulgRP, well that is good news.17:21
RPpaulg: yes, its made me a lot happier17:25
*** Falital <Falital!> has quit IRC (Ping timeout: 272 seconds)17:25
overridebasically when I bring in nginx using a recipe, can I be writing services with stuff like Requires=nginx.service?17:25
paulgRP, was that 12 just for RCU dain-bramage alone, or also including earlier LTP/cgroup wreckage?17:27
JPEWoverride: Recipes with systemd support will list the services they install in the SYSTEMD_SERVICE variables17:31
JPEWHmm, I had several jobs timeout when trying to share DL_DIR over NFS. It looks like they all deadlocked trying to flock the .lock file17:35
JPEWAnyone else see such a thing?17:35
*** BCMM <BCMM!~BCMM@user/bcmm> has quit IRC (Ping timeout: 258 seconds)17:45
*** creich <creich!> has quit IRC (Remote host closed the connection)17:57
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)18:04
*** camus <camus!~Instantbi@> has joined #yocto18:04
*** ant__ <ant__!> has joined #yocto18:15
*** xmn <xmn!> has joined #yocto18:26
*** camus1 <camus1!~Instantbi@> has joined #yocto18:39
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)18:40
*** camus1 is now known as camus18:40
chrfleDoes anyone know if block devices which are not mounted are automatically synced upon reboot18:45
*** Guest15 <Guest15!~Guest15@> has quit IRC (Quit: Client closed)18:47
rburtonif they're not mounted... how will they have pending writes?19:00
chrflerburton: e.g. dd if=my_fancy_firmware of=/dev/sda619:04
*** Spooster <Spooster!~Spooster@user/spooster> has joined #yocto19:06
*** florian <florian!> has joined #yocto19:33
marc1chrfle: systemd will call sync() at shutdown which in turn will flush all fs and block devices caches, see:
chrflemarc1: do you know where in systemd that call is made?19:36
chrflesystemd-shutdown I presume, will go have a look19:40
*** yates <yates!> has joined #yocto19:44
*** davidinux <davidinux!~davidinux@> has quit IRC (Read error: Connection reset by peer)19:47
*** davidinux <davidinux!~davidinux@> has joined #yocto19:51
smurraychrfle: one option there is to tell dd to use direct writes19:51
*** mattofak <mattofak!> has quit IRC (Remote host closed the connection)19:56
marc1chrfle: look at shutdown.c in SD sources19:57
chrflemarc1: yeah, found it in async.c called from shutdown.c, thanks19:58
*** BCMM <BCMM!~BCMM@user/bcmm> has joined #yocto19:59
*** Falital <Falital!> has joined #yocto19:59
*** Falital <Falital!> has quit IRC (Client Quit)20:00
*** jpuhlman__ <jpuhlman__!> has quit IRC (Quit: Leaving)20:04
*** jpuhlman <jpuhlman!> has joined #yocto20:05
*** Vineela <Vineela!~vtummala@user/vineela> has quit IRC (Quit: Leaving.)20:09
*** Vineela <Vineela!~vtummala@user/vineela> has joined #yocto20:13
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto20:22
*** leonanavi <leonanavi!~Leon@> has joined #yocto20:28
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Ping timeout: 272 seconds)20:31
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 265 seconds)20:38
*** camus <camus!~Instantbi@> has joined #yocto20:38
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)20:45
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 268 seconds)20:50
SpoosterI added a kernel cfg fragment... and it looks like the recipe picked it up... and I see that it showed up in the workdir... aside from verifying the behavior by running the kernel... is there another way to verify that the new kernel was built with the options?20:52
Spoostermy fear is I just copied a random file that ends in .cfg, and it won't do anything20:52
*** davidinux <davidinux!~davidinux@> has joined #yocto20:54
smurraySpooster: look at the .config in the kernel build directory under ${WORKDIR}?20:54
SpoosterI see my .cfg fragment, a file named defconfig.cfg, and a couple others popping up in ./build/tmp/work/raspberrypi4_64-poky-linux/linux-raspberrypi/1_5.4.72+gitAUTOINC+5d52d9eea9_154de7bbd5-r020:56
Spoosterbut I don't know enough about the meta-raspberrypi recipe to know if "that's it" or if that's the ${workdir}20:56
smurraythere's a build output directory under there, for linux-raspberrypi, it'll be something like linux-raspberrypi4_64-standard-build, in there will be the final .config20:58
*** rob_w <rob_w!> has quit IRC (Read error: Connection reset by peer)21:05
RPpaulg: covered both but ltp was 2-3 of that total21:07
RPabelloni: looks like there is an arm ltp hang again21:07
RPpaulbarker: Looks like a prserver hang: :/21:08
RPpaulbarker: is there any debug we want from that?21:08
Spooster+1 smurray tyvm. Found and confirmed what I was hoping to see21:08
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)21:10
paulbarkerRP: Damn. I have no idea where it is hanging now if there's no backtrace at all. May be worth a look at the cookerdaemon log at least21:14
*** leonanavi <leonanavi!~Leon@> has quit IRC (Remote host closed the connection)21:14
*** leonanavi <leonanavi!~Leon@> has joined #yocto21:14
*** florian <florian!> has quit IRC (Ping timeout: 272 seconds)21:17
RPpaulbarker: no traceback, last command completed successfully, last command looked to be "bitbake -R conf/prexport.conf -p"21:17
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 272 seconds)21:17
*** camus <camus!~Instantbi@> has joined #yocto21:18
RPpaulbarker: that looks like something bitbake-prserv-tool would run21:18
paulbarkerRP: Ok, so that bitbake command completed successfully but the corresponding test (likely test_import_export_override_db) never finished21:19
RPpaulbarker: The cooker log says the command completed, I'm not sure the server exits21:19
paulbarkerIt's likely
RPpaulbarker: agreed, yes21:20
RP$ ps ax | grep prser21:21
RP1441773 ?        S      0:00 /bin/sh -c bitbake-prserv-tool export /home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/build-st-507461/export.inc21:21
paulbarkerSo it's probably stuck waiting for the server to shutdown, somewhere where there is no timeout21:21
RPpaulbarker: it kind of looks like bitbake's main loop thinks something is still active21:22
paulbarkerRP: Is there any way to figure out which bitbake pid is the prservice server? Maybe run `lsof` with the path to prserv.sqlite321:22
RPpaulbarker: pstree -p 144177321:23
RPpaulbarker: what looks bad is that there are a ton of parser worker zombie processes21:24
RP1444977 ?        Z      0:03 [Parser-2] <defunct>21:25
RP1444980 ?        Z      0:03 [Parser-3] <defunct>21:25
RPbut 58 of them21:25
paulbarkerSo I'm guessing the main bitbake process is stuck at
RPpaulbarker: I can see 1444905 is the prserv (or it at least has the sqlite open)21:25
paulbarkerIf you kill that pid I'd like to see if the bitbake server shuts down cleanly21:26
RPso you want me to kill it?21:26
paulbarkerYes just that pid21:26
RPpaulbarker: now also a zombie21:27
*** Spooster <Spooster!~Spooster@user/spooster> has quit IRC (Remote host closed the connection)21:28
*** Spooster <Spooster!~Spooster@user/spooster> has joined #yocto21:28
paulbarkerWell that's disappointing21:29
*** florian <florian!> has joined #yocto21:30
*** Spooster <Spooster!~Spooster@user/spooster> has quit IRC (Ping timeout: 258 seconds)21:33
paulbarkerRP: So I started with the assumption that the way cooker spawns hashserv ( is well validated21:38
paulbarkerBut that doesn't get exercised on the autobuilder as it uses a separate hashserv daemon21:39
RPpaulbarker: correct21:39
paulbarkerThat code creates the asyncio loop in the main process then runs it (??) in a subprocess21:40
paulbarkerI wonder if the next step is to rip that out for prserv so the subprocess is started first then all the prserv work (opening database, initialising asyncio loop, etc) occurs within the subprocess21:41
RPpaulbarker: this is what we use to do as it is hard to ensure the subprocesses don't hold the wrong resources. Its not very pythonic though :/21:42
RPpaulbarker: what is odd is that there is one parser thread that is still "alive" :/21:43
paulbarkerHanging code isn't very pythonic either haha21:43
*** cquast <cquast!~cquast@> has quit IRC (Ping timeout: 268 seconds)21:43
RPpaulbarker: I get a lot of complaints about the fact we use old fashioned fork() calls ;-)21:43
RPbut yes, I like old/simple in many ways for this reason21:43
paulbarkerWhat does bother me is that I've never been able to replicate the issue here. I guess it's due to a lower level of parallelism21:43
RPthe autobuilder does seem to find things at scale that most people don't :/21:44
paulbarkerI tried to run oe-selftest in parallel but it triggered the OOM killer21:44
paulbarker`oe-selftest -j12 ...`, BB_NUMBER_THREADS=12 and PARALLEL_MAKE=-j12.21:45
paulbarkerEat through 64GB RAM, 8GB swap and then the kernel started chomping processes21:46
paulbarkerI saw a load average >700 on this 6 core/12 thread machine21:46
RPpaulbarker: ok, I installed python3-dbg and we have some backtraces on the processes. Let me try and dump this into an email21:48
*** Vineela <Vineela!~vtummala@user/vineela> has quit IRC (Ping timeout: 272 seconds)21:52
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)21:52
RPpaulbarker: I've mailed it over to you. It looks to me like when bitbake forks off the parser worker threads, the worker threads are inheriting the asyncio in progress from the parent :/21:54
paulbarkerRP: Ah that would definitely break everything!21:54
*** argonautx <argonautx!> has quit IRC (Quit: Leaving)21:54
*** florian <florian!> has joined #yocto21:56
RPpaulbarker: looking more closely I'm wrong about that. It is a parser thread sitting in async clinent connection code22:00
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)22:04
*** camus1 <camus1!~Instantbi@> has joined #yocto22:04
paulbarkerRP: I'll take a look at those dumps tomorrow22:06
*** Spooster <Spooster!~Spooster@user/spooster> has joined #yocto22:06
*** camus1 is now known as camus22:07
RPpaulbarker: its sitting in prserv_dump_db() but since we killed the server now, I'm not sure what it would do. It is data at least, happy to have the stack traces22:10
*** florian <florian!> has quit IRC (Ping timeout: 258 seconds)22:18
*** leonanavi <leonanavi!~Leon@> has quit IRC (Quit: Leaving)22:33
RPabelloni, rburton: with the arm worker ltp bug, I ssh'd in and it was stuck on proc01. I installed strace, attached to the stuck process and it unblocked it and everything started running again22:35
RPI lost the log as it scrolled off my terminal buffer :(22:35
RPit is reading /proc/kmsg22:36
jonesv[m]hmm I thought I could use `${IMAGE_BASENAME}` to enable my bbappend only for a specific image, but that does not seem possible... (details here:
abelloniyeah, so proc01 is an issue on arm23:06
abelloniand it is blocked on a read23:06
*** camus1 <camus1!~Instantbi@> has joined #yocto23:09
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)23:09
*** camus1 is now known as camus23:09
jonesv[m]Would it make sense to add a COMPATIBLE_IMAGE variable, similar to COMPATIBLE_MACHINE or COMPATIBLE_HOST, that would allow me to write bbappends that are ignored on incompatible images?23:15
*** Vineela <Vineela!~vtummala@user/vineela> has joined #yocto23:16
*** fullstop_ <fullstop_!~fullstop@user/fullstop> has joined #yocto23:36
*** fullstop <fullstop!~fullstop@user/fullstop> has quit IRC (Ping timeout: 244 seconds)23:37
*** fullstop_ is now known as fullstop23:37
*** abelloni <abelloni!> has quit IRC (Ping timeout: 244 seconds)23:56
*** abelloni <abelloni!> has joined #yocto23:56
*** xantoz <xantoz!> has quit IRC (Ping timeout: 244 seconds)23:57
*** xantoz <xantoz!> has joined #yocto23:58

Generated by 2.17.2 by Marius Gedminas - find it at!