**** BEGIN LOGGING AT Thu Oct 25 03:00:00 2018 **** BEGIN LOGGING AT Thu Oct 25 07:28:08 2018 Oct 25 07:42:55 has ypdd started ? Oct 25 08:06:43 armpit: technically yes Oct 25 08:23:12 LetoThe2nd, how do you get in ? Oct 25 08:23:16 any guards? Oct 25 08:27:02 Crofton__: just the usual. orcs, ogres, a hungry balrog and some lf folks Oct 25 08:27:43 as always, I forget to register as staff Oct 25 08:27:45 I think :) Oct 25 08:28:24 Crofton__: well the usual door bouncers asking for badges are still there Oct 25 08:33:49 Hi guys. Question: how should I create library symlinks? If I do this in the image_postprocess step they disappear before the image is built.. Oct 25 08:34:51 At least, the symlinks that I place in /lib or /usr/lib do. If I place them in another location they do remain. Which step causes them to disappear? Oct 25 08:35:01 Anyone else observing extreme slow uninative downloads http://downloads.yoctoproject.org/releases/uninative/ ? Oct 25 08:36:03 I meant rootfs_postprocess instead of image_postprocess by the way. Oct 25 08:36:50 halstead: ^^^^^^^^ (mns) Oct 25 08:37:15 RyanMeulenkamp: hum, why are you jumping through those magic hoops anyways, instead of getting stuff straight during do_install? Oct 25 08:38:46 Thanks LetoThe2nd Oct 25 08:39:23 mns_ which region is the download happening in? Oct 25 08:40:21 Denmark (Europe) Oct 25 08:41:48 Because the recipe it actually 'belongs' to has it's IPK's generated externally. Oct 25 08:42:43 RyanMeulenkamp: huh? you have a recipe that takes externally packaged ipks? or is it actually not a recipe, but something you just inject in the package feed Oct 25 08:43:24 RyanMeulenkamp: despite the fact this sounds extremely painful, the standard approach would be to do repackaging in the recipe. there's examples on doing that for debs, for example Oct 25 08:43:41 mns_ thank you. I'm checking a few things. Oct 25 08:43:41 halstead: Tracepath available here: https://pastebin.com/8caVM2sS - don't know if it makes any sense to you Oct 25 08:46:05 LetoThe2nd: Hmm alright, I'll have a look. Thanks! Oct 25 08:55:05 hi, how can i skip do_compile step ? I just need a do_install Oct 25 08:55:39 mns_, I'm seeing between 64-100mbps to Amsterdam and the UK. Can you run 'tracepath downloads.yoctoproject.org' and e-mail the result to mhalstead@linuxfoundation.org? Oct 25 08:55:59 RyanMeulenkamp: i think there was some doc or example but can't find t right now too. Oct 25 08:56:20 and rburton is offline. i'd suggest to poke him Oct 25 08:56:47 angelo_ts: here you go: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#packaging-externally-produced-binaries Oct 25 08:59:14 LetoThe2nd, thanks ! Oct 25 09:01:09 Ok, I am seeing <10kbps. I'll start by trying through my LTE connection - could be our corporate network. I'll get back with the observations Oct 25 09:10:26 Hmm, it works fine on a LTE connection and issue must thus be in our corporate network - sorry for the noise Oct 25 09:21:20 But thank, halstead Oct 25 09:57:38 mns_: FYI the speed looks good from Frederiksberg. Just out of curiosity, where in DK are you working with Yocto? Oct 25 10:16:22 mns_, Thanks for reporting. I'm always glad to check in. Oct 25 11:13:43 FrostEyes: Aalborg (Gomspace) Oct 25 12:04:57 ok now i have a weird one: when i try to use https://gitlab.denx.de/Xenomai/ipipe.git as SRc_URI for the kernel, it goes for a tableflip with "bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-image, expression was ...." Oct 25 12:06:20 why on earth is that? Oct 25 12:10:38 and where is zeddii when you need him Oct 25 12:14:10 gah paulbarker sorted it out Oct 25 12:34:42 hi Oct 25 12:36:13 does bitbake somehow block network access besides its own SRC_URI fetch related tasks? Oct 25 12:36:58 i.e. meson has a wrap system that allows to download missing dependencies on the fly during configuration stage Oct 25 12:38:58 T_UNIX: No. But if you want, you can do fetchall first and then run bitbake in a network namespace without internet access Oct 25 12:39:11 T_UNIX: nope it certainly doesnt Oct 25 12:39:22 at least not by default Oct 25 12:40:33 okay. Weird. Cause configuring the project works fine on my host. But fails during fetch w/ bitbake Oct 25 12:46:03 damn corporate proxy sh*$ Oct 25 13:19:30 fetching via urllib in python: works; fetching via meson (urllib) inside bitbake: fails -.-' Oct 25 13:20:48 sounds like that recipe needs fixing regardless. bitbake doesn't block fetching from buildsystems, but it'd be awfully nice if it did, since all fetching belongs in do_fetch Oct 25 13:33:02 Hi guys. Is in yocto any variable which contains a name of current git-branch? E.g. I want to use a git-branch name as a 'suffix' for generation of a name of my image. Oct 25 13:35:39 like: my-image-blabla-$${GIT_BRANCH_NAME}.ext3 Oct 25 13:44:15 kergoth: does it clean the enviornment variables it passes when it runs the stages? Oct 25 13:44:24 i.e. removing `https_proxy`? Oct 25 13:44:35 s/stages/tasks/ Oct 25 13:45:12 it does filter the environment, but iirc those should already be in the whitelist unless you're running a very old version Oct 25 13:55:53 guys, is it possible to call a system shell comamnds and to parse its output to some variables? Oct 25 13:56:47 e.g. I tried GIT_BRANCH_NAME='git rev-parse --abbrev-ref HEAD' but then ${GIT_BRANCH_NAME} returns 'git rev-parse --abbrev-ref HEAD' instead of, e.g. 'master' Oct 25 13:58:13 https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#basic-syntax Oct 25 14:01:51 I'm not a python expert.. From that doc I see similar: DATE = "${@time.strftime('%Y%m%d',time.gmtime())}" ... But I need to do similar only for 'git' command.. Oct 25 14:11:17 I found it: GIT_BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD) :)) Oct 25 14:12:45 kergoth: it is in the whitelist and fetching source via SRC_URI works. I just thought that bitbake might clean the environment prior to executing the compiled scripts (tasks) Oct 25 14:13:25 if it's set in the recipe metadata, it'll be set for hte tasks. i.e. run bitbake -e somrecipe | grep 'https_proxy=' Oct 25 14:13:39 filtering happens pretty early on, when setting up the global configuration metadata Oct 25 15:02:08 I've now added all the subprojects of the meson project as explicit SRC_URI (dublicating the checksum). That works. Oct 25 15:04:24 ah, nice Oct 25 16:05:44 if this question reoccurs: the workaround is to download all the files (disabling unpacking `;unpack=0`) and then append e.g. `do_configure_prepend` to copy the zip files from the `${WORKDIR}` to meson's packagecache dir (typcally: `${WORKDIR}/git/subprojects/packagecache`). From there it'll pick'em up, assuming it fetched it on its own. Oct 25 16:09:46 btw. I would have preferred `do_unpack_append` but, it seems, it is interepreted as python (i.e. indentation parsing errors, etc.) Oct 25 16:20:08 do_unpack[postfuncs] += "my_unpack_function" Oct 25 16:20:10 will do it Oct 25 16:30:30 is there a reasoning behind? Oct 25 16:36:23 I don't understandt he question Oct 25 16:36:39 the do_unpack function is python. bitbake's _append just concatenates you can't concatenate shell onto a python function Oct 25 16:37:16 whereas prefuncs/postfuncs are additional separate functions called, no string concatenation involved Oct 25 16:37:23 does that make it clear? Oct 25 16:52:20 kergoth: I didn't know one couldn't "mix". I thought commands were glued together and python snippets moved to tmp files and executed accordingly Oct 25 16:52:29 so yes, that makes it clear. Oct 25 16:54:36 it's not that granular. and wouldn't be possible in all cases. i.e. we can't just execute each fragment of an append/prepend separately, as later appends often reference earlier appends variables Oct 25 16:54:49 could break it up at each python/shell boundary, but no one has bothered to make it happen Oct 25 16:55:12 that's just what I assumed. Didn't mean to complain :) Oct 25 16:55:38 eh, it's a long standing limitation that occasionally irritates me, so.. :) Oct 25 16:56:39 when is it appropriate to use work-shared? Oct 25 16:56:45 notably kernel headers seem to get installed there by default Oct 25 16:56:56 but they are not preserved in sstate Oct 25 16:57:05 (at least not in my recipe) Oct 25 16:57:18 is it reasonable to add work-shared directories to sstate output dirs? Oct 25 16:57:35 work-shared is highly special cased and is pretty much only used by the kernel and gcc sources Oct 25 16:57:44 you really shouldn't be trying to use it for anything else Oct 25 16:58:06 my kernel recipe installs the produced uapi headers there Oct 25 16:58:21 but when the kernel is restored from sstate those headers are not Oct 25 16:58:51 sounds like you're installing them wrong Oct 25 16:58:53 i guess this is covered in the libc-linux-headers recipe, which is to add explict dependencies on do_install Oct 25 16:59:01 do_install should only ever be installing to ${D} Oct 25 16:59:16 then our other functions and tasks and sstate are responsible for putting it where it belongs Oct 25 17:00:34 the recomendation in linux-libc-headers is to add # do_configure[depends] += "virtual/kernel:do_shared_workdir" Oct 25 17:01:20 that's if you want to depend on the kernel headers, not write to them Oct 25 17:01:29 err, yeah Oct 25 17:01:38 i think my kernel recipe doesn't do the headers installation at the right time Oct 25 17:01:45 and my recipes don't depend on it properly Oct 25 17:01:58 yuck Oct 25 17:02:49 it's sadly easy to write terribly broken bsps Oct 25 17:03:17 either that or qcom puts a lot of effort into making their bsps terrible :p Oct 25 17:03:31 thx for the help Oct 25 17:08:07 i'd suggest reading do_shared_workdir to see how the files get deployed into workdir, but likely you just need to install the headers in do_Install to ${D}${includedir} Oct 25 17:08:13 s/workdir/shared_workdir/ Oct 25 21:08:07 in a bbappend file, if I set SRCREV_thing = "${AUTOREV}", can I do PV += "${SRCPV}" to get a specific SRC_URI to always fetch when the repository is updated? Oct 25 21:31:35 4.4.3-yocto-standard corresponds to which linux kernel version? 4.4.3? Oct 25 21:48:48 noway96: yup! The output of uname -r on a yocto-built kernel is a combination of the LINUX_VERSION LINUX_VERSION_EXTENSION variables. Your LINUX_VERSION seems to be 4.4.3 and the default value of LINUX_VERSION_EXTENSION is "-yocto-standard" Oct 25 21:58:04 ok thank you robbawebba. Oct 25 21:58:54 ALL: On rocko, my read only filesystem has most of the files with uid:gid 1000:1000 and not root:root. Is this normal or indication of a recipe issue? I didn't see this with my kergoth release. Oct 25 21:59:19 I know that linux 4.4.3 standard has NVMe support. Namely, it knows where to find the linux/nvme_ioctl.h command. But why when I try to build against 4.4.3-yocto-standard does it not compile and say unknown headers linux/nvme_ioctl.h? Oct 25 22:09:52 noway96: Was the kernel definitely compiled with nvme support? IIRC the config options are CONFIG_NVME and/or CONFIG_BLK_DEV_NVME Oct 25 22:11:30 CONFIG_BLK_DEV_NVME=m Oct 25 22:15:09 noway96: linux/nvme_ioctl.h doesn't seem to appear in linux kernel 4.4. There is NVMe support, but the only relevant header file I see in include/linux is nvme.h Oct 25 22:16:20 oh ok. how to I get the most recent yocto linux kernel version?? Oct 25 22:16:58 also I found nvme_ioctl inside linux-4.4.0 headers for ubuntu but I must have done something wrong Oct 25 22:17:25 what does the =m flag mean? Oct 25 22:19:42 noway96: ahh, I think I'm mistaken. the file appears at include/uapi/linux/nvme_ioctl.h. SO it should be available. I'm actually unfamiliar with the uapi subdirectory Oct 25 22:19:51 right Oct 25 22:20:02 =m means module Oct 25 22:20:14 anyway why won't this find nvme_ioctl then? Oct 25 22:20:30 do I need to do a rebuild from scratch? Oct 25 22:21:21 the =m flag instructs the kernel build system to build the nvme driver as a loadable module, rather than built into the kernel. If it was built-in, you wouldn't be able to insert or remove the module on-demand. It is built into the kernel if you choose =y, and it won't be included at all if you choose =n Oct 25 22:22:28 noway96: not sure why it won't find it. I'll brb, going to do some googling about uapi Oct 25 22:23:51 noway96: aokay, that's just the location of userspace API headers. That makes sense. Are you compiling on the target device, or are you compiling on your host PC? Oct 25 22:26:01 host PC Oct 25 22:26:50 thanks for the explanation Oct 25 22:28:44 conf/fatal error: linux/nvme_ioctl.h: No such file or directory Oct 25 22:29:02 Is this being built with bitbake? Oct 25 22:29:08 yes Oct 25 22:32:34 noway96: Okay, so it sounds like your recipe might not have access to the shared kernel source that is provided by the virtual/kernel recipe Oct 25 22:33:42 noway96: The virtual/kernel do_shared_workdir task populates ${STAGING_DIR_KERNEL} (which is often tmp/work-shared/${MACHINE}/kernel-source), which your recipe would need Oct 25 22:34:57 noway96: what tsak is your recipe failing at? do_configure? do_compile? Oct 25 22:35:28 do_compile: Function failed: do_compile Oct 25 22:37:04 but I found nvme_ioctl.h: tmp/work-shared/genericx86-64/kernel-source/include/uapi/linux/nvme_ioctl.h Oct 25 22:45:10 noway96: yup! Thats it :) Oct 25 22:45:33 So we have to make sure your recipe has access to those files Oct 25 22:45:56 adding do_compile[depends] += "virtual/kernel:do_shared_workdir" might be a start Oct 25 22:45:59 yeah still getting the same bug: fatal error: linux/nvme_ioctl.h: No such file or directory Oct 25 22:46:06 ok Oct 25 22:46:08 I'll try that Oct 25 22:52:58 doesn't look like it worked. still getting an error Oct 25 22:53:04 same error* Oct 25 22:53:09 robbawebba^ Oct 25 22:55:42 noway96: could you try making the do_configure task depend on the do_shared_workdir task? instead of do_compile Oct 25 22:57:14 yeah it could be a race condition. but I'm getting the same error still Oct 25 22:58:31 noway96: this dependency declaration should prevent the race condition, meaning that it should gaurantee that the linux kernel source is available in work_shared. But it seems like your recipe still cannot find the sources :/ Oct 25 22:58:45 and you verified that they are there in the work-shared directory Oct 25 22:59:30 yes Oct 25 22:59:52 they're in the path I shared with you earlier Oct 25 23:00:30 or rather, that's the path for nvme_ioctl.h. Is that what you're referring? Oct 25 23:01:44 yeah Oct 25 23:02:55 fatal error: linux/nvme_ioctl.h: No such file or directory. Maybe not linux/nvme_ioctl.h but some other path? Oct 25 23:04:47 noway96: I think that's the right include statement. Since linux/nvme_ioctl.h is located under include/uapi, we have to make sure include/uapi is able to be found by the compiler Oct 25 23:17:51 any ideas? is there something I can depend on to ensure that linux headers are there? Oct 25 23:21:11 robbawebba^ Oct 25 23:41:15 robbawebba, so turns out that it's something to do with Cython. Built my C++ code just fine using a Makefile with bitbake. So the issue is with using cython's setup.py for building. Oct 25 23:41:59 My python code wraps some C++ code that uses linux/nvme_ioctl.h Oct 25 23:42:24 C++ code compiles just fine by bitbake. But when wrapped by python, it doesn't Oct 25 23:42:52 robbawebba^ Oct 25 23:43:12 noway96: ahhh okay. I'm unfamiliar with how python/cython accomplishes this. It it's documentation, does it mention anything about adding more directories to look for when including headersw? Oct 25 23:47:31 well my build command works just fine right now when not used by Yocto, but I'll take a look Oct 25 23:50:12 there's an include_path variable which I can define to the kernel headers. Question is, what path should I use? Oct 25 23:51:34 ${STAGING_KERNEL_DIR} might be what you're looking for Oct 25 23:52:28 it's empty inside the devshell Oct 25 23:53:12 shoot, that might only be available to kernel recipes :/ Oct 25 23:55:46 noway96: huh, I'm definitley seeingnon-kernel bb recipes and classes use the KERNEL_STAGING_DIR variable Oct 25 23:55:57 PREFIX = os.path.normpath(sys.prefix).replace( os.getenv("BUILD_SYS"), os.getenv("HOST_SYS") ) Oct 25 23:56:06 TypeError: expected a string or other character buffer object Oct 25 23:56:26 So I need to set some variable in my recipe? Oct 25 23:56:35 no, that's usually set by the kernel recipe I believe Oct 25 23:57:05 can I set it? Is it BUILD_SYS ?= "" or something? Oct 25 23:57:10 so you would use the ${STAGING_KERNEL_DIR} variable in your yourto recipe Oct 25 23:57:14 yocto * Oct 25 23:57:56 I'm not sure if you can set it, without interfering with the kernel recipe at least Oct 25 23:58:17 I'm kind of lost for ideas at this point :/ Oct 25 23:59:08 unparsed line: 'BUILD_SYS = ${STAGING_KERNEL_DIR}' Oct 25 23:59:35 let me just try to get setup.py to build inside the devshell Oct 26 00:01:41 robbawebba: http://lists.openembedded.org/pipermail/openembedded-core/2014-February/089894.html Oct 26 00:19:43 ok so I overcome that bug with the patch. But still getting this error Oct 26 00:20:06 nice thing is that I'm inside the dev shell so I can build the underlying C++ code but not when I use Cython Oct 26 01:02:27 Hi all, Im reading here: http://lists.busybox.net/pipermail/busybox/2006-November/059507.html that post install scripts are not supported with busybox as init manager? Oct 26 01:02:32 this is also a related thread: https://lists.yoctoproject.org/pipermail/yocto/2015-March/024129.html Oct 26 01:02:41 anyone know if this is still the case? Oct 26 01:33:18 noway96: BUILD_SYS is already set, you just need to export it so it's in the environment of the task. 'export BUILD_SYS' Oct 26 01:33:29 noway96: one of hte python classes does that already, iirc Oct 26 01:33:48 so you might just be missing an inherit **** ENDING LOGGING AT Fri Oct 26 02:59:59 2018