**** BEGIN LOGGING AT Tue May 04 02:59:57 2021 May 04 08:34:05 khem: looks good, thanks! May 04 09:40:15 good morning! Does anybody know the dtbo.img file format, which is used on android and flashed onto a separate partition? do you know how the bootloader selects which dtb to use when booting? May 04 11:06:04 my yocto device after getting booted it got pause on login terminal. how can i automatically boot inside os? i want to run a python script automatically after device gets power on via usb May 04 11:06:38 @aalu: use systemd for that? May 04 11:08:42 or sysv init script May 04 11:09:32 the login is only for console access, but the login screen is a init script that is started at one point in time, you just need to write another one. May 04 11:09:56 for sysv, it's in /etc/init.d/ directory on the target and I think you should use udpate-rc.d to "schedule" it in the init May 04 11:10:22 for systemd, it's in /etc/systemd/system IIRC (or user subdir) May 04 11:10:39 INITSCRIPT_NAME and all for sysv init scripts May 04 11:11:23 SYSTEMD_PACKAGES and SYSTEMD_SERVICE for systemd init scripts (and probably other variables too) May 04 11:13:13 oh wow. thanks i am trying this May 04 11:14:33 update-rc.d and systemd bbclass will help you, there's also some documentation available May 04 11:14:38 docs.yoctoproject.org May 04 11:30:15 i guess i have to see about both of it. i have just read them on linux subreddits ;-; May 04 11:30:22 i am using my vendor building scripts to build images. main con is the image is too old like i am using sumo of yocto. and i am not able to update even pip ;-; it took me 15 days to learn to build image with my added packages. thinking to use toaster recently learnt about it. my device uname -a is Linux phyboard-segin-imx6ul-2 4.14.93-bsp-yocto-i.mx6ul-pd19.1.0 #1 SMP Wed Feb 10 01:11:08 UTC 2021 armv7l GNU/Linux May 04 11:30:22 so by using toaster just adding packages and images. will i able to build image with new yocto? i have 50gb already used does it will help me in new compile? it's is very tiring and a bit learning curve in these tasks. May 04 13:11:06 paulbarker: Are there still patches pending in the prserver queue? I have 3 of the last 4 in the queue and all seems ok so far... May 04 13:11:10 all: Hi, I am trying to build e-sdk for core-image-minimal, gatesgarth branch, but fail with this error: path mismatch [1 link]: ino 21393138 db May 04 13:11:19 all: does anyone of you know how to fix this? May 04 13:12:43 phatina: is there something else in the pseudo log with the actual path of the file with the mismatch? May 04 13:15:07 RP: path mismatch [1 link]: ino 21393138 db '/home/phatina/Work/yocto-build/tmp/work/skyboard_evb-poky-linux-gnueabi/core-image-minimal/2.0-r0/sdk-ext/image/opt/product-name/3.2+snapshot/layers/poky/bitbake/lib/bb/__pycache__/tinfoil.cpython-38.pyc' req '/home/phatina/Work/yocto-build/tmp/work/skyboard_evb-poky-linux-gnueabi/core-image-minimal/1.0-r0/sdk-ext/image/opt/product-name/3.2+snapshot/cache/hashserv.db-wal'. May 04 13:16:00 RP: tbh, I have no clue what database it's talking about May 04 13:19:28 phatina: are you up to date on the gatesgarth branch? May 04 13:20:06 phatina: its the pseudo database, that error helps a lot. Question is now what the fix is. Is this a build from scratch? May 04 13:20:08 hello guys ! does anybody know how to inform u-boot to use the dtb file generated by the deice-tree recipe as its own dtb ? May 04 13:21:09 phatina: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=63831568bdf49d21edcc158c157ac086e25e9168 looks related to that but wouldn't cover the hashserv wal file May 04 13:22:17 phatina: you could try applying that, cleaning core-image-minimal and rebuilding it May 04 13:30:16 RP: is meta-gplv2 included in some autobuilder jobs? (is there some reason why elfutils patch isn't included in master-next yet?) May 04 13:34:07 thekappe: I'd make the device-tree part of U-Boot source code in U-Boot recipe or add it to the U-Boot source code with an SRC_URI in the U-Boot recipe May 04 13:34:51 JaMa: it is, I was surprised you saw the failure as the autobuilder did not May 04 13:35:14 JaMa: the patch isn't in master-next as the autobuilder didn't see the failure and non of the layer maintainers have noticed May 04 13:35:23 thekappe: IIRC, the dtb in U-Boot is part of the binary, so it needs to be packed into the binary one way or the other May 04 13:35:34 * RP is not a maintainer of the layer, I just keep fixing it :( May 04 13:36:11 RP: that's strange, will retest with gcc-11.1.0 as I did that patch with gcc-11.0.1 from master-next, but I doubt that it will change this May 04 13:36:27 RP: maybe the autobuilder doesn't set P_V_elfutils? May 04 13:36:39 JaMa: https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/3381 May 04 13:37:34 JaMa: perhaps elfutils isn't needed by core-image-minimal core-image-full-cmdline ? May 04 13:38:25 Running task 3951 of 4076 (/home/pokybuild/yocto-worker/non-gpl3/build/meta/recipes-devtools/elfutils/elfutils_0.183.bb:do_install) May 04 13:38:54 PREFERRED_VERSION_elfutils = "0.148" May 04 13:39:04 ^ is what I was using to reproduce this May 04 13:40:17 JaMa: I'd guess the image doesn't pull in any of the gplv3/lgplv3 pieces of it then May 04 13:42:44 Saur: rburton: ^^ May 04 13:43:20 * RP thinks we should drop that layer from testing along with mingw May 04 13:44:17 no objection from me May 04 13:46:26 zeddii: you broke yocto-check-layer: https://autobuilder.yoctoproject.org/typhoon/#/builders/121/builds/38/steps/23/logs/stdio ;-) May 04 13:46:37 (for meta-virt) May 04 13:47:01 Saur: rburton: elfutils from meta-gplv2 still broken with gcc-11.1.0: http://errors.yoctoproject.org/Errors/Build/121780/, please review and merge the patch from th ML May 04 13:48:07 RP: thanks, will give it a shot May 04 13:53:18 RP: hahah! I'm not in the mode of running it often. I'll have a look. May 04 13:54:28 RP: is that the right link ? It has: INFO: meta-virtualization ... PASS May 04 13:54:39 but I'm doing a local run now, that'll give me what I need. May 04 13:54:53 zeddii: search the output for ERROR: May 04 13:55:21 zeddii: to save your some pain, its because a directory with a conf file was added and the autodetection is now getting confused, raspberrypi related May 04 13:55:46 ahah. crap. those aren't my changes. I'll need to get Christopher to look at those. May 04 13:56:02 but I'll see if I can sort it out until I raise him. May 04 13:56:03 zeddii: we could turn off autodetection on the tests I guess but we need to do something May 04 13:57:24 yah. I see it now. poking at it more. May 04 13:59:32 Hello all, I have installed Yocto inside WSL2 environment, all projects build but when I want to run a devshell the terminal doesn't drop my inside the right folder and put me inside the $HOME dir. All environment var seems set correctly. Any idea ? May 04 14:00:21 qschulz, thanks " May 04 14:00:32 going through it May 04 14:01:51 RP: an empty conf/layer.conf makes the test pass. I'd rather just do that than any type of test inhibit. We didn't need the layer.conf before (in that dynamic layer), so we shouldn't need it now, and adding the placeholder file with a comment indicating it is a placeholder is the easiest thing to do. May 04 14:02:14 I was thinking about adding some device-tree:do_deploy dependency May 04 14:03:18 zeddii: fair enough, thanks! May 04 14:03:35 zeddii: I do wonder if we could fix the test logic somehow May 04 14:04:21 I'll look at that as well, but will push the fix in the meantime. May 04 14:04:46 thekappe: what are you trying to achieve exactly with having another recipe for the device-tree? May 04 14:05:01 oh May 04 14:05:04 nothing May 04 14:05:13 I'm a bit confused May 04 14:05:29 the device-tree recipe generates the dts and build the actual dtb May 04 14:05:48 I want to instruct u-boot to use the same dts and/or dtb May 04 14:06:07 thekappe: there are plenty of device trees already in U-Boot, and they are compiled during U-Boot compilation May 04 14:06:17 I've noticed May 04 14:06:25 so it's why I'm confused May 04 14:06:43 thekappe: you have to explicit what your confusion is :) May 04 14:06:47 also because in some sort of way it seems to use the correct one generated by the dtv May 04 14:07:13 basically I don't need any of the dts files available in u-boot srcs May 04 14:07:25 (or at least I think so) May 04 14:07:39 just FYI, DeviceTree is a standard. The Device Trees used by the kernel and U-Boot (or other SW using DeviceTrees) do not have to be (and often aren't) compatible/identical May 04 14:08:03 ok May 04 14:08:15 I'm using a zynqmp May 04 14:08:47 which has some dt tweaks to reflect the different configuration of the custom board May 04 14:08:59 in particular I have a fixed link on an ethernet node May 04 14:09:19 no mdio no phy May 04 14:09:41 thekappe: just ad dyour dts in your U-Boot sources, modify slightly the Makefile which is building the dts in U-Boot and there you go May 04 14:10:00 and select the device tree to use maybe in the menuconfig don't remember exactly how it's picked May 04 14:10:08 point is that the dts is autogenerated May 04 14:10:30 thekappe: based on what and when? May 04 14:10:36 from a file "binary" file parsed by the device-tree recipe itself May 04 14:11:51 basically the dt recipe takes a .hdf file and extract "two" dts file May 04 14:12:13 one representing the SoC activated/enabled processor nodes May 04 14:12:27 and the other one representing the nodes enablend in FPGA May 04 14:12:53 the two dts are put toghether and with some magic a final system.dts is gnerated and compiled May 04 14:14:22 So I thought it would be nice to use that dts because it brings the current Processor/FPGA nodes configurations May 04 14:15:03 btw, I don't know how, right now, but it seems the the u-boot recipe (flavoured) is already doing it May 04 14:22:18 hah. I spoke to soon, the placeholder isn't enough for that layer. May 04 14:34:58 thekappe: i'd figure out where you could patch things up in U-Boot or add your hdf file May 04 14:35:53 thekappe: otherwise, yeah, depending on do_deploy might be an option, since it's not really best practice to use the SYSROOT for things that aren't really supposed to be in any filesystem, but that would be another option May 04 14:35:57 yes, I agree May 04 14:55:09 RP: Digging a bit more, after I created the empty layer.conf, the compatibility of course runs more layer checks on it, and it fails. So the question is .. should dynamic layers have full/proper layer.conf files ? If so, I'll fill it out. If not, then I'll have to see if we can make that check know it is a dynamic layer. May 04 15:07:53 does pypi.bbclass work at all on offline mode and with download caches? May 04 15:09:11 or maybe I can't read error logs and can't spot the missing runtime dependency which it tries to fetch in offline mode and fails.. May 04 15:09:59 zeddii: that is the question I didn't dig into, I don't know offhand May 04 15:10:50 I'm leaning towards, yes. Since once that layer as a conf file, or any type, it is now behaving more as a layer than just as a dynically added set of BBFILES for bb and bbappends. May 04 15:11:01 s/or any/of any/ May 04 15:24:57 RP: have you seen GLIBC_2.33-only symbol failures? They did some weird thing with stat() there, which I am looking into (ncurses built against glibc 2.33 cannot be relocated onto older glibc). May 04 15:25:16 "/bin/bash: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/build-st-24308/tmp/work/x86_64-linux/gnupg-native/2.3.1-r0/recipe-sysroot-native/usr/lib/libtinfo.so.5)" is the AB fail. May 04 15:25:41 kanavin: have you upgraded uninative to a version which has glibc 2.33 in it? If not, that would likely be the cause May 04 15:26:27 zeddii: perhaps the error should become a note that it was ignoring that directory? May 04 15:27:07 RP: I did rebase onto it http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates&ofs=50 but there might be a cache contamination issue then? May 04 15:28:13 kanavin: that should be ok :/ May 04 15:28:33 kanavin: I just realised that is an AB failure and we do have a uninative with 2.33 in it May 04 15:28:59 kanavin: the other option is that something didn't correctly add uninative into the system for that binary/lib May 04 15:29:08 RP: wait a second... May 04 15:29:23 kanavin: we have seen an occasional error like that with libtinfo but didn't get to the bottom of it May 04 15:30:30 RP: all such failures happen in specific oe-selftests than run gnupg https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/2090/steps/14/logs/stdio May 04 15:30:40 (there's a version update in there) May 04 15:31:36 is uninative used in that context? May 04 15:34:37 I guess I should look more carefully at gnupg-native builds before and after the version update May 04 15:43:39  I have installed Yocto inside WSL2 environment, all projects build but when I want to run a devshell the terminal doesn't drop my inside the right folder and put me inside the $HOME dir. All environment var seems set correctly. Any idea ? May 04 15:44:27 kanavin: I doubt the version upgrade is at fault. More likely it is some case where the binary/libs are built on some worker and then reused on another with differing libc version May 04 15:44:44 kanavin: it looks a bit like something escapes our uninative intercept somehow May 04 15:44:49 RP: I thought so as well, quite probably it's one of the new fedoras May 04 15:44:55 kanavin: right May 04 15:50:27 PR: you were right, now eSDK builds - thank you for the patch ; May 04 15:50:38 RP: ^^ sorry May 04 15:51:53 phatina: we should perhaps mention that to Anuj for gatesgarth May 04 16:01:05 YP Monthly Technical Call starting now: https://www.yoctoproject.org/public-virtual-meetings/ May 04 16:27:46 RP: yes, will do May 04 16:51:18 zeddii: are you going to look at a tweak to yocto-check-layer? May 04 16:52:53 yah. that was my next thing to poke at. given that I'd need a full layer.conf for that dynamic layer to pass otherwise. May 04 16:56:02 zeddii: thanks, just checking you weren't looking at me :) May 04 16:58:30 i am using toaster to build imaage.i added project and added everytinh i like to add even buidling python 3 is taking more than 15 mins! it is still in Build queued using 9th gen i5 but it is taking too much time. help! how can i build via commandline that i have made project in toaster May 04 16:59:20 cpu is not using 100% and only python is at queue and nothing nothing else May 04 17:07:53 RP: I found it May 04 17:08:39 RP, JPEW I'm afraid we may have to revert http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=a0ce9a8bbc5e88ebe965344f01057615aa55fdbc May 04 17:09:00 as LD_LIBRARY_PATH set this way leaks into host executables, such as bash: May 04 17:09:18 (which are not uninative-enabled) May 04 17:09:20 akanavin@ubuntu1804-ty-3:/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/build-st-24341/tmp/work/x86_64-linux/gnupg-native/2.3.1-r0/recipe-sysroot-native$ LD_LIBRARY_PATH=./usr/lib /bin/bash May 04 17:09:49 bin/bash: ./usr/lib/libtinfo.so.5: no version information available (required by /bin/bash) May 04 17:09:56 bin/bash: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./usr/lib/libtinfo.so.5) May 04 17:19:09 dwagenk: I didn't thank you for yesterday's patch May 04 17:53:08 kanavin: well spotted, that won't work from that perspective. What breaks if we revert? May 04 17:54:51 RP: running a build now with it https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2110 May 04 17:55:25 could presumably use wrappers that set it? probably a bit heavy handed, though :) May 04 17:55:26 * kergoth yawns May 04 17:57:32 kergoth: a wrapper around python might work well May 04 17:57:52 kanavin: cool, will be interesting to see what happens May 04 17:58:17 RP: I have a colossal patchset coming May 04 17:58:25 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates May 04 17:59:19 kanavin: do I dare look? :) May 04 17:59:42 it spills over to second page, over 50 commits :) May 04 17:59:55 kanavin: remember our lists have a 100 patch limit :) May 04 18:03:23 RP: I was wondering why last AUH email set didn't seem complete May 04 18:14:06 kanavin: Hmm, I don't recall exactly why I did that May 04 18:14:40 Oh, right, Python ctypes doesn't work without it May 04 18:15:53 I think reverting that will break diffoscope May 04 18:17:40 is here a good place to ask about meta-rust, or is there somewhere specific those folks hang out? i'm trying to build websocat, which has "panic = 'abort'" in its release profile, and when i try and build it with bitbake, i get "error: the crate `panic_abort` does not have the panic strategy `abort`" May 04 18:17:56 if i patch out the "panic = 'abort'" from Cargo.toml it seems to build just fine though May 04 18:18:08 jordemort: You might as vmeson ? May 04 18:18:12 *ask vmeson May 04 18:18:14 JPEW, I guess we'll come up with a more targeted fix then for just that May 04 18:19:05 kanavin: It's really python3-ctype that doesn't work; I'm not sure how you're going to make the work May 04 18:19:44 kanavin: I guess you could expect users to patch ever single -native recipe that uses python3-ctype? Seems annoying May 04 18:23:04 Sorry, I don't quite follow from your example whats wrong May 04 18:28:41 Ah, OK. I get it now.... ya I think we need a wrapper around -native python3 to set the LD_LIBRARY_PATH May 04 18:30:29 Although, that wouldn't solve the problem if python itself invokes bash because it would pass along the environment including LD_LIBRARY_PATH May 04 18:49:06 JPEW, let's first see what breaks and how May 04 18:52:45 kanavin: Like I said, it's diffoscope, so you probably won't notice unless there are non-reproducible packages May 04 18:53:53 JPEW, if it passes, I can re-run the repro test and artificially insert some May 04 18:54:05 kanavin: Sounds good May 04 20:16:36 JPEW, there were failing packages, and diffoscope did not fail May 04 20:16:43 https://autobuilder.yoctoproject.org/typhoon/#/builders/115/builds/231/steps/12/logs/stdio May 04 20:16:50 https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210504-q60we4nk/packages/diff-html/ May 04 20:17:32 although... it did fail here https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/232/steps/13/logs/stdio May 04 20:18:05 kanavin: Ya, that is the error IIRC May 04 20:18:48 I'm pretty sure it's using ctype.util.find_library to try an find libarchive, which fails May 04 20:18:52 then we probably just add LD_LIBRARY_PATH wrapping to diffoscope recipe? May 04 20:19:07 similar things are already done to many native tools May 04 20:19:41 probably May 04 22:08:11 I'm stupid.. how do I add a recipe to my workspace, something that already exists? May 04 22:08:29 anytime I run a devtool command, I just get back "No recipe named '...' in your workspace, but nothing tells me HOW to add it?! May 04 22:10:14 it's _modify_.. ugh May 04 22:13:32 RP: send you a potential patch for the yocto-check-layer issue. I really didn't know what I was doing, so I sent it just to you for now. May 04 22:22:36 Hello all! I deleted my build dir `/home/manuel/bora-proj/build/tmp/deploy/images/raspberrypi4-64/` and would like to recreate it. `bitbake my-image-name` doesn't. What do I need to do? May 04 22:28:08 zeddii: hmm. I'll need to look at the code :) May 04 22:29:46 zeddii: I was wondering about simply changing the logger.error for NO_LAYER_CONF to a logger.info May 04 22:30:40 zeddii: with a message like "%s: No conf/layer.conf present so ignoring layer" May 04 22:30:54 ignoring potential layer May 04 22:39:41 zeddii: its really a question of whether the tool should "scan" dynamic layers or not May 04 22:46:44 manuel1985: Something like `bitbake -C image my-image-name` May 04 22:46:58 Not sure the exact task you want to force to re-run for an image May 04 22:49:22 JPEW: I did `bitbake -c do_clean my-image && bitbake my-image` and it failed b/c it couldn't find the kernel sources in `build/tmp/deploy/images/raspberrypi4-64/` which I found weird. I had to delete build/tmp to make it work. May 04 23:00:35 manuel1985: Ya, that was going to be my next suggestion. It should have gone quickly b/c of sstate May 04 23:56:27 Is this indicative of a bug in the current (Hardknott) eudev_3.2.10.bb recipe? -> https://gist.github.com/chuckwolber/2255b1171a618aaca965da54ebb28985 May 04 23:57:18 If I understand this correctly, I would think pkg_postinst_eudev-hwdb() should be changd to pkg_postinst_ontarget() May 04 23:59:05 Whoops, I meant pkg_postinst_ontarget_${PN}() **** ENDING LOGGING AT Wed May 05 02:59:56 2021