**** BEGIN LOGGING AT Wed Oct 10 03:00:00 2018 Oct 10 03:52:46 why does DEPENDS = python3-pytest-runner not work Oct 10 03:54:04 ERROR: Logfile of failure stored in: /home/dingo/rpi-yocto/rpi64-build/tmp/work/aarch64-poky-linux/python3-flake8/3.5.0-r0/temp/log.do_configure.25715 Oct 10 03:54:04 Log data follows: Oct 10 03:54:04 | DEBUG: Executing shell function do_configure Oct 10 03:54:04 | ERROR: Do not try to fetch `pytest-runner' for building. Please add its native recipe to DEPENDS. Oct 10 03:54:04 | Traceback (most recent call last): Oct 10 03:54:08 grrrrrr Oct 10 04:34:15 New news from stackoverflow: Init service not running in yocto.. pidof not found error Oct 10 09:24:22 Morning! Oct 10 09:44:10 Question about downloaded sources ; Ive got maybe five different bsp projects on the go at any one time and Im scratching my head trying to decide on a strategy for locally storing downloaded sources. I cant quite work out whether I should be using common downloads via DL_DIR, PREMIRRORS or SOURCE_MIRROR_URL... My goal is to be able to build each independently offline (BB_NO_NETWORK) but to also be able to packag Oct 10 09:44:10 e up local sources downloads for each project without redistriubuting ALL downloads from all projects? Oct 10 10:54:55 no_such_user: just use a common DL_DIR Oct 10 10:57:28 rburton: If it's a single common DL_DIR, is there a way to extract the subset of contents to re-distribute per-build? Oct 10 10:58:57 Also, I was wondering if it was worth trying to locally / manually mirror some of the larger git repos to reduce network usage (my network bandwith is awful) Oct 10 11:12:26 hm if you set DL_DIR to the project local path and PREMIRRORS to the common place then do fetchall, it might do the right thing Oct 10 11:27:46 rburton: found a problem with the new autobuilder - wasn't setting PACKAGE_CLASSES :/ Oct 10 11:33:45 rburton: I'll have a play with that thanks. How do you stop it being unwieldy though? Every time one does a build with different yocto version or platofrm that creates another big swathe of downloads - do most people just dump into a common shared DL_DIR? Some of my big builds are tens of gigs of download per-board... Oct 10 11:34:02 yes, a common DL_DIR is the easy solution Oct 10 11:35:34 New news from stackoverflow: scipy python library installation in open embedded linux platform || Can I use Google-assistant library on YOCTO linux? [closed] Oct 10 11:56:40 hello! anyone building go executables on yocto? I have single such executable and I dont want to have 30MB go's stdlib, but GO_DYNLINK is set fixed in goarch.bbclass. is there another way to link with go's stdlib Oct 10 12:02:21 changing GO_DYNLINK to "" in goarch.bbclass did that. but I don't want to change class file Oct 10 12:02:29 no_such_user: You can also get by by periodically moving your current DL_DIR to a PREMIRROR and starting with a clean DL_DIR Oct 10 12:02:47 Not that this might only give you a complete download cache when you build from scratch (i.e. without sstate), though Oct 10 12:03:17 neverpanic: Yeah, I was wondering about something like that - i.e. a different DL_DIR for each project that forms a complete set of downloads for each Oct 10 12:03:39 Well yes, but even that will grow over time as your layers change Oct 10 12:12:39 ak77: setting it in your distro or local.conf should work Oct 10 12:16:32 rburton: it doesn't. bb.class imports bbarch (which defines GO_DYNLINK with =) and then inspects it, nowhere to interfere Oct 10 12:18:00 rburton: I tried GO_DYNLINK and GO_DYNLINK_package in distro Oct 10 12:18:26 rburton: oh, not bb.class, go.class inherits goarch.class Oct 10 12:35:47 New news from stackoverflow: Yocto- bitbake qt5-image - trouble creating bootable flash for rpi from result Oct 10 12:37:28 RP: autobuilder urls such as https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/42753/raw should set the mime type so i can read them in browser Oct 10 12:38:59 RP: was that a multilib build that failed? Oct 10 12:43:12 Hey All! Has anyone build a rootfs with busybox in it? I'm struggling to figure out how to do it Oct 10 12:46:07 davenporten: 1) open yocto quick start document 2) read and follow it 3) see, you've built a rootfs with busybox Oct 10 12:47:26 to expand on what LetoThe2nd said: busybox is the default, building an image *without* busybox is harder Oct 10 12:49:12 rburton: really? Do you mean that 'bitbake core-image-sato' will produce a rootfs with busybox? Because I haven't been seeing it, and that could be something else I'm doing wrong Oct 10 12:49:18 yes Oct 10 12:49:51 core-image-sato will maybe use bash as its shell, as it is way bigger anyways. Oct 10 12:49:55 rburton: Ok, good to know, I'll check that out. LetoThe2nd: Thanks for your response too Oct 10 12:50:31 And thanks rburton, as always for all your help Oct 10 13:10:51 rburton: musl Oct 10 13:11:07 rburton: you should file the mimetype issue upstream ;-) Oct 10 13:16:28 rburton: GO_LINKSHARED = "" does the trick. thank you anyway Oct 10 13:16:32 RP: i can replicate without anythign special Oct 10 13:17:41 rburton: right, musl just failed fastest, no-x11 is now showing it too, as I suspect will other builds Oct 10 13:17:59 rburton: might cancel that build and retest -next without the cmake bits? Oct 10 13:29:47 yes Oct 10 13:35:44 rburton: multiple builds in parallel and stopping builds is lovely now Oct 10 13:49:59 rburton: think I've figured out why opkg/apt runtime tests aren't running too Oct 10 15:46:26 hi, im trying to run QEMU testing on a "pelux" image. One of the tests that i included on local.conf, is auto. Its testing `buildgalculator` and it seems to keep failing because it cannot untar it. The tarball is of bz2 format and nor bzip, nor lbzip is installed to untar it. Oct 10 15:47:01 Is this something that has to be fixed on the "pelux" image or is it some error from poky? Oct 10 16:06:17 kinsifous: it sounds like the testcase is missing a dependency Oct 10 16:06:57 kinsifous: adding bzip2 to the image would fix it, adding the dependency to the test case would skip the test Oct 10 16:32:48 armpit: I merged the stable -next pieces for rocko and sumo btw. Let me know if/as/when there is anything else. If you need builds please run them, we can run more in parallel now Oct 10 16:48:43 RP. thanks for the merges.. and yes.. I will try to load up the builds, just added sumo-nmut Oct 10 16:49:33 why are the Smiley face icons now giving me the finger ? Oct 10 16:51:58 I just added stable/rocko-nmut.. Oct 10 16:53:41 halstead, you might want to check loads on the builder Oct 10 16:54:50 armpit, Looking at all the workers now. We don't watch loads for them. Oct 10 16:56:17 armpit, They are high as expected during a build. Is something timing out? Oct 10 16:57:12 no. just testing out RP parallel changes Oct 10 16:58:18 I have no idea if we have data on time vrs # nightly builds Oct 10 16:59:39 armpit, Ah. Okay. They are certainly under heavy load but still respond within 10 seconds. I look more at how many build can fit on each worker. Currently they all run 3. There is come optimization to do still. Oct 10 17:00:52 halstead, armpit: We can likely just move away from the notion of triggering one build at a time, the infrastructure and buildbot code can cope with multiple in parallel Oct 10 17:01:16 * RP queues a nightly-packagemanager Oct 10 17:04:51 RP, I've dropped thhe notion of one build at a time. I'm watching the number of builds per worker now. Oct 10 17:05:17 halstead: its still in the muscle memory of armpit, rburton and myself though Oct 10 17:06:21 For sure. Being allowed to forget that is nice. :) Oct 10 19:03:29 I'm getting errors creating a wic image with TMPDIR on a NFSv3 mount. Is this expected? It's complaining about the FIEMAP ioctl, SEEK_HOLE, and SEEK_DATA not being supported by the filesystem, but it seems like maybe they are implemented for NFS? Oct 10 19:23:19 Does it make sense to have one recipe build both a shared library and a program that uses that same library? Oct 10 19:35:07 uglyoldbob: certainly, there should be quite a few other example recipes where that is done Oct 10 19:35:37 uglyoldbob: you may choose to package the library separately within the recipe if there's a chance you'd want to use the library without the program it comes with Oct 10 21:18:03 What yocto(codename/release) started to provide ./dep-subgraph.py? Oct 10 21:22:08 That script is actually written by NCCgroup for visualizing package dependencies using dot files. Has anyone used it? Oct 11 02:56:54 Hi folks! The gstreamer1.0-plugins-bad-opengl package moved to gstreamer1.0-plugins-base-opengl in gstreamer 1.14 (yocto master). In meta-webkit, we currently link with -bad but we would like to link with -base if gst >= 1.14 instead. How could I put this logic in a recipe? Currently we have `RDEPENDS_${PN} += " ${@bb.utils.contains('PACKAGECONFIG', 'gst_gl', 'gstreamer1.0-plugins-bad-opengl', '', d)} \"` **** ENDING LOGGING AT Thu Oct 11 02:59:59 2018