**** BEGIN LOGGING AT Sun Jan 13 02:59:57 2019 Jan 13 03:30:32 Hi, I am considering including ${DATETIME} in my DISTRO_VERSION in order for each of my builds to automatically have a unique version, which matches between what's displayed in the distro's user interface (via /etc/os-release) and the generated filename of the images. Jan 13 03:30:41 Is this a good idea or is there something else I should consider? Jan 13 15:08:36 when I ran bitbake to build an image for the raspberry pi - bitbake core-image-base, it has ended up building an image for qemu instead ... I was expecting something in ls rpi-build/tmp/deploy/images/raspberrypi/*sdimg, however I have only a folder named poky/rpi-build/tmp/deploy/images/qemux86 Jan 13 15:09:23 is this workflow correct? check out sumo branch in poky directory. check out the sumo branch in the meta-raspberrypi folder. run - source oe-init-build-env rpi-build. edit the bblayers.conf inside the conf in the rpi-build folder - append the path of the meta-raspberrypi folder to it. from inside the rpi-build folder run: bitbake core-image-base Jan 13 15:11:47 saraf__, you probably want to set MACHINE Jan 13 15:12:15 default is qemux86 Jan 13 15:13:43 is that an environment variable to set before running bitbake? Jan 13 15:13:49 you want to set machine to one of the names in meta-raspberrypi/conf/machine/* Jan 13 15:13:59 yes Jan 13 15:14:00 saraf__, usually it is set in local.conf Jan 13 15:14:17 need to source the oe-init-.... from oe-core Jan 13 15:14:57 aah I see. Okay - I had done source oe-init-build-env rpi-build-dir Jan 13 15:20:33 aah ... okay - local.conf the default machine is set to be qemux86 ... Jan 13 15:20:49 I see a raspberrypi2.conf in meta-raspberrypi/conf/machine Jan 13 15:21:09 so MACHINE=raspberrypi2 in local.conf should do it Jan 13 15:21:14 am I correct? Jan 13 15:21:23 yes Jan 13 15:21:41 okay ... cool :) thanks Jan 13 15:28:45 what is the difference between MZ Jan 13 15:28:57 oops MACHINE ?= and MACHINE ??= Jan 13 15:29:39 in local.conf Jan 13 15:34:05 https://unix.stackexchange.com/questions/215044/meaning-of-and-in-bitbake-yocto Jan 13 15:51:09 Crofton: I see ... thanks. Jan 13 15:55:35 Is it necessary to delete the Downloads directory in the build folder before running bitbak core-image-base, after setting MACHINE in local.conf? Jan 13 15:56:49 I do not have enough space - so I have deleted everything inside tmp ... and am running the bitbake again. Let's see if it reuses the downloads from cache. Jan 13 16:34:01 it reuses downloads Jan 13 17:54:29 Crofton: napster ? Jan 13 18:00:20 khem, we are that old Jan 13 18:02:38 Crofton: I saw the screeching servers in data center in Fremont, we should do a fund raising campaign so we can get some modern servers for doing CI Jan 13 18:03:47 napster?! :) Jan 13 18:04:09 lol Jan 13 18:05:24 no you need to switch context RP you need to install go runtime or rust runtime where concurrency is handled in language runtime Jan 13 18:06:51 khem: Can't process that on a Sunday! :) Jan 13 18:11:18 sure Jan 13 19:52:14 Hi there, I'm trying to build a yocto-based project in a Nix FHSUserEnv. The problem I'm encountering is that while trying to configure m4, it fails a check. But when I run the command manually it works. Jan 13 19:52:24 configure:4902: ./conftest Jan 13 19:52:24 ../m4-1.4.18/configure: line 4904: 24322 Segmentation fault (core dumped) ./conftest$ac_cv_exeext Jan 13 19:53:12 Does anyone have a clue what could cause this? I suspect it might be related to some environment variables set by bitbake/yocto. Jan 13 19:53:25 what is a "Nix FHSUserEnv"? Jan 13 19:54:38 The Nix package manager usually doesn't use the FHS (filesystem hierarchy standard), so there's a function that creates a chroot and puts all the files into place. Jan 13 19:55:21 ah, that thingy Jan 13 19:55:44 so, a test program of m4's configure fails badly Jan 13 19:55:59 yeah, but if I do the same configure command manually, it works Jan 13 19:56:00 did you try it in devshell? Jan 13 19:56:15 nope, let me look at that Jan 13 19:56:38 also inspect logs to get the command line Jan 13 19:56:44 did you check the core file? Jan 13 19:56:52 usually it can tell you what went wrong Jan 13 19:57:28 will also look at that, thanks for the hints Jan 13 20:37:09 hm, can not get a devshell. I added the INHERIT and ran bitbake -c devshell, but it doesn't change anything Jan 13 20:37:56 ? Jan 13 20:38:18 the command is: bitbake -c devshell YOURPACKAGE Jan 13 20:38:26 yeah, I did that Jan 13 20:38:36 but it just tries to build and errors as before Jan 13 20:38:36 and what error did you get? Jan 13 20:38:48 same ./configure fail in m4 Jan 13 20:38:54 well, then m4 fails very early Jan 13 20:39:02 check the logs to find the right command line Jan 13 20:39:11 and as i said, inspect the core file Jan 13 20:39:17 something must be different Jan 13 20:52:17 true.. I just tried to use the exact same environment variables when executing the command manually and it worked. I just tried to get some information from the core dump but the backtrace doesn't tell me anything. This must be something so fundamentally wrong with the environment bitbake creates under this platform. I think I'll give it up for now, thanks for your help. Jan 13 21:15:46 Is the yocto sstate mirror not updated anymore ? Jan 13 21:22:51 Or if it is, which folder should one use together with "master" ? **** ENDING LOGGING AT Mon Jan 14 02:59:56 2019