**** BEGIN LOGGING AT Mon Oct 07 02:59:57 2019 Oct 07 06:44:41 good morning Oct 07 06:46:31 good morning to all Oct 07 07:48:03 New news from stackoverflow: Rauc and Yocto on Jetson Nano Oct 07 09:30:00 Hello, I am trying to bundle the dtb with the kernel image and I am using the KERNEL_DEVICETREE_BUNDLE flag, however the image is being put in the deploy directory with 0 bytes. Does anyone know what might be causing this? Oct 07 09:32:13 gsalazar: the image, or the link to it? Oct 07 09:32:29 LetoThe2nd: the actual image Oct 07 09:32:51 actually, this only happens for the initramfs image Oct 07 09:33:05 for the image without the initramfs bundled it works Oct 07 09:33:07 initramfs, i'm out. Oct 07 09:34:33 LetoThe2nd: It doesn't seem to be related to the initramfs itself, but the flow that is being used for the generation with initramfs on the kernel-devicetree.bbclass Oct 07 09:37:04 gsalazar: i don't doubt that, but i don't have experience concerning initramfs. thats all. Oct 07 09:37:30 LetoThe2nd: thanks anyways! Oct 07 12:15:15 is it possible to have sourceless recipes? I have some init scripts, which may vary by machine type, that don't really have a home right now. Oct 07 12:21:40 fullstop: sure! I have the same for my startup scripts, it just has some init scripts and a do_install() function to put them in the correct location / run update-rc.d Oct 07 12:22:04 iceaway: awesome, thanks. I wasn't sure if SRCREV was required or not. Oct 07 12:22:11 I'll just try it and see what happens. Oct 07 12:22:29 fullstop: where do you have the init scripts? You can locate them inside the recipre tree Oct 07 12:22:39 right, that's where I want to put them. Oct 07 12:22:43 My scripts are in a ${PN} subdir of the recipe, and I list the files in SRC_URI. Oct 07 12:23:14 fullstop: see here https://github.com/koansoftware/meta-training/tree/master/recipes-example/example Oct 07 12:24:50 awesome, thanks marco Oct 07 12:27:10 Hello, I try to use bitbake on a schroot. Everything seam fine but when I launch bitbake it quit without any message. Oct 07 12:27:32 Someone already try that? Oct 07 12:28:37 Zadbar: any particular reason for not using docker? its usually the tool of choice these days. Oct 07 12:29:59 I'm not very familliar with docker and I need to run on debian jessie to match the production environnement Oct 07 12:31:46 Zadbar: It's quite nice to use docker. I did a small write-up of how I use it which could probably get you started: http://blog.unixshell.se/2018/03/simplify-your-yocto-builds-using-docker/ Oct 07 12:34:31 erbo: nice Oct 07 12:35:06 it's quite like I did during my Yocto workshop: https://koansoftware.com/workshop-yocto-project-at-linuxlab-2018/ Oct 07 12:35:15 It's also easy to add another -v /hostpath/to/sstate-cache:/path/in/docker/sstate-cache to mount in sstate-cache Oct 07 12:35:45 erbo: the best trick is "User id mismatch" ;-) Oct 07 12:37:01 yep, love that feature of the CROPS images. Make it so much easier to integrate into various CI-systems etc where you don't have control over which user it runs as. Oct 07 12:38:41 Is it possible to fetch with a ssh key during the build? Oct 07 12:39:06 with docker Oct 07 12:41:41 Zadbar: I guess you have to add the populating of the ssh keys to the custom Dockerfile, but otherwise I don't see any issues with that Oct 07 12:42:17 Okay. Thank you. I will take a look. Oct 07 12:43:00 Zadbar: This might also be a way: https://github.com/crops/poky-container/issues/29 Oct 07 12:44:03 Probably easier and doesn't require any changes to the docker image Oct 07 12:44:15 Is there a reason why I can't use ${PN} in ${SDKPATH}? Oct 07 12:51:06 hello folks Oct 07 12:51:20 I've moved my poky checkout + my build directory to somewhere else Oct 07 12:51:44 I removed build/tmp and now rerun, mostly reusing the sstate-cache from build/../sstate-cache Oct 07 12:52:26 however when I try to regenerate my image, I get this error: "ERROR: Failed to spawn fakeroot worker to run /path/to/image.bb:do_rootfs: [Errno 32] Broken pipe" Oct 07 12:52:42 I'm assuming that I should have removed something else, but I'm unsure as to what Oct 07 13:25:18 litb: probably one of the caches, or your local.conf still refers to the old build dir Oct 07 13:26:16 rburton, do I have to remove tmp-glibc aswell? Oct 07 13:26:24 yes Oct 07 13:26:31 ahh that's it maybe Oct 07 13:26:40 well you use either tmp or tmp-glibc Oct 07 13:26:50 the former is typically poky or similar, the latter is nodistro or similar Oct 07 13:27:02 both a reasonable names for the tmp directory Oct 07 13:29:13 rburton, weird that there's no log.do_rootfs . it appears that maybe libpseudo LD_PRELOAD is missing or something like that. so it thinks that it doesn't need to rebuild pseudo, even though i removed the complete tmp/ Oct 07 13:29:36 well maybe you deleted the tmp that its not using Oct 07 13:29:54 if you have two, then you switched configuration at some point to a different setup that uses a different name for TMPDIR Oct 07 13:31:26 rburton, TMPDIR is still the default Oct 07 13:31:36 i.e '#TMPDIR = "${TOPDIR}/tmp"' Oct 07 13:32:01 but ah, I suspect my experiments with toaster may have done that. though I subsequently removed those files from local.conf that were added by toaster Oct 07 13:32:45 meta/conf/distro/defaultsetup.conf:TMPDIR .= "${TCLIBCAPPEND}" Oct 07 13:32:59 different distros set TCLIBCAPPEND differently Oct 07 13:33:12 as i said, poky uses tmp and oe-core nodistro uses eg tmp-glibc Oct 07 13:33:20 for historical reasons, presumably Oct 07 13:35:51 rburton, hm, my distro inherits from poky Oct 07 13:36:02 so it should use tmp Oct 07 13:36:34 typicall if you want to move a build directory just create a new one, copy the local.conf and ensure the DL_DIR SSTATE_DIR are set correctly Oct 07 13:36:44 oh and bblayers.conf Oct 07 13:36:47 nothing else is relevant Oct 07 13:37:11 ah thanks, I didn't investigate this. I'll move DL_DIR aswell, this time to build/.. aswell Oct 07 13:42:30 maybe after all it's a debian10 issue, because yocto doesn't officially support debian10 in warrior apparently Oct 07 13:43:59 officially, but works Oct 07 13:44:54 i expect the build tree still has bits in. don't copy and fixup, make a new one and copy in the local.conf bblayers.conf Oct 07 14:05:25 Someone has idea why if I put ${PN} in the ${SDKPATH} the SDK fails to build? Oct 07 14:10:27 alessioigor: where, how? Oct 07 14:11:59 mckoan: SDKPATH = "/opt/${IMAGE_BASENAME}/${SDK_VERSION}" makes SDK fails with: configure: error: C preprocessor "x86_64-pokysdk-linux-gcc -E --sysroot=/home/alessio/Sources/git-trees/poky-master/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-libgcc-initial/9.2.0-r0/recipe-sysroot " fails sanity check Oct 07 14:12:31 Default value is SDKPATH = "/opt/${DISTRO}/${SDK_VERSION}" Oct 07 14:14:41 On Warrior works. Oct 07 14:34:16 rburton, same error happens with fresh build directory and copied local.conf + bblayers.conf Oct 07 14:34:23 appears it's maybe the sstate cache :/ Oct 07 14:34:42 or actually that i'm logged in as a remote-user using winbind/samba/kerberos Oct 07 14:34:50 perhaps that confuses pseudo? Oct 07 14:52:48 shouldn't do. easy to verify that its not the sstate though ,just build an initramfs image Oct 07 15:02:14 rburton, i tried to execute the bitbake-worker manually to maybe attach strace to it. however it complains that it should not be run manually and exits right away Oct 07 15:02:21 any idea how I can debug it? Oct 07 15:11:25 rburton, also I changed my host distribution from 32bit to 64bit userland. maybe that's the problem? Oct 07 15:11:34 maaaybe Oct 07 15:11:42 pseudo might not have noticed? Oct 07 15:11:48 its *very* tied to the host Oct 07 15:11:52 force a rebuild of that? Oct 07 15:12:36 BUILD_ARCH is still at i686, but my host changed from debian9 i686 userland to debian10 x86_64 userland Oct 07 15:13:17 rburton, yeah. ah, i see, it will take pseudo from the sstate cache, so I need to purge it from there. I'll try Oct 07 15:13:45 bitbake pseudo-native -C unpack will rebuild it Oct 07 15:14:56 I guess i should remove the complete sstate cache for -native packages. the toolchain is unable to rebuild pseudo-native, it seems Oct 07 15:15:24 easiest test: do a minimal image build without the sstate, as i said above Oct 07 15:15:28 the initramfs images are tiny Oct 07 15:18:51 rburton, i tried bitbake --no-setscene core-image-minimal-initramfs and it failed for m4-native Oct 07 15:19:03 why would you do --no-setcene? Oct 07 15:19:05 "configure: error: cannot run C compiled programs." Oct 07 15:19:12 rburton, i wanted to ignore the sstate-cache Oct 07 15:19:21 impressive breakage, what does the log say Oct 07 15:19:25 the actual config.log Oct 07 15:20:29 rburton, the erroring line apparently is "../m4-1.4.18/configure: line 4896: ./conftest: Accessing a corrupted shared library " Oct 07 15:21:14 new build directory, just set DL_DIR to an existing one for speed, and build m4-native Oct 07 15:21:35 so you're literally doing a pristine qemux86 poky build Oct 07 15:21:51 without sstate-cache, I take it? Oct 07 15:22:17 i.e not reusing my current Oct 07 15:22:32 right Oct 07 15:28:32 rburton, ah, doing "do_devshell" for m4-native, i see that "gcc" is resolved to /mnt/sdc1/git/poky/build-lmg6xx/tmp/hosttools/gcc Oct 07 15:28:54 so it points to a compiler that targets x86_64 by default. while my buildhost is i686 (32bit) Oct 07 15:29:08 you just said you've moved to 64-bit Oct 07 15:29:23 (not sure i want to know why your host is 32-bit) Oct 07 15:29:24 rburton, yeah, but I build the sstate cache and everything else before on 32bit debian9 Oct 07 15:29:57 anyway if you want to use a native compiler that isn't 'gcc' then you need to tell bitbake Oct 07 15:30:02 the sstate-cache still has the objects built on the 32bit host Oct 07 15:30:51 rburton, hmm, I though I need to tell it the build architecture using BUILD_ARCH. I set i686 there Oct 07 15:30:56 nooope Oct 07 15:31:18 and the build architecture is equal to the -native one, I suspect Oct 07 15:32:14 well you can set that if you really want but you'll need to tell it a lot more if you're asking it to do a 32-bit build on a 64-bit system Oct 07 15:32:18 like BUILD_CC etc Oct 07 15:32:26 easy fix: just do a clean build Oct 07 15:35:31 I would have thought that yocto's native.bbclass would set BUILD_CC to include "-m32" for example, when the host-bitness disagrees with BUILD_ARCH Oct 07 15:35:49 gcc-multilib is a requirement already of yocto, so the host compiler would need to support that flag Oct 07 15:36:19 gcc-multilib isn't a requirement Oct 07 15:36:52 BUILD_ARCH is usually set by bitbake.conf its not usual to set it yoursef Oct 07 15:39:31 rburton, hm, i see. Oct 07 15:40:13 rburton, in the 32bit userland I needed to set BUILD_ARCH, because i was running a 64bit kernel there, and yocto uses uname which returned x86_64 there, despite a 32bit userland Oct 07 15:40:23 so I did override it and everything worked magically Oct 07 15:40:44 still determined to not know why anyone would run a 32-bit userland on purpose :) Oct 07 15:41:00 overriding it worked then becayse you had a whole 32-bit userspace Oct 07 15:41:08 hmm, i see Oct 07 15:41:30 now you've a compiler and userland that wants to build 64-bit code but you're trying to convince it otherwise Oct 07 15:42:41 rburton, i see, this makes sense. Oct 07 15:43:01 rburton, perhaps I could remove all files that match pattern sstate:*-native:i686-linux:* below sstate-cache directory Oct 07 15:44:35 the build-arch should be tainting the sstate already. Oct 07 15:44:44 have you verified that a stock build works fine? Oct 07 15:47:47 rburton, hm, I thought it's not worth it if we tracked down the problem anyway. should I still try? Oct 07 15:57:06 rburton, this seems to have worked, thanks! Oct 07 21:02:59 Where should the u-boot.img live? I'm getting the error: spl: error reading image u-boot.img, err - -1 booting from and SD card with four partitions, the first contains imx6q-hummingboard2.dtb uEnv.txt zImage Oct 07 21:24:01 HI newbie question, I need to disable the journaling for ext4. Any idea how I can do that in Yocto??? Oct 07 23:05:10 hmm interesting... the poky libtool is actually patched to ignore the link_all_deplibs settings and always link them Oct 07 23:05:53 diff between normal libtool and the poky one: https://paste.ubuntu.com/p/SJDpPBS5rd/ Oct 07 23:05:59 i wonder where that comes from? Oct 07 23:15:08 its a debian patch :( Oct 08 00:45:54 is python3-grpcio-native broken for anyone else in warrior? Oct 08 01:08:50 hm, i think it's just broken with ccache. :-( Oct 08 01:20:50 New news from stackoverflow: How to add X11 desktop environment in yocto configuration? **** ENDING LOGGING AT Tue Oct 08 02:59:57 2019