Thursday, 2021-07-22

*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)00:08
*** BobPungartnik <BobPungartnik!~Pung@> has joined #yocto00:17
*** prabhakarlad <prabhakarlad!> has quit IRC (Ping timeout: 246 seconds)01:03
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto01:08
*** fitzsim <fitzsim!> has quit IRC (Ping timeout: 265 seconds)01:08
*** fitzsim <fitzsim!> has joined #yocto01:11
*** vmeson <vmeson!> has quit IRC (Ping timeout: 258 seconds)01:12
*** vmeson <vmeson!> has joined #yocto01:16
*** sakoman <sakoman!> has quit IRC (Quit: Leaving.)01:36
*** camus1 <camus1!~Instantbi@> has joined #yocto02:26
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)02:27
*** camus1 is now known as camus02:27
*** tokamak[m] <tokamak[m]!~tokamakma@2001:470:69fc:105::c4df> has joined #yocto03:01
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: Textual IRC Client:
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto03:29
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)03:33
*** camus <camus!~Instantbi@> has joined #yocto03:33
*** amitk <amitk!~amit@> has joined #yocto03:48
*** Emantor <Emantor!> has quit IRC (Quit: ZNC -
*** paulg <paulg!> has quit IRC (Ping timeout: 268 seconds)04:05
*** Emantor <Emantor!> has joined #yocto04:05
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 240 seconds)04:41
*** Vonter <Vonter!~Vonter@user/vonter> has joined #yocto04:46
*** roussinm <roussinm!~mroussin@> has quit IRC (Quit: WeeChat 3.3-dev)05:24
*** goliath <goliath!~goliath@user/goliath> has joined #yocto05:54
*** rob_w <rob_w!> has joined #yocto06:06
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto06:07
*** manuel1985 <manuel1985!~manuel198@2a02:1748:dd5c:f290:c5b2:fdff:b718:9edf> has quit IRC (Ping timeout: 245 seconds)06:15
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 258 seconds)06:16
*** ykrons <ykrons!~guillaume@> has joined #yocto06:24
*** frieder <frieder!> has joined #yocto06:30
*** mckoan|away is now known as mckoan06:37
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Remote host closed the connection)06:48
*** alimon <alimon!> has quit IRC (Read error: Connection reset by peer)06:50
*** alimon <alimon!> has joined #yocto06:52
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)06:53
*** hpsy <hpsy!~hpsy@> has joined #yocto06:56
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto06:56
*** zpfvo <zpfvo!~fvo@> has joined #yocto06:57
*** ant__ <ant__!> has quit IRC (Remote host closed the connection)07:00
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 255 seconds)07:03
*** camus1 <camus1!~Instantbi@> has joined #yocto07:06
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 255 seconds)07:06
*** camus1 is now known as camus07:06
*** davidinux <davidinux!~davidinux@> has joined #yocto07:10
*** prabhakarlad <prabhakarlad!> has joined #yocto07:11
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto07:16
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)07:21
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 252 seconds)07:25
*** davidinux <davidinux!~davidinux@> has joined #yocto07:28
*** _franck_ <_franck_!> has left #yocto (The Lounge -
*** manuel1985 <manuel1985!~manuel198@> has joined #yocto07:31
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 256 seconds)07:34
*** goliath <goliath!~goliath@user/goliath> has joined #yocto07:39
*** camus1 <camus1!~Instantbi@> has joined #yocto07:39
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)07:40
*** camus1 is now known as camus07:40
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)07:41
*** davidinux <davidinux!~davidinux@> has joined #yocto07:42
ykronsHello all08:04
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 268 seconds)08:07
ykronsI was often using devshell to rework some patches and use quilt to update them. Today I would like to do the same with devtool but it seems patches are applied in the source tree and there is no way to use quilt.08:07
ykronsSo what is the proper way to applied remove patches during development using devtool?08:07
qschulzJPEW: re: pyrex. I removed the container image locally, re-sourced pyrex-init-buildenv, it fetched from correctly. Then I re-sourced it once again to make sure it'd take the "local copy". It seems to work as good as before.08:08
*** davidinux <davidinux!~davidinux@> has joined #yocto08:08
qschulzykrons: devtool is using git and you have a commit for each patch applied, so you can edit them manually08:09
*** davidinux <davidinux!~davidinux@> has quit IRC (Read error: Connection reset by peer)08:15
ykronsqschulz: thanks. and reworking a commit will update accordingly the corresponding patch?08:16
*** xmn <xmn!> has joined #yocto08:16
*** davidinux <davidinux!~davidinux@> has joined #yocto08:18
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 268 seconds)08:18
*** camus <camus!~Instantbi@> has joined #yocto08:19
qschulzykrons: I think there's a devtool command for that (a subcommand of devtool finish?)08:24
qschulzI replace the patches manually by running git format-patch and overwrite the original patch (or add it in a bbappend)08:24
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)08:28
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)08:28
ykronsqschulz: ok thanks08:28
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 258 seconds)08:31
*** davidinux <davidinux!~davidinux@> has joined #yocto08:33
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 255 seconds)08:38
*** camus <camus!~Instantbi@> has joined #yocto08:38
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto08:48
*** florian <florian!> has joined #yocto08:55
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 252 seconds)08:58
*** davidinux <davidinux!~davidinux@> has joined #yocto09:06
*** camus1 <camus1!~Instantbi@> has joined #yocto09:07
*** florian_kc <florian_kc!> has joined #yocto09:07
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 245 seconds)09:09
*** camus1 is now known as camus09:09
*** davidinux <davidinux!~davidinux@> has quit IRC (Ping timeout: 255 seconds)09:21
*** davidinux <davidinux!~davidinux@> has joined #yocto09:25
*** rob_w <rob_w!> has quit IRC (Ping timeout: 240 seconds)09:27
*** vmeson <vmeson!> has quit IRC (Ping timeout: 250 seconds)09:36
*** rob_w <rob_w!> has joined #yocto09:39
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)09:40
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has joined #yocto09:49
*** goliath <goliath!~goliath@user/goliath> has joined #yocto09:53
*** wing0 <wing0!~wing0@2804:431:c7ed:6171:bb13:7508:2998:4a1b> has quit IRC (Quit: WeeChat 3.1)09:54
OutBackDingook, ive got a thought, all the newest "broken" link fetches, mostly due to github changes from master to main branches. Is there possibly a way to test like bitbake fetch world, find everything broken and fix it :)09:56
RPOutBackDingo: like "bitbake universe -c fetch"? :)09:57
OutBackDingosure, then i can fixup all the brokenness and supply a single patch :)09:58
*** mattsm is now known as Guest938209:58
*** Guest9382 <Guest9382!> has quit IRC (Killed ( (Nickname regained by services)))09:58
*** mattsm <mattsm!> has joined #yocto09:58
*** mattsm <mattsm!> has quit IRC (Read error: Connection reset by peer)09:59
*** mattsm <mattsm!> has joined #yocto09:59
wyrewhy do you think I'm having this problem when shutting down the SoM from the bash cli?10:22
*** BobPungartnik <BobPungartnik!~Pung@> has quit IRC (Quit: Leaving)10:33
*** LetoThe2nd <LetoThe2nd!> has joined #yocto10:34
LetoThe2ndyo dudx10:35
Ad0upgrading from warrior to dunfell wasn't that bad10:36
Ad0what do you do though when an out of tree kernel calls functions in a newer kernel coming with the newer yocto that isn't there anymore :P I patched the kernel by reintroducing the function but that can't go on forever10:43
qschulzAd0: you port the out of tree driver to the newer kernel10:45
Ad0yeah like know that haha10:45
qschulzcheck what the function was replaced with (if it was) in git log of the kernel and do the same for your out-of-tree driver10:45
qschulzsurround all of those changes with a nice #ifdef with the version of the kernel and you're good to go10:46
Ad0no idea what the replacement for that would be10:51
Ad0I thought the mantra was "never break anything" but they did there10:52
Ad0if the driver was in-kernel it would have stayed10:53
qschulzAd0: the mantra is: out-of-tree driver, your shit to fix :)10:58
Ad0I guess10:59
qschulzthe only thing that is guaranteed to stay consistent across releases is the sysfs ABI10:59
Ad0the chip supplier has to fix it but for now I patched the kernel by reintroducing the function10:59
qschulzand it's a PITA10:59
qschulz(from kernel dev pov, but very good for userspace)10:59
Ad0and that's what they do too. they have the same patch10:59
Ad0but one day that function will break11:00
qschulzAd0: yes, and you'll need to fix it. If you want the kernel to not break your out-of-tree custom driver, upstream it11:00
*** dkl <dkl!> has quit IRC (Quit: %quit%)11:08
*** dkl <dkl!> has joined #yocto11:09
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto11:31
*** Guest26 <Guest26!~Guest26@> has quit IRC (Quit: Client closed)11:58
*** camus1 <camus1!~Instantbi@> has joined #yocto11:58
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 252 seconds)11:59
*** camus1 is now known as camus11:59
JPEWqschulz: thanks12:03
wyrewhat poky version do you recommend me to work with?12:10
rburtonlatest release12:10
wyrethe LTS is Dunfell12:11
rburtonyeah either12:11
rburtonLTS will still EOL at some point, but there'll be a new LTS to replace it12:11
rburtondepends on what sort of cadence you want to follow12:11
rburtonLTS releases are every two years.  other releases are every six months, but are EOL when the next one is released.12:12
rburtonSo if you use a non-LTS release you need to keep up12:12
*** prabhakarlad <prabhakarlad!> has quit IRC (Quit: Client closed)12:27
*** prabhakarlad <prabhakarlad!> has joined #yocto12:30
*** rob_w <rob_w!> has quit IRC (Remote host closed the connection)12:46
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Ping timeout: 258 seconds)12:50
*** jsandman <jsandman!~jsandman@> has quit IRC (Quit: Ping timeout (120 seconds))12:55
*** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has quit IRC (Read error: Connection reset by peer)12:55
*** jsandman <jsandman!~jsandman@> has joined #yocto12:55
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)12:56
*** alejandrohs <alejandrohs!> has quit IRC (Ping timeout: 265 seconds)12:57
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto12:58
*** vmeson <vmeson!> has joined #yocto12:58
*** alejandrohs <alejandrohs!> has joined #yocto12:58
*** tangofoxtrot <tangofoxtrot!~tangofoxt@user/tangofoxtrot> has joined #yocto13:00
*** yates_home <yates_home!> has joined #yocto13:02
yates_homein my build folder there is an elf application that is used in run.do_uboot_mkimage: <build>/tmp/work/qemucsky-poky-linux/linux-csky/5.12-r0/recipe-sysroot-native/usr/bin/uboot-mkimage13:04
yates_homewhere is the source for this application?13:04
rburton$ git grep uboot-mkimage13:09
rburtonrecipes-bsp/u-boot/    install -m 0755 tools/mkimage ${D}${bindir}/uboot-mkimage13:10
*** mcc_ <mcc_!> has joined #yocto13:14
Ad0I did devtool workspace finish , but yocto insists to keep building the workspace kernel sources13:15
Ad0is there some documentation to properly finish and exit the workspace so it goes back to normal yocto sources w/patch?13:15
*** creich_ <creich_!> has joined #yocto13:15
*** lucaceresoli <lucaceresoli!~lucaceres@> has joined #yocto13:15
yates_homerburton: thanks. good tip.13:15
*** zyga__ <zyga__!> has joined #yocto13:16
*** mattsm <mattsm!> has quit IRC (Killed ( (Nickname regained by services)))13:17
*** mattsm <mattsm!> has joined #yocto13:17
*** lucaceresoli <lucaceresoli!~lucaceres@> has quit IRC (Client Quit)13:17
*** splatch_ <splatch_!> has joined #yocto13:18
*** chrysh_ <chrysh_!> has joined #yocto13:18
*** Vonter <Vonter!~Vonter@user/vonter> has quit IRC (Ping timeout: 255 seconds)13:18
*** tkoskine <tkoskine!> has quit IRC (Ping timeout: 255 seconds)13:18
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 255 seconds)13:18
*** rewitt3 <rewitt3!~rewitt@> has quit IRC (Ping timeout: 255 seconds)13:18
*** splatch <splatch!> has quit IRC (Ping timeout: 255 seconds)13:18
*** florian <florian!> has quit IRC (Ping timeout: 255 seconds)13:18
*** zyga_ <zyga_!> has quit IRC (Ping timeout: 255 seconds)13:18
*** creich <creich!> has quit IRC (Ping timeout: 255 seconds)13:18
*** mccc <mccc!> has quit IRC (Ping timeout: 255 seconds)13:18
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 255 seconds)13:18
*** chrysh <chrysh!> has quit IRC (Ping timeout: 255 seconds)13:18
*** tkoskine <tkoskine!> has joined #yocto13:18
*** Vonter <Vonter!~Vonter@2406:7400:73:8f06:ba27:ebff:fe40:73d2> has joined #yocto13:18
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto13:19
yates_homeAd0: it's been a long time since i used devtool, but a) properly finishing it should work and b) there is a good bit of documentation on the tool.13:19
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #yocto13:20
Ad0I need to patch a kernel driver13:20
*** florian <florian!> has joined #yocto13:20
*** rewitt3 <rewitt3!~rewitt@> has joined #yocto13:20
yates_homeyeah, thats a perfect use-case, i think13:20
Ad0I followed this one13:20
Ad0first off "devtool modify linux-yocto" doesn't work. I have to do virtual/kernel13:21
Ad0I have some confusion between virtual/kernel and linux-raspberrypi, etc13:21
Ad0is virtual/kernel some magic alias?13:23
yates_homeAd0: virtual/kernel is defined somewhere to be a default kernel.13:23
Ad0my kernel is called linux-raspberrypi13:23
Ad0but starting devtool with that gives error13:23
Ad0virtual/kernel works. why? :)13:23
Ad0somehow devtool finish does not give error on linux-raspberrypi13:24
* Ad0 is very confused13:24
*** Schlumpf <Schlumpf!~Schlumpf@> has joined #yocto13:24
Ad0also, in warrior it started an interactive shell with screen, I can't seem to see this now13:25
rburtonsounds like you're not really using linux-rpi13:25
Ad0it does run the recipes and overrides with that name13:26
yates_homeAd0: search for "PREFERRED PROVIDER" in your custom layer or your build conf's13:26
rburtonoh right, you said 'first off "devtool modify linux-yocto" doesn't work.'13:26
rburtonyes: you are using linux-raspberrypi13:26
Ad0no matches13:27
Ad0sorry I meant  "devtool modify linux-raspberrypi"13:27
rburtonto bitbake your kernel, what do you type?13:27
Ad0I don't explicitly do that I built my image13:27
Ad0I will try it again13:27
Ad0it worked now with "devtool modify linux-raspberrypi" .13:28
Ad0must have been some strange things going on in the upgrade :)13:28
rburtonyoud only modify linux-yocto if that was the kernel you had selected13:28
rburtonideally, just use virtual/kernel everywhere13:29
Ad0so that's the alias for the current kernel13:29
Ad0yeah I should really use the virtual/kernel13:29
Ad0is it dangerous to do "devtool modify linux-raspberrypi" and then use virtual/kernel for finish , for example?13:30
Ad0also, I have a full kernel config (defconfig) I want to overwrite, what is the most appropiate way to do that in my layer? I have seen misc posts with different approaches.13:33
rburtonmisc posts are often wrong13:34
rburtonthe documentation tends to be right:
rburtonone would hope that devtool doesn't get confused if you use different aliases for the same recipe, so it *shouldn't* break13:35
rburton has more details re defconfig13:35
*** paulg <paulg!> has joined #yocto13:40
smurrayRP JPEW: if I have a stuck bitbake-server process, any pointers on digging out why?13:40
JPEWIs it possible to attach PDB to a stuck process?13:41
Ad0thanks rburton :)13:42
smurrayJPEW: I'm able to attach with gdb and poke with the python extensions, e.g. py-bt13:42
Ad0I recall that doing that gave me "defconfig was supplied both via KBUILD_DEFCONFIG and SRC_URI. Dropping SRC_URI defconfig"13:43
Ad0didn't happen in warrior, happens in dunfell13:43
rburtonmost likely meta-rpi using KBUILD_DEFCONFIG13:43
smurrayJPEW: I was doing a run with plain master poky on a loaner machine, so I have a suspicion it might be hash equiv not shutting down, but there's like > 100 threads ;)13:44
Ad0does this mean it ditches my defconfig, or should I just ignore it13:44
smurrayJPEW: err, nm, > 100 stack frames, -ENOCOFFEE13:44
rburtonAd0: "dropping SRC_URI defconfig" sounds pretty clear.  unset KBUILD_DEFCONFIG too13:45
smurrayJPEW: it's sitting in hash equiv's run_loop_forever, hence my thinking it's stuck13:46
Ad0yeah just wondered if it dropped the variable or the file itself :) was a bit unclear to me hehe13:46
JPEWsmurray: On the client side?13:46
smurrayJPEW: looks like server based on this:
JPEWsmurray: Ah you are using `BB_HASHSERVE = "auto"` ?13:49
smurraythere was a reason I asked for that run on the autobuilder13:49
smurraythis is stock poky defaults13:49
JPEWSo bitbake server itself is waiting for the hash server to exit?13:49
smurrayI think that's what it means13:50
overriderunning in to weird errors after setting up a distro. any debugging ideas would be highly appreciated. ERROR: opentrons-ot3-image-1.0-r0 do_image_complete: The recipe opentrons-ot3-image is trying to install files into a shared area when those files already exist. Those files and their manifest location are:13:51
override  /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/Verdin-iMX8MM_Reference-Minimal-Image.rootfs.manifest13:51
override    (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete)13:51
override  /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/Verdin-iMX8MM_Reference-Minimal-Image.rootfs.wic.bmap13:51
override    (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete)13:51
smurrayJPEW: it's the same failure mode as was being seen with the reworked pr serv AIUI13:51
override  /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/image-Reference-Minimal-Image.json13:51
override    (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete)13:51
override  /home/ubuntu/oe-core-6-28-21/build/deploy/images/verdin-imx8mm/Verdin-iMX8MM_Reference-Minimal-Image.rootfs.tar.xz13:51
override    (matched in manifest-verdin_imx8mm-tdx-reference-minimal-image.image_complete)13:51
overridesorry about the spam..13:51
overridewas trying to paste a pastebin link sorry so sorry13:51
overridejust ignore that for now actually13:51
JPEWsmurray: Hmm, I wonder if the server even got the singal13:59
JPEWthe SIGTERM signal that is14:00
overrideok so I keep getting the "trying to install files into a shared are where the files already exisit". for wiping out tmp do we just rm -rf it or is there some better way of going about it?14:00
smurrayJPEW: yeah, that's occurred to me just now as well from looking at the code14:00
JPEWsmurray: Can you put a break point in the signal handler in asyncrpc/ and manually send the process a SIGTERM?14:01
smurrayJPEW: I'll try, not used the gdb python extensions very much before14:02
JPEWsmurray: Me either14:03
qschulzoverride: rm -rf it, or I think just removing the inode of the directory is enough? don't remember, but I always rm -rf :)14:05
qschulzmake sure you don't have your sstate-cache and downloads dir in your tmp14:06
overrideqschulz: not sure why but i did an rm -rf on my deploy folder too14:07
qschulzoverride: shouldnt deploy be in your tmp dir by default?14:07
overrideohhh, maybe its not.. remeber rburton pointed that out once. my bso is putting it elsewhere14:08
*** sakoman <sakoman!> has joined #yocto14:10
*** manuel1985 <manuel1985!~manuel198@> has quit IRC (Quit: Leaving)14:11
JPEWsmurray: I wonder if there is still a connected client that is preventing the loop from exiting14:12
*** rcw <rcw!~rcwoolley@> has quit IRC (Quit: Leaving)14:14
smurrayJPEW: there are no other processes at this point that I see, just this one cooker + hash equiv server set after a oe-selftest run with a bunch more errors than expected14:18
smurrayJPEW: looking in cooker, it's where you'd expect, it's waiting on the join after the process.terminate14:19
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)14:20
JPEWToo bad the async server doesn't log when it gets a new client connection14:21
smurrayyeah, I suspect it might take a bit of instrumentation to work through this14:29
JPEWsmurray: How easily can you reproduce?14:30
*** zyga-mbp <zyga-mbp!> has joined #yocto14:30
smurrayJPEW: somewhat reliably, I suspect, but it takes hours since it's running oe-selftest14:30
smurrayJPEW: heh, I've found examples of setting breakpoints on python function name, but they're all for py2, and of course the unicode stuff in py3 makes them obsolete14:32
JPEWOk. I'll give you a new patch with some logging14:32
JPEWI *think* I might know what the problem is14:32
JPEWOr at least I think I can fix it if the theory is that there is a dangling client preventing the loop from exiting14:33
*** Guest26 <Guest26!~Guest26@> has joined #yocto14:33
Ad0rburton, "ERROR: No recipe named 'virtual/kernel' in your workspace14:33
Ad0" even if I did "devtool modify virtual/kernel"14:33
Ad0first I did "devtool modify virtual/kernel" - that worked, then "devtool build virtual/kernel".14:34
smurrayJPEW: would there be an open socket around from that that I could poke around for?  or I can maybe dig down to look at the asyncio loop object contents in gdb...14:36
JPEWsmurray: Good call! there should be a unix domain socket in /proc/PID/fds14:36
*** LetoThe2nd <LetoThe2nd!> has quit IRC (Quit: Connection closed for inactivity)14:40
smurrayJPEW: there are a few:
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has quit IRC (Remote host closed the connection)14:45
*** bps <bps!> has joined #yocto14:57
JPEWsmurray: are you sure it's stuck in loop.run_forever()?14:59
*** Schlumpf <Schlumpf!~Schlumpf@> has quit IRC (Quit: Client closed)15:00
smurrayJPEW: every time I attach to the process it's in there, so I'd say yes?15:01
JPEWsmurray: Ok, can you post the callstack?15:01
smurrayJPEW: this, you mean?:
JPEWsmurray: Ya thanks15:02
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Read error: Connection reset by peer)15:04
*** mihai <mihai!~mihai@user/mihai> has joined #yocto15:04
smurrayJPEW: this gets truncated, but might be helpful:
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Read error: Connection reset by peer)15:05
smurrayJPEW: I notice the loop has a _stopping=False internal value15:05
JPEWAlso _closed=False15:05
JPEWSo I think it's not getting the signal for some reason15:06
smurrayJPEW: yeah, but it's unclear to me how that SIGTERM would get dropped15:06
JPEWEither it's blocked, or the signal arrived before the server installed the handler....15:07
JPEWHmm, I but I can test that :)15:08
JPEWsmurray: What test is it failing on?15:09
smurrayJPEW: I don't believe it's any specific test, that's been the problem, random failures under heavy load15:09
*** mihai <mihai!~mihai@user/mihai> has joined #yocto15:14
*** mihai <mihai!~mihai@user/mihai> has quit IRC (Read error: Connection reset by peer)15:15
*** mihai <mihai!~mihai@user/mihai> has joined #yocto15:19
JPEWsmurray: Ok, I think maybe I can reproduce it in a simple test case, I'll push it up and see what you think15:19
smurrayJPEW: if you have logging or a potential fix, I can kick off a run, would hopefully see results later this aft or in the evening15:20
JPEWK. The fix is a little more involved... but I'll work on one15:20
smurrayheh, even logging to confirm the problem would be good ;)15:21
JPEWI *think* that the loop not being in the _closed state is sufficient, but yes, I'll add some logging for the signal handler15:22
RPsmurray, JPEW: if/as/when there are patches you think I should merge, can you point me at them. I don't know what to with the ones in -next really now :/15:25
JPEWI'll take a look at the patches in -next and see what needs done after I write up the proposed fix15:26
smurrayRP: I think you just have a couple of minor bits, not the whole pr server rework to use asyncrpc?15:28
RPsmurray: correct, just not sure if those should be going in or not15:29
smurrayRP: the bad message error message change seems innocuous enough, the 30s timeout for the client is maybe more debatable15:32
smurrayRP: but if that's working on the autobuilder, then it seems unlikely to be a problem in general perhaps15:34
*** xmn <xmn!> has joined #yocto15:34
JPEWIf the theory is correct, it's only a problem under high load when bitbake-server attempts to exit before the hashserver/prserver have installed their signal handler (so unlikely in cases other than the AB)15:35
JPEWIt's a race basically15:36
smurrayah, interesting15:44
smurrayI have a change in my local work to shift where the loop gets created that I could maybe repurpose to block for that15:44
JPEWThe fix is to mask of the SIGTERM signal before we start the server so that inherits that mask, then unblock the signal in the hashserve process after it's install the handler (which will immediately deliver any pending signals)15:45
smurrayah, much better than my thought ;)15:45
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto15:45
JPEWI'm putting a wrapper in AsyncServer to do this so it's easier15:46
smurrayJPEW: do you think there's still benefit to shifting the asyncio loop creation into the child process?15:46
JPEWsmurray: I'm not sure15:46
JPEWLets see if this fixes it first15:46
rfs613what could be causing the "do_build" step of every recipe to have a dependency on "db.do_package_write_deb" ?16:09
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)16:09
*** florian_kc <florian_kc!> has quit IRC (Ping timeout: 255 seconds)16:11
smurrayrfs613: deb packaging is turned on, i.e. package_deb is in PACKAGE_CLASSES16:13
rfs613smurray: and this needs berkley DB?16:14
smurrayrfs613: I'm not sure about dpkg, but I think dnf may, and I believe it's used even with deb16:16
rfs613smurray: hmm, okay, i'll go digging there... thanks ;-)16:16
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto16:17
*** xmn <xmn!> has joined #yocto16:17
smurrayrfs613: no worries, good luck16:17
*** zpfvo <zpfvo!~fvo@> has quit IRC (Remote host closed the connection)16:19
JPEWRP, smurray : Patch send to bitbake ML16:19
*** florian <florian!> has quit IRC (Quit: Ex-Chat)16:21
JPEWIf you comment out the signal.pthread_sigmask() in AsyncServer.serve_as_process(), you should be able to reliably reproduce the bug (the test_slow_server_start) will fail after 300 seconds)16:25
smurrayJPEW: okay16:33
*** zyga__ <zyga__!> has quit IRC (Ping timeout: 265 seconds)16:36
*** ecdhe <ecdhe!> has quit IRC (Read error: Connection reset by peer)16:42
*** ecdhe <ecdhe!> has joined #yocto16:42
*** mckoan is now known as mckoan|away16:44
smurrayJPEW: I've put that on top on my plain poky setup and started a run to compare against last night's16:51
*** dev1990 <dev1990!> has joined #yocto16:54
*** camus1 <camus1!~Instantbi@> has joined #yocto16:55
*** camus <camus!~Instantbi@> has quit IRC (Read error: Connection reset by peer)16:56
*** camus1 is now known as camus16:56
rfs613noticed small typo in poky/meta/lib/oeqa/manual/toaster-managed-mode.json ... it needs s/PACKAGE_CLASES/PACKAGE_CLASSES/ ... should I report this somewhere?17:05
*** bps <bps!~bps@user/bps> has quit IRC (Ping timeout: 268 seconds)17:05
rburtonrfs613: you can send a patch to openembedded-core@lists.openembedded.org17:07
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has joined #yocto17:07
rburtonor file a bug in  the patch would be best :)17:07
rfs613rburton: patch sent... it's pretty trivial ;-)17:11
*** jmiehe <jmiehe!~Thunderbi@user/jmiehe> has quit IRC (Quit: jmiehe)17:13
rfs613I left off the 2nd hunk which added newline at end of file17:14
*** kpo <kpo!> has joined #yocto17:16
overrideWhen we define a custom IMAGE_FSTYPE class as a bbclass, so we need to add that class to some other variable too, or is jsut having that bblass enough?17:30
smurrayoverride: IMGCLASSES would be my guess, see meta/classes/image.bbclass17:35
smurrayoverride: though I'm willing to believe I'm wrong, there's also IMAGE_TYPES in image_types.bbclass, which might be more relevant if it's a new fstype17:36
overrideill set IMAGE_FSTYPE to thene class i just eclared and see what breaks17:38
smurrayoverride: I think you add your class's name to IMAGE_CLASSES so it gets pulled in, and your class adds its new type to IMAGE_TYPES17:39
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 240 seconds)17:43
*** camus <camus!~Instantbi@> has joined #yocto17:44
overridesmurray: where do i even name the custom image class? the image bbclass which came with my bsp, i dont see the type getting named anywhere17:46
smurrayoverride: I'd need some more context, I think.  Is the class adding a new output type like ext4 or the like?17:48
overridelets say you make a custon image class..17:49
*** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:44f2:149e:9572:50da> has joined #yocto17:49
smurrayoverride: they might just be inheriting in a recipe before setting IMAGE_FSTYPES, I'd probably grep through the BSP layer to see where it's being references17:50
overridebeen grepping, ill double check17:51
*** kanavin <kanavin!~Alexander@2a02:2454:2a0:cb00:eb83:2e01:3dda:5d46> has joined #yocto17:54
overridemaybe all bbclasses with a image_type_ prefixed to their name start getting picked up as possible IMAGE_FSTYPE ?17:54
*** mranostaj <mranostaj!~mranostaj@> has quit IRC (Remote host closed the connection)17:54
overridemaybe im just being horribly ineloquent as I try to explain this17:55
overridelets say I declare some image_type_smurray.bblcass, can I just go ahead and do something like IMAGE_FSTYPE = smurrayimg now?17:56
overridethats what my bsp is leading me to belive right now17:56
overrideor wait, maybe I do need a IMAGE_CLASSES_append before I can start using that image type17:58
*** mranostaj <mranostaj!~mranostaj@> has joined #yocto17:58
overrideok, think I got now, didnt see this when I first grepped t17:58
*** dmoseley <dmoseley!~dmoseley@> has quit IRC (Ping timeout: 255 seconds)18:02
smurrayoverride: cool18:06
*** florian <florian!> has joined #yocto18:06
overridesmurray: so the IMAGE_CLASSES_append bit makes sense18:07
overrideim just appening the new image class to it18:07
smurrayyes, that makes sense18:07
overridebut even now the name being given in IMAGE_FSTYPE has an img at its end.. i dint get where we are defining this name..18:08
overridethe image class is called img_type_tezi, i append img_type_tezi to IMAGE_CLASSES_append, but then in IMAGE_FSTYPE i see teziimg getting added18:09
overrideis that just like some yocto magic or what?18:09
overridesmurray: see what im trying to get at? ^18:12
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto18:12
smurrayoverride: I'd need to see the class, my guess is they're adding teziimg to IMAGE_TYPES in it18:12
smurrayoverride: that's what registers the type for use in IMAGE_FSTYPES, it's not based on the bbclass name18:14
overrideoh, let me double check.. maybe I wasnt differentiating between my IMAGE_FSTYPES and IMAGE_TYPE as i grepped for teziimg or something18:17
*** frieder <frieder!> has quit IRC (Remote host closed the connection)18:36
overridesmurray: I still dont get the teziimg bit..
overridenot seeing the IMAGE_TYPES or nothing18:45
*** Tokamak <Tokamak!~Tokamak@> has quit IRC (Ping timeout: 255 seconds)18:51
smurrayoverride: there might be some magic somewhere, the definition of IMAGE_CMD_teziimg and the other stuff there is about what I'd expect, but as you say there's no adding of teziimg to IMAGE_TYPES or CONVERSIONTYPES18:52
smurrayI'd also be willing to believe I'm missing something about image.bbclass ;)18:56
*** yates_home <yates_home!> has quit IRC (Remote host closed the connection)18:57
*** yates <yates!> has quit IRC (Remote host closed the connection)18:58
*** Tokamak <Tokamak!~Tokamak@> has joined #yocto19:00
overridesmurray: do u know why this class insny including the base image class or something?19:00
smurrayoverride: if it's providing a new type it wouldn't have to, just get added to IMAGE_CLASSES somewhere19:02
smurrayoverride: or in their image recipe, they inherit it manually19:02
overridesmurray: inheriting core-image would take care of it?19:15
overrideand how does it work again - in recipes you inherit and in classes you require?19:15
smurrayoverride: AIUI inheriting core-image (and this image) wouldn't drive pulling this image type class in unless it's in IMAGE_CLASSES19:16
*** dev1990 <dev1990!> has quit IRC (Quit: Konversation terminated!)19:17
smurrayoverride: inherit is specifically for classes, include/require are for pulling in another file19:17
whuang0389does anyone have experience configuring LLVM build for an aarch64?19:18
whuang0389i think im doing something wrong.. host-target triple comes up as x86_64-unknown-linux-gnu lol19:18
overridesmurray: whats AIUI again?19:19
whuang0389as i understand it19:19
smurrayoverride: as I understand it19:19
whuang0389only thing i know in my life right now is AIUI19:19
overridevery nice19:19
overrideIm also trying to work with on a hdmi dongle side project, something kinda like amaxzon firestick or something. Would anyone have any reccomendations at all for prototype boards?19:21
overridethe toradex im working with right now might be an overkill i feel19:21
overridewant some dev board with everything video over hdmi, 4k and all19:22
smurrayif it's for a product that you'd sell, SoC availability and cost would likely be the drivers.  A lot of such things use Allwinner and Amlogic SoCs, I think, but whether you can source them is a good question19:25
smurrayrockchip is the other vendor that comes to mind in that cheap set top box/stick space19:26
overridenice.. ill start looking into those19:27
smurrayif it's for a hobby project and form factor isn't an issue, then rpi4.  For an actual HDMI dongle product it'd likely be a non-starter since getting those chips is likely impossible for small players19:27
overridethe usecase would be for tvs in hotels rooms , so guest servies and all can use it. you can setup like a wakeup call or whatever off of it , switch to normal tv programming.19:29
smurraynote that your mileage may vary for the vendors I've mentioned, some of them don't have great upstream support for various things19:29
overrideI can prototype with rpi4, if i can switch to something else later which can fit in a hdmi dongle form factor only by writing a new machine config filr or soemthing19:30
smurraythe other possibility would be one of the i.MX8 variants, though I suspect they'd be pricier than the set top box oriented SoCs from the Chinese mfgers19:30
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has quit IRC (Quit: ZNC 1.8.2 -
overridesmurray: if i were to start out with an rpi4 would yocto make the swithc over to imx etc super swift?19:33
*** dtometzki <dtometzki!~dtometzki@fedora/dtometzki> has joined #yocto19:34
smurrayoverride: in theory, though there's usually at least some h/w specific tweaking required around things like packages for graphics, video decode, etc. that aren't necessarily all handled in BSP layers in a consistent way19:37
overrideI bet, just bringing over this toradex filesystem image class to my meta-layer is proving to be no walk in the park...19:38
smurrayfor the Automotive Grade Linux demo images we build for a bunch of platforms, the BSP specific tweaks tend to be around stuff like that19:38
smurraythe other area you'd maybe see differences would be h/w specific security features like secure boot, there's still a variety of different vendor things there you might need to account for19:40
overridewill start looking up all the vendors u mentioned19:42
overridelearning some solidworks too, so the form factor and all would be pretty involved19:43
overrideneed some vendor doing timy soms for hdmi dongles19:44
*** florian <florian!> has quit IRC (Ping timeout: 265 seconds)19:44
overridesmurray: on replacing that teziimg class with my own, im running into some virtual/dtb errors. whats a virtual/dtb to begin with?19:46
smurrayoverride: I've no idea, sorry19:47
*** zyga-mbp <zyga-mbp!> has quit IRC (Ping timeout: 252 seconds)19:48
overrideno worries, looking into it19:48
smurrayI know what the virtual/ mechanism is for, I didn't think upstream oe-core / poky used it for devicetrees19:50
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto19:53
*** kpo <kpo!> has quit IRC (Read error: Connection reset by peer)19:56
*** kpo <kpo!> has joined #yocto19:56
*** Ad0 <Ad0!~Ad0@> has quit IRC (Ping timeout: 252 seconds)20:06
*** Ad0 <Ad0!~Ad0@> has joined #yocto20:12
*** leon-anavi <leon-anavi!~Leon@> has quit IRC (Quit: Leaving)20:35
*** ant__ <ant__!> has joined #yocto20:40
*** florian <florian!> has joined #yocto21:08
*** xmn <xmn!> has quit IRC (Quit: ZZZzzz…)21:25
*** yannd <yannd!~yann@> has quit IRC (Remote host closed the connection)21:29
*** camus1 <camus1!~Instantbi@> has joined #yocto21:50
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 250 seconds)21:51
*** camus1 is now known as camus21:51
*** whuang0389 <whuang0389!~whuang038@2607:9880:2d78:22:44f2:149e:9572:50da> has quit IRC (Quit: Client closed)21:54
JaMazeddii: around?22:11
*** hpsy <hpsy!~hpsy@> has quit IRC (Quit: Leaving.)22:15
*** florian <florian!> has quit IRC (Ping timeout: 252 seconds)22:42
JaMazeddii: meta-virtualization/recipes-extended/uxen/ is now failing in dunfell, gatesgarth, hardknott, honister "bitbake world" builds and I'm pretty sure that it wasn't failing before (as I would notice in jenkins jobs), but the strange part is that it wasn't changed for long time (not uxen-guest-tools, quilt, module.bbclass) and definitely not in all 4 releases at the same22:46
JaMatime, any idea what might cause this sudden change?22:46
JaMastdout: Applying patch fix-Makefile-for-OE-kernel-build.patch22:46
JaMapatching file Makefile22:46
JaMaHunk #1 FAILED at 1 (different line endings).22:46
JaMaHunk #2 FAILED at 19 (different line endings).22:46
JaMa2 out of 2 hunks FAILED -- rejects in file Makefile22:46
JaMauxen-guest-tools/4.1.7-r0/uxen-vmsupport-linux-4.1.7/Makefile: makefile script, ASCII text, with CRLF line terminators22:46
*** zyga-mbp <zyga-mbp!~zyga@> has quit IRC (Ping timeout: 250 seconds)22:47
JaMait also doesn't use AUTOREV or something to silently start using different source now22:48
*** zyga-mbp <zyga-mbp!~zyga@> has joined #yocto22:50
smurrayJaMa: maybe something's gone off with sha384sum?  It's not tested in oe-core AFAICT, and I must admit I didn't think it was supported22:57
smurrayJaMa: that plus upstream changing the zip file in place might explain a failure?  I'm just spitballing, though22:58
*** jwillikers <jwillikers!~jwilliker@2604:2800:2:a403:fe91:ac3e:5153:1290> has joined #yocto22:58
smurrayJPEW: the oe-selftest run I started earlier with your change isn't done yet, but it's looking promising, none of those failures so far23:04
JPEWsmurray: excellent! Thanks!23:06
smurrayJPEW: I'll do another run overnight, perhaps racheting the -j option up a bit further, then tomorrow I can apply the PR server patches and try with those23:07
JPEWsmurray: I forgot to check the patches in master-next, but the fix should be pretty easy. You'll need to change how the server is started to use the new API like hashserver23:10
smurrayJPEW: yeah, I noticed that, should be straightforward enough23:10
*** amitk <amitk!~amit@> has quit IRC (Ping timeout: 258 seconds)23:18
*** camus1 <camus1!~Instantbi@> has joined #yocto23:19
*** xmn <xmn!> has joined #yocto23:20
*** camus <camus!~Instantbi@> has quit IRC (Ping timeout: 255 seconds)23:21
*** camus1 is now known as camus23:21
JaMasmurray: thanks, I didn't notice that this recipe is using sum384sum, but that would mean that sum384sum checking is completely broken (I don't expect anyone able to figure out sha384 collision to overlook accidentally changing line endings in files) :)23:22
smurrayJaMa: heh, yes, it'd indeed take more than one thing being broken23:26
*** ant__ <ant__!> has quit IRC (Ping timeout: 240 seconds)23:30
JaMaand sha384sum isn't completely broken as well:23:34
JaMaecho foo > downloads/uxen-vmsupport-linux-4.1.7.zip23:34
JaMaWARNING: uxen-guest-tools-4.1.7-r0 do_fetch: Checksum mismatch for local file /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip23:35
JaMaCleaning and trying again.23:35
JaMaWARNING: uxen-guest-tools-4.1.7-r0 do_fetch: Renaming /jenkins/mjansa/build/webos/dunfell/downloads/ to /jenkins/mjansa/build/webos/dunfell/downloads/uxen-vmsupport-linux-4.1.7.zip_bad-checksum_8effdabfe14416214a250f935505250bd991f106065d899db6e19bdc8bf648f3ac0f1923:35
*** sbach <sbach!~sbach@user/sbach> has joined #yocto23:37
smurrayJaMa: hrm, if it's working then the patch not applying is indeed quite strange23:37
JaMamy current theory is that it wasn't included in "bitbake world" for some strange reason, because now I'm looking at 2 days old "bitbake world" build for qemux86-64 and it's not shown there23:40
*** sbach <sbach!~sbach@user/sbach> has quit IRC (Remote host closed the connection)23:43
*** sbach <sbach!~sbach@user/sbach> has joined #yocto23:43
*** goliath <goliath!~goliath@user/goliath> has quit IRC (Quit: SIGSEGV)23:58

Generated by 2.17.2 by Marius Gedminas - find it at!