**** BEGIN LOGGING AT Thu Oct 18 03:00:00 2018 Oct 18 06:18:49 H, what I should set in my recipe If I want to have my lib in target SDK ? Oct 18 06:21:39 all parameters with "nativesdk" results that lib is available on x86_64-nativesdk ..... Oct 18 06:22:45 but I see that I have to have this lib + includes into ../core-image-base/1.0-r0/sd/image/ .... Oct 18 06:23:37 to use these files in SDK after populate_sdk command Oct 18 06:24:15 So the difference between other lib and my is that my is missing in this sdk/image path Oct 18 06:38:26 I generated a sdcard image and it fails to mount the kernel's `debugfs`, as well as `/tmp`, `/var/volatile` etc. Oct 18 06:38:35 is this a known problem? Oct 18 06:38:47 this happened on rocko Oct 18 06:44:00 Is it possible to see the compile messages when building a package? Oct 18 06:46:41 learningc: whilst building a package or afterwards? Oct 18 06:47:38 afterwards you'll find the log in `build/tmp/work/$architecture/$packagename/$version/temp/do_compile.log` (or similar) Oct 18 06:59:36 it appears to be host-contamination. I.e. all core utils are owned by the bitbake executing user -.-' Oct 18 07:03:48 Hi, I solved problem with missing lib in my SDK but I don't know how to populate includes Oct 18 07:04:19 I have them on target image Oct 18 07:04:22 T_UNIX, Can we view it while building? Oct 18 07:05:23 but I don't see them on target SDK, do you know how to configure my recipe that it will copy includes to target SDK ? Oct 18 07:06:20 learningc: you might be able to do that by invoking more verbose output (`-D flag`) on the compile task. I.e. `bitbake -DDD -c compile $mypackage` Oct 18 07:06:33 I see Oct 18 07:06:40 I want to do that for the kernel Oct 18 07:13:22 my `coreutils` (v8.27) stay host-contaminated even after cleansstate + rebuild Oct 18 07:35:41 Is it possible to prevent package do_fetch, do_compile ? Oct 18 07:36:23 but I want to parse package recipe to build RDEPENDS packages Oct 18 07:39:41 mckoan: hello :) Oct 18 07:40:06 your workaround for libinih versioning works Oct 18 07:40:48 rokm: nice Oct 18 07:40:57 also I added some parameters which populates lib.so to target SDK Oct 18 07:41:06 but I can't force to populate includes Oct 18 07:41:10 :( Oct 18 07:41:32 includes are on target image Oct 18 07:41:44 because I added it in do_install Oct 18 07:41:58 but I don't see them on SDK image Oct 18 07:42:46 rokm: please share your actual recipe Oct 18 07:44:27 https://pastebin.com/SmvTxz98 Oct 18 07:45:41 additionally I added TOOLCHAIN_TARGET_TASK in core-image-base.bbapend Oct 18 07:49:04 and in my local.conf SDKIMAGE_FEATURES = "libinih" Oct 18 07:49:27 nokm: -dev? Oct 18 07:50:03 for SDKIMAGE ? Oct 18 07:50:32 TOOLCHAIN* Oct 18 07:50:59 (Keep in mind: I'm a n00b who's just trying to be useful.. :p ) Oct 18 07:51:30 rokm: But for my images, I'm doing TOOLCHAIN_TARGET_TASK += "libstdc++-dev libstdc++-staticdev" Oct 18 07:51:47 will try Oct 18 07:51:56 rokm: In order to get the C++ stdlib into the SDK Oct 18 07:53:55 rokm: So I'm just guessing you need something similar (i.e. -dev and/or -staticdev, depending on how you intend to link) Oct 18 07:55:39 I've added -dev but I will take a while Oct 18 08:04:31 What is the correct way to specify that my do_configure() step should happen within my ${S}? Oct 18 08:05:11 It's currently being executed within "build".. (also, this recipe inherits cmake) Oct 18 08:08:04 I think that there is no specific path to build Oct 18 08:08:25 I also used in my recipe ${WORKDIR}/build/... Oct 18 08:08:50 or I think ${S}/../ Oct 18 08:09:40 The build directory becomes ${B} .. which is fine for most of it.. I'm just relaying on a tool for the do_configure(actually do_configure_prepend()) that needs to be executed with CWD=the source directory Oct 18 08:10:05 relying? Oct 18 08:12:42 uhh :| Oct 18 08:12:45 I can have my do_configure_prepend() do: cd ${S} && && cd ${B} .. but it seems.. ugly... Oct 18 08:22:46 What is the best way to provide a different file in SRC_URI (eg. a conf file for nginx) based on the image being built. In one image I need a conf file, in another image I need a slightly different one. One of the image has IMAGE_FEATURE =" production " - can I use this somehow in the nginx.bbappend ? Oct 18 09:09:35 (Pretext: I *know* it's not how it's supposed to be done.) Is there a way to have a recipe use particular tools from the build-host system? Oct 18 09:17:49 jofr: what kind of tools? you can have native build the tools, then DEPEND on that package and it should be available in the PATH Oct 18 09:19:19 My situation is that I'm building an in-house application, but its build requires an in-house tool, a compiler for building protocol files (custom in-house equivalent, but not at all the same as, protobuf). This compiler is written in C# and needs to be executed with Mono. Since Mono isn't required on the target system at all, I was just wondering if I could take a shortcut and use the mono-installation from the host-system, instead of having my recipe depend on m Oct 18 09:21:07 mmircea3948: but DEPENDS doesn't make files available on the target (that's RDEPENDS), it makes them avaiable for compile Oct 18 09:21:12 oh. wrong user Oct 18 09:21:26 jofr: it was for you what I wrote to mmircea3948 Oct 18 09:22:15 jofr: so, you make native package that gets this tool and does do install to ${bindir}, then in your recipe in DEPEND on this -native package, and you should be able to use a tool Oct 18 09:23:08 ak77: I know. It's working fine when I have my recipe depend on mono-native. It just takes a huge amount of time to fetch and build mono .. which just seems like a waste of time to me, since I already have it on the host-system. And the output of this build-step is .cpp files, but not actual binaries that will get installed into the target. Oct 18 09:26:25 jofr: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-HOSTTOOLS ? Oct 18 09:27:25 ak77: Aha! Seems like what I'm looking for. :-) Thanks! Oct 18 09:27:57 ak77: Now I just have to make up my mind on whether I actually want to do this or not.. ;) Oct 18 09:28:35 jofr: i, personaly, would not. building mono-native is one time thing, and then it's available Oct 18 09:28:44 ak77: I'm on the fence, because depending on mono-native feels "correct" Oct 18 09:28:46 ak77: Exactly. Oct 18 09:30:19 Hi guys. I tried to create a skeleton of an own image_type_my.bbclass. Which contains only IMAGE_CMD_myimg () { Oct 18 09:30:19 bbnote "Create MY image" Oct 18 09:30:19 } Oct 18 09:30:26 mmircea3948: something like this maybe https://pastebin.com/TtCkcbHb ? Oct 18 09:30:43 mmircea3948: this is from bbappend file Oct 18 09:30:48 Also I have added IMAGE_CLASSES += "image_type_my" and IMAGE_FSTYPES = "myimg" Oct 18 09:31:05 How I can know that my changes were applied? Oct 18 09:31:32 jofr: I have thins in local.conf: HOSTTOOLS += "java" ... Oct 18 09:31:36 mmircea3948: this pastebin shows how to add multiple lines to FILESEXTRAPATHS with custom subdirectories, Oct 18 09:32:14 kuzulis: do you see bbnote output? try bbwarn Oct 18 09:35:44 ak77: Where I should to see that message? Oct 18 09:35:59 ak77: when you do bitbake image Oct 18 09:36:03 ak77: when you do bitbake `image` Oct 18 09:36:17 ak77: No, I do not see it Oct 18 09:36:30 ak77: did you change it to bbwarn Oct 18 09:36:38 ak77: Yes Oct 18 09:36:40 ak77: stop talking to yourself Oct 18 09:36:57 kuzulis: then it's not applied :O Oct 18 09:37:05 ak77: Maybe I need to see it from a some log file? Oct 18 09:37:56 kuzulis: bbwarn should be seen during bitbake `image`, do bitbake `image` -c cleansstate, bitbake `image`, if that doesn't work question is over my head Oct 18 09:41:15 ak77: Ahh.. I see now: WARNING: blabbla-m-image dp_image_myimg: Create MY image Oct 18 09:41:27 ak77: Many thanks Oct 18 09:46:38 How I should specify a dependency of myimg type from the ext3 image type? Is IMAGE_TYPEDEP_myimg += "ext3" a correct way? Oct 18 09:49:48 kuzulis: looking at https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/classes/sdcard_image-rpi.bbclass (which I believe is battle tested stuff), it seems a right way to do Oct 18 09:52:33 ak77: Ok, many thanks Oct 18 10:03:35 l Oct 18 10:28:46 Guys, another question: How to use a nested functions inside of a IMAGE_CMD_myimg {} ? Oct 18 10:29:05 e.g. I have created an empty function: _deploy_foo () { Oct 18 10:29:05 } Oct 18 10:29:37 and add it into: Oct 18 10:29:39 IMAGE_CMD_мимг () { Oct 18 10:29:39 bbwarn "Create МЫ image" Oct 18 10:29:39 _deploy_foo Oct 18 10:29:39 } Oct 18 10:30:01 but bitbake 'my-image' fails than Oct 18 10:30:29 then, with a strange errors Oct 18 10:31:11 like: '/run.do_image_myaimg.13211: Syntax error: "}" unexpected Oct 18 10:31:12 ' Oct 18 10:36:12 wtf? Oct 18 10:45:28 The proper way to append to SYSROOT_DIRS_NATIVE, is to to add ${STAGING_DIR_NATIVE}/my-directory? Oct 18 10:46:33 In the manual, I can't see another variable that contains the prefix I need to match the entries that are aready in SYSROOT_DIRS_NATIVE.. Oct 18 10:47:42 Also the "Note" below it seems to indicate that this is the proper way to do it Oct 18 10:48:16 kuzulis: look at run.do_image_* and have a look at line 13211 Oct 18 11:19:34 Still having problems with my -native recipe (A). It installs stuff into ${D}${bindir} but also into ${D}/opt. I then have a recipe (B) that depends on A. Recipe B's recipe-sysroot-native has all the things I installed into ${D}${bindir} in recipe A, but not /opt. I've been trying all kinds of combinations in recipe A, in order to add /opt to SYSROOT_DIRS_NATIVE in order to get /opt over to recipe B, but none of it works. What I've tried goes along the lines of: S Oct 18 11:21:22 If I do SYSROOT_DIRS_NATIVE_append = "${STAGING_DIR_NATIVE}/opt" and in recipe A's do_install step do a: echo "${SYSROOT_DIRS_NATIVE}" > /tmp/sysroot.txt, I can see that my line has been added to SYSROOT_DIRS_NATIVE and it looks just like the other ones.. but for some reason it's not being copied (or symlinked or whatever) over to recipe B's recipe-sysroot-native Oct 18 11:22:08 Or do I have to append to SYSROOT_DIRS_NATIVE in recipe B? Seems counterintuitive... Oct 18 11:48:15 'noon Oct 18 11:50:04 Potentially contentious question : I'm setting up a new build server - until now, most of our build machines have run Ubuntu LTS, but Ive been aware that a few tools tend to be maintained with distribution for debian only... Any particular pros/cons to changing? Im pretty much distribution agnostic myself but prefer to use longer supported releases Oct 18 11:50:49 no_such_user: run your server on what ever you are comfortable with, and use containers suiting the build needs. Oct 18 11:58:52 Why IMAGE_TYPEDEP_myimg = "ext3" ignores/ Oct 18 11:58:55 ? Oct 18 11:59:38 I have added IMAGE_FSTYPES = "ext3 myimg" Oct 18 11:59:55 but seems that myimc calls before than ext3 Oct 18 12:00:09 myimg runs before than ext3 Oct 18 12:02:11 in my IMAGE_CMD_myimg script I try to copy the rootfs.ext3 file to another location.. but this rootfs.ext3 file does not exists Oct 18 12:02:48 but it I do comments out 'myimg' in IMAGE_FSTYPES = "ext3" , thwn the rootfs.ext3 creates Oct 18 12:03:00 s/but it/but if Oct 18 12:03:45 how to make the image types dependency order? Oct 18 12:04:02 I have looked an example from: https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/classes/sdcard_image-rpi.bbclass Oct 18 12:04:53 and created an own bbclass by analogy with that.. but seems, IMAGE_TYPEDEP_xx does not work.. wtf? Oct 18 12:05:13 magic Oct 18 12:12:00 uhm, how do I tell bitbake to create new image files (tmp/deploy/images/*) when I stupidly deleted mine? Oct 18 12:12:26 running "bitbake " gives me "Attempted 1789 tasks of which 1789 didn't need to be rerun and all succeeded." Oct 18 12:14:04 I tried cleaning some packages, and -c do_rootfs but same result Oct 18 12:15:32 the -f flag forces a step to run Oct 18 12:16:58 right, but I'm guessing there are lots of steps to run to recreate all these files Oct 18 12:17:20 I find it a little puzzling that it doesn't detect that the output files are in fact not there Oct 18 12:22:04 Why this doc: https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-IMAGE_TYPEDEP lies? Oct 18 12:23:27 The IMAGE_TYPEDEP ignores at all Oct 18 12:27:07 haha. "bitbake -f -c do_rootfs " produces ... .testdata.json :) Oct 18 13:12:11 Is this invalid syntax: do_install_class-native[cleandirs]? It doesn't seem to be getting parsed (the directory is not cleaned ahead of the install task). Oct 18 13:12:44 New news from stackoverflow: How to copy content from .repo/manifests during repo sync? Oct 18 13:19:55 is it possible to have an optional file in SRC_URI? Oct 18 13:20:30 uglyoldbob: yes, use an inline python expression like ${@bb.utils.contains('your variable', 'some value', 'if true', 'if false', d)} Oct 18 13:23:14 that's useful but not quite what i meant. I was thinking something like SRC_URI += "file://blabla". If blabla is found then great, if blabla is not found then oh well keep going. Oct 18 13:24:17 uglyoldbob: oh... hmm. Well, you could still do something similar still using that method but instead making it an if statement using the os python package to check for the file. Oct 18 13:24:42 That could get dicey though since I think you would want to scrape all of the file paths for that recipe. Oct 18 13:26:00 uglyoldbob: so, it would be something like ${@'file://somefile' if os.path.exists('path to somefile') else ''} Oct 18 13:29:25 tgoodwin: thank you Oct 18 13:29:35 uglyoldbob: sure thing :) Oct 18 13:35:00 bb.utils.which() against FILESPATH would probably be needed as well unless you hardcode the path you're checking Oct 18 13:42:24 kergoth: is there a correct way to use "class-native" and varflags together? I'm using 1.36 and it throws no error when I have "do_install_class-native[cleandirs] += ..." but it also does nothing to those directories. Oct 18 13:43:20 remember that until overrides are applied, do_install and do_install_class-native are separate variables with separate flags. application of overrides can bring over certain specific flags, iirc, but not all Oct 18 13:43:29 i'd suggest an indirection Oct 18 13:43:49 MY_CLEANDIRS = ""; MY_CLEANDIRS_class-native = "foo"; do_install[cleandirs] += "${MY_CLEANDIRS}" Oct 18 13:51:36 kergoth: thanks! Oct 18 13:51:54 np Oct 18 13:53:51 Guys. I don;t understand, why my IMAGE_CMD_myimg called before than the *rootfs.ext3 file created? I have added IMAGE_TYPEDEP_myimg = "ext3"... IMAGE_FSTYPES = "myimg" and IMAGE_CLASSES += "image_type_my" Oct 18 13:54:23 ? Oct 18 13:56:04 My CMD is: Oct 18 13:56:05 IMAGE_CMD_myimg () { Oct 18 13:56:05 bbwarn "Create MY image" Oct 18 13:56:05 cd ${DEPLOY_DIR_IMAGE} Oct 18 13:56:05 mkdir my-out Oct 18 13:56:05 cp ${ROOTFS} my-out/rootfs.ext3 Oct 18 13:56:06 } Oct 18 13:56:55 why roots.ext3 not exists when IMAGE_CMD_myimg() called? Oct 18 14:01:55 bitbake -e imagename | grep ^ROOTFS Oct 18 14:12:17 uglyoldbob: ? Oct 18 14:12:47 Hello, is there a possibility to collect all sources for an image? Oct 18 14:12:59 so I end up with a bunch of tar.gz's or something? Oct 18 14:13:26 So Oct 18 14:13:53 I still have the sources in like 10 years, when half of the git-repo's stopped to exist (I don't know) Oct 18 14:14:16 woutervh: here you go https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#providing-the-source-code Oct 18 14:16:30 great, thankss Oct 18 14:17:44 kuzulis: that command should tell you what the value of ${ROOTFS} is. If it is the location of a folder or blank, the plain cp command will not work Oct 18 14:19:33 uglyoldbob: This returns an expected file path.. But in reality this file not exists yet when IMAGE_CMD_xx called.. It is a problem Oct 18 14:20:04 cp fails because the file not exists!!! Oct 18 14:20:50 but why rootfs.ext3 creates after the IMAGE_CMD_xx? it is magic for me Oct 18 14:21:25 because I already created a dependency IMAGE_TYPEDEP_myimg = "ext3" !!! Oct 18 14:22:17 as I understand, in this case IMAGE_CMD_myimg shoul be called after the ext3 created.. but this not happens!! Oct 18 14:23:10 wtf? I spent a lot time to understand.. why.. but it is not clear to me Oct 18 14:28:58 kuzulis: have you looked at the notes for IMAGE_FSTYPES? https://www.yoctoproject.org/docs/2.4.1/ref-manual/ref-manual.html#var-IMAGE_FSTYPES Oct 18 14:31:22 uglyoldbob: Yes Oct 18 14:31:53 uglyoldbob: But I did't use inside of IMAGE_FSTYPES Oct 18 14:32:20 uglyoldbob: But I did't use IMAGE_FSTYPES inide of image recipe.. I use it inside of a .conf file Oct 18 14:41:16 kuzulis: it looks like meta/classes/image_types.bbclass has an oe_mkext234fs writes its output to "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype" Oct 18 14:42:03 kuzulis: maybe ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.ext3 would work ? Oct 18 14:43:56 uglyoldbob: I construct my ROOTFS name in image_type_my.bbclass as: MY_IMG_ROOTFS = "${IMAGE_NAME}.rootfs.${MY_IMG_ROOTFS_TYPE}", where MY_IMG_ROOTFS_TYPE ?= "ext3".. Oct 18 14:44:41 but bitbake -e | grep ^MY_IMG_ROOTFS_TYPE returns: *-20181018144110.rootfs.ext3 Oct 18 14:45:25 but bitbake -e | grep ^SDCARD_ROOTFS returns: *-20181018144001.rootfs.ext4 Oct 18 14:45:48 uglyoldbob: So, as you can see that its timestamps is different Oct 18 14:46:09 why? :) Oct 18 14:47:08 kuzulis: the filesystems were built at different times. it looks like they were generate 9 seconds apart from each other Oct 18 14:47:32 or 1 minute and 9 seconds. lots of 0 and 1 there Oct 18 14:50:36 uglyoldbob: No, yor suggestion does not helped.. Oct 18 14:51:16 uglyoldbob: CP fails with: Oct 18 14:51:20 cp: cannot stat 'irp-embedded-qt5-x11-image-apalis-imx6-20181018144833.rootfs.ext3': No such file or directory Oct 18 14:51:47 because the *.rootfs.ext3 is not exists in that time Oct 18 14:52:31 because (as I said before) IMAGE_CMD_myimg runs before than ext3 dependency completes Oct 18 14:52:37 but why? Oct 18 14:53:09 kuzulis: what is ls -la (deploy dir here)/irp-embedded-qt5-x11-image-apalis-imx6-*ext3 Oct 18 14:53:50 uglyoldbob: There are (in deploy dir) no any *.ext3 file Oct 18 14:55:16 uglyoldbob: But if I make the IMAGE_CMD_myimg empty (e.g. with a simple 'echo' command), then *.ext3 creates Oct 18 14:57:01 grrrr struggling with file /var/www/index.html conflicts between attempted installs of A and B Oct 18 14:58:30 uglyoldbob: So, the ext3 creates too late Oct 18 15:00:14 uglyoldbob: Is any other way to defer the IMAGE_CMG_my ? Oct 18 15:00:33 s/IMAGE_CMG_my/IMAGE_CMD_my Oct 18 15:00:39 kuzulis: can you pastebin your image_type_my.bbclass ? Oct 18 15:01:16 uglyoldbob: https://pastebin.com/QdnfDz6Q Oct 18 15:16:56 uglyoldbob: Is any workaround to do not use IMAGE_TYPEDEP ? Oct 18 15:24:42 uglyoldbob: Is it a but in Yocto? Oct 18 15:26:09 kuzulis: i'm examining the custom image type on my system Oct 18 15:32:50 Hi Ross, I have started my meeting Oct 18 15:34:49 dreyna: bug triage overran, joining now Oct 18 15:43:15 New news from stackoverflow: conflicting requests error while building SDK Oct 18 15:44:43 kuzulis: what does ls -la tmp/work/machinename/imagename/bla/temp/log.do_image_ext3 and ls -la tmp/work/machinename/imagename/bla/temp/log.do_image_miaimg say? Oct 18 15:47:19 uglyoldbob: first: tmp/work/apalis_imx6-poky-linux-gnueabi/irp-embedded-qt5-x11-image/1.0-r0/temp/log.do_image_ext3 -> log.do_image_ext3.27962 Oct 18 15:48:21 uglyoldbob: second: tmp/work/apalis_imx6-poky-linux-gnueabi/irp-embedded-qt5-x11-image/1.0-r0/temp/log.do_image_miaimg -> log.do_image_miaimg.29231 Oct 18 15:48:57 kuzulis Oct 18 15:49:07 ? Oct 18 15:49:09 kuzulis: what is the timestamp reported? Oct 18 15:51:41 uglyoldbob: How I can see it? Oct 18 15:51:59 uglyoldbob: cp wants this ts: cp: cannot stat 'irp-embedded-qt5-x11-image-apalis-imx6-20181018154537.rootfs.ext3': No such file or directory Oct 18 15:52:36 uglyoldbob: but on FS placed a previous file: irp-embedded-qt5-x11-image-apalis-imx6-20181018153543.rootfs.ext3 Oct 18 15:52:54 kuzulis: ls -la shoudl show something like "lrwxrwxrwx 1 tepperson tepperson 25 Oct 18 11:35 tmp/work/de0nano-poky-linux-gnueabi/bh-de0-nano-1/1.0-r0/temp/log.do_image_miaimg -> log.do_image_miaimg.21152" Oct 18 15:53:46 uglyoldbob: ahh.. first: lrwxrwxrwx 1 denis denis 23 окт 18 18:37 Oct 18 15:54:19 uglyoldbob: second: rwxrwxrwx 1 denis denis 25 окт 18 18:45 Oct 18 15:54:36 s/окт/oct Oct 18 15:55:05 23 and 25 october o_O Oct 18 15:55:14 23 and 25 are filesizes Oct 18 15:55:29 ahh.. yes Oct 18 15:56:06 looks like the recipes are being called in the correct order. it matches my results as well Oct 18 15:56:24 uglyoldbob: It is strange Oct 18 15:56:59 uglyoldbob: any other ideas why ext3 does not exists in reality? Oct 18 15:57:13 try adding ls -la ${DEPLOY_DIR_IMAGE} into your IMAGE_CMD_miaimg, then check the log.do_image_miaimg log Oct 18 15:59:26 uglyoldbob: First: https://pastebin.com/emeLkp1T Oct 18 16:00:00 uglyoldbob: Second: lrwxrwxrwx 1 denis denis 25 окт 18 18:58 tmp/work/apalis_imx6-poky-linux-gnueabi/irp-embedded-qt5-x11-image/1.0-r0/temp/log.do_image_miaimg -> log.do_image_miaimg.29524 Oct 18 16:03:38 kuzulis: it looks like the image name contains a variable that depends on the current system time. it would seem this is regenerated within your image generation function, resulting in a different filename. Oct 18 16:05:00 uglyoldbob: ok, many thanks.. I will try to find that.. Oct 18 16:05:02 kuzulis: find a variable that resolves to irp-embedded-qt5-x11-image-apalis-imx6.ext3 Oct 18 16:05:26 kuzulis: it symlinks to the latest image created, which is most likely what you want Oct 18 16:07:18 uglyoldbob: Is this variable related to adding the '2018101815437' value? Oct 18 16:09:02 kuzulis: try echo "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.ext3" Oct 18 16:11:30 uglyoldbob: I tried 'bbwarn ${IMAGE_NAME}' and it returns: irp-embedded-qt5-x11-image-apalis-imx6-20181018161024 Oct 18 16:13:10 uglyoldbob: So, as I understand, I need to get the irp-embedded-qt5-x11-image-apalis-imx6 instead of irp-embedded-qt5-x11-image-apalis-imx6-20181018161024 ? Oct 18 16:14:21 kuzulis: that is correct Oct 18 16:14:57 uglyoldbob: Previously I had this: update_file_timestaps() { Oct 18 16:14:57 # Update file timestamp to 1 second since Epoch time. Oct 18 16:14:57 TZ=UTC find ${IMAGE_ROOTFS} -exec touch -h -m -t '197001010000.01' {} \; Oct 18 16:14:57 } Oct 18 16:14:57 ROOTFS_POSTINSTALL_COMMAND += "update_file_timestaps; " Oct 18 16:15:08 but I have removed it Oct 18 16:16:38 uglyoldbob: Do I need delete whole build- directory and to start bitbake from scratch? Oct 18 16:17:06 kuzulis: not likely Oct 18 16:18:33 uglyoldbob: Hmm.. Oct 18 16:19:24 kuzulis: try this: echo "${IMAGE_NAME%-*}" Oct 18 18:10:52 khem: nice, vscode settings sync extension supports vscodium, code portable, and now has per-platform/per-hostname settings. much more useful now Oct 18 19:46:20 how to start a build then detach from the bitbake server, later can connect to see the progress Oct 18 19:48:33 xtron1: don't think it can work that way right now, I believe it is expected that there is at least one active UI Oct 18 19:48:41 xtron1: the practical way to do such a thing is GNU screen / tmux Oct 18 19:49:16 (I use screen for this all the time) Oct 18 19:50:04 bluelightning: there is option " --server-only " which will start without UI, I never used that Oct 18 19:50:39 active UI can be the web one for toaster Oct 18 19:50:45 then you can effectively 'detach' Oct 18 19:50:54 but don't know how to re-connect :P Oct 18 19:51:19 --server-only Run bitbake without a UI, only starting a server Oct 18 19:51:26 i should give it a try Oct 18 20:01:07 i use tmux myself Oct 18 20:36:05 I can't use linux/nvme_ioctl ? I have to use linux/nvme? And even then I'm getting error: aggregate 'nvme_admin_cmd cmd' has incomplete type and cannot be defined. It's struct nvme_admin_cmd. Oct 18 20:36:30 uname -r: 4.4.3-yocto-standard **** ENDING LOGGING AT Fri Oct 19 03:00:00 2018