**** BEGIN LOGGING AT Fri Nov 16 02:59:58 2018 Nov 16 03:57:46 New news from stackoverflow: how to simplify recipe-sysroot-native Nov 16 07:28:23 New news from stackoverflow: CUPS web interface on YOCTO Nov 16 07:50:58 Hey, I'm trying to build my first yocto for raspberry pi, but getting problems with automake all the time: ERROR: Task (virtual:native:/home/mo/src/poky-sumo/meta/recipes-devtools/autoconf/autoconf_2.69.bb:do_compile) failed with exit code '1' Nov 16 07:51:21 console output is at https://nopaste.xyz/?d85a6d38288728b9#D9//svPbk1kebH6XIQb1yxVy8A3rHrBL+5rwMSb4s3g=, logfile at https://nopaste.xyz/?98115df586278c7a#CYLQJY1u1ghiVglHaNIZpa07cDipGeYIa3Cbo+CaunY= Nov 16 07:52:02 autoconf on the host-system (debian stable) is installed as well: mo@rrpc0019:~/src/yocto-rpi/build$ autoconf --version Nov 16 07:52:05 autoconf (GNU Autoconf) 2.69 Nov 16 07:52:13 any hints where to dig further? Nov 16 08:08:30 hello, so Thud was released yesterday, but I see that thud-next branch is lagging behind the thud branch... I was kinda expecting it to be the other way around... can someone explain the difference and purposes of the two branches? Nov 16 08:11:17 the yocto-2.6 tag is actually the latest one on the thud-next branch Nov 16 08:16:11 moemoe: well its not about the autoconf on your host, ot is trying to build its own one. but it rings a bell, with the m4 message. Nov 16 08:16:30 Hi, I am trying to build zeromq.js for raspberrypi3. My recipe is found here: https://gist.github.com/jostor/9f98b37cff6b08cac132ed7f167b16e1#file-gistfile1-txt Nov 16 08:16:41 The build fails with "configure: error: cannot run C compiled programs. | If you meant to cross compile, use `--host'." Nov 16 08:16:44 See complete log here: https://gist.github.com/jostor/e200d7993cbc0b271aeddc7421ad3a46 Nov 16 08:17:02 Does anyone know how to solve this? Nov 16 08:19:45 moemoe: actually no, sorry, i misremembered it Nov 16 08:22:31 jostor: find the already existing solutions as inspiration here: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-connectivity/zeromq/zeromq_4.2.5.bb?h=master Nov 16 08:24:04 jostor: and as you are basically trying to build the node bindings it seems, it obviously needs zeromq itself to be ready first. so you need to set a DEPENDS on it. Nov 16 08:24:31 hi, is there any layer that provides libperl5.14 for yocto? perl itself is available but it doesn't have any modules available (and at least on Debian those are part of libperl) Nov 16 08:27:17 jkliemann: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/perl/perl_5.24.4.bb?h=master#n269 suggests that its there, and the package is called perl-lib Nov 16 08:28:14 LetoThe2nd: hm. thanks anyway. the strange thing is that autoconf and automake both have problems, with similar errors: "configure: error: The installed version of autoconf does not work" and "autom4te: need GNU m4 1.4 or later: m4", so at first it looks like there is some problem with my local tools. Nov 16 08:29:11 moemoe: i'm not totally convinced there. you do have the prerequisites as mentioned in the quick start guide installed? Nov 16 08:35:13 LetoThe2nd: Thanks! I have added DEPENDS += "zeromq" to my recipe, but I am still getting errors: https://gist.github.com/jostor/495f91b35b0fff839c6b284293bc9c04 Nov 16 08:35:23 LetoThe2nd: thanks, perl-lib was the information I needed Nov 16 08:36:38 LetoThe2nd: I installed the packages mentioned in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ubuntu-packages Nov 16 08:37:50 jostor: this might be related to non-crosscompile-issues in the node bindings, but i don't have the possibilities to dig into this at the moment. my suggestion would be to put it on the ML, and/or wait a couple of hours until the USians are wake. Nov 16 08:38:30 moemoe: the essentials part, right? Nov 16 08:39:53 LetoThe2nd: right Nov 16 08:40:29 LetoThe2nd: Ok, Thanks, I will do that Nov 16 08:41:26 moemoe: ok, fine. and this is an otherwise completely untinkered debian as a build host? which poky revision plus layers are you using? Nov 16 08:41:48 LetoThe2nd: it seems the perl standard lib is still not available (or complete), in my case I need File/Glob.pm which isn't available under /usr/lib/perl Nov 16 08:42:34 jkliemann: you'll have to read the perl recipe then and find out if what you are missing is disbaled, or packaged otherwise, or... Nov 16 08:44:34 LetoThe2nd: It's a host I use for development, but all packages installed should be plain debian stable. I'm using sumo, overlays are https://github.com/jumpnow/meta-rpi and the ones listed as dependencies below. Nov 16 08:46:24 moemoe: could you give it a try in the vanilla rpi situation? e.g. poky + meta-openembedded + meta-raspberrypi, and from meta-openembedded you only need oe, python, networking, multimedia Nov 16 08:46:45 moemoe: as documented here: https://git.yoctoproject.org/cgit.cgi/meta-raspberrypi/about/ Nov 16 08:47:16 (feel free to read it as: i'm not convinced that the security and jumptek layers are ok) Nov 16 08:47:47 and the state i linked is pretty much known good, just built it myself a couple of days back. Nov 16 08:51:02 LetoThe2nd: WIll do Nov 16 09:25:41 LetoThe2nd: Still the same problem: https://nopaste.xyz/?f60384e66175c735#VqrbiFda2E9OYC51pUWKUGwjCKIiUwblWAWCOFvp3vM= Nov 16 09:25:50 the config is https://nopaste.xyz/?ed6680e3d75daf23#1oy+azqrGIvzHQO47SmQ9BZcUxhYwxq0sliQUU3d6vM= Nov 16 09:27:26 Anyone here experienced a bitbake devshell under tmux not going into the appropriate CWD? For me, it just stays in my build-root-directory where I issued the bitbake command..? Nov 16 09:27:48 My OE_TERMINAL is set to tmux-new-window Nov 16 09:28:43 If I use another terminal for OE_TERMINAL I get the correct behavior. Nov 16 09:28:51 New news from stackoverflow: how to force order in DEPENDS while preparing recipe-sysroot? Nov 16 09:41:15 rburton: care to glance over -next? Nov 16 09:41:28 rburton: builds cleanly and I think this does fix the httpservice hang Nov 16 09:42:57 LetoThe2nd: switched to thud, no problems so far (but compile is still running). Nov 16 09:43:21 just didn't wait long enough :/ Nov 16 09:43:27 | ERROR: Function failed: do_compile (log file is located at /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/work/x86_64-linux/autoconf-native/2.69-r11/temp/log.do_compile.21092) Nov 16 09:43:30 ERROR: Task (virtual:native:/home/mo/src/poky-thud/meta/recipes-devtools/autoconf/autoconf_2.69.bb:do_compile) failed with exit code '1' Nov 16 09:45:28 moemoe: Some things to check a) did it build m4-native? b) is m4 in the recipe-sysroot-native for autoconf-native? c) is there anything interesting about the missing m4 in config.log ? Nov 16 09:53:02 RP: a) according to tmp/log/cooker/raspberrypi-cm3/20181116093521.log "NOTE: recipe m4-native-1.4.18-r0: task do_populate_sysroot: Succeeded" Nov 16 09:53:06 b) mo@rrpc0019:~$ grep m4-native src/poky-thud/meta/recipes-devtools/autoconf/autoconf.inc Nov 16 09:53:09 DEPENDS += "m4-native" Nov 16 09:53:11 DEPENDS_class-native = "m4-native gnu-config-native" Nov 16 09:54:54 moemoe: no, for b), I mean to go into /home/mo/src/yocto-rpi/plain-rpi/tmp/work/x86_64-linux/autoconf-native/2.69-r11/recipe-sysroot-native and see if usr/bin/m4 exists Nov 16 09:55:11 RP: c) doesn't look strange: https://nopaste.xyz/?bcda865b6c189a2c#tycRl//2G0C6UEf1uaqiour0k+NttYNcyXVGBK8goq0= Nov 16 09:55:36 moemoe: can you share the whole config.log please? Nov 16 09:56:50 moemoe: of course this is autoconf-native itself so its not a normal configure process :/ Nov 16 09:57:43 https://nopaste.xyz/?ded25feb29107b7f#M4DXrrxHJDFTzMtQviEBnbnWsoPjy/uybUslN/Ftmmo= this m4 binary looks strange to me Nov 16 09:59:24 moemoe: something is definitely wrong there Nov 16 09:59:41 moemoe: does /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 exist? Nov 16 10:00:13 here is the complete log file: https://nopaste.xyz/?50ccf4432b15bc4e#tAdNq+b54Iu4FBNfSOkCezPrgZK8hPMe/YfCOTdU4cs= Nov 16 10:00:41 mo@rrpc0019:~/src/yocto-rpi/plain-rpi-thud/tmp$ file /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 Nov 16 10:00:43 /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2: symbolic link to ld-2.28.so Nov 16 10:00:46 mo@rrpc0019:~/src/yocto-rpi/plain-rpi-thud/tmp$ file /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ld-2.28.so Nov 16 10:00:50 /home/mo/src/yocto-rpi/plain-rpi-thud/tmp/sysroots-uninative/x86_64-linux/lib/ld-2.28.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=692dcab863f5451a27fa549f337f6ce1767f36fe, stripped Nov 16 10:02:14 moemoe: are you building on a noexec filesystem or something odd like that? has any OE/Yocto build every worked? Nov 16 10:03:34 moemoe: also, what is the host distro? The only difference in the file output between your build and mine is your kernel version is older (2.6.32 for you, 3.2.0 for me) Nov 16 10:04:42 moemoe: I suspect something in the uninative code is break things but I don't know how/why :/ Nov 16 10:08:33 hum, he said "debian stable"... but 2.6.32 indicates debian squeeze, which is certainly far beyond stable, with LTS having ended in 2016 Nov 16 10:09:05 LetoThe2nd: remember this is a minimum version, not the actual kernel version Nov 16 10:09:27 RP: i remember nothing, as usual. ;-) Nov 16 10:09:39 so its certainly using a generation older ABI than my binaries but doesn't mean its that old Nov 16 10:11:40 It's a Debian running in WSL, I just ordererd a regular Debian VM to try over there. Nov 16 10:11:45 Will be ready in some minutes :) Nov 16 10:12:54 moemoe: WSL? That is known not to work Nov 16 10:13:00 *bingo* Nov 16 10:13:22 (why can't people mention such weirdnesses right upfront?) Nov 16 10:14:49 I think we're going to need to start detecting WSL Nov 16 10:14:58 RP: Okay. Good to know. I searched for WSL in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html but it wasn't mentioned there Nov 16 10:15:44 Just came to my mind when reading the kernel version above, using it for golang since a while and never had problems... Nov 16 10:15:45 moemoe: I will mention this to our docs person, we should probably put it in big letters that WSL doesn't work :/ Nov 16 10:16:11 moemoe: OE/Yocto do some interesting things with the system which WSL doesn't support Nov 16 10:16:23 I'd love to have it work but as of today it doesn't Nov 16 10:17:39 Would be great to mention it in the docs, or even better detect it automatically, could have saved me a day of trying. Nov 16 10:17:42 $ cat /proc/version Nov 16 10:17:45 Linux version 4.4.0-17134-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #345-Microsoft Wed Sep 19 17:47:00 PST 2018 Nov 16 10:18:08 searching for m$ in /proc/version should be the easist wayI guess Nov 16 10:19:21 But thank you for your help so far, RP and LetoThe2nd, sorry I wasted your time trying to hunt an error on a known non-working system. Nov 16 10:19:46 moemoe: we'll improve the docs and I'll try and add something to detect this, we need to do better here Nov 16 10:30:24 moemoe: patch queued: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=b6fa510868572683749acc1a651d03d1a7c77da0 Nov 16 11:02:48 moemoe: what's the error? Nov 16 11:03:24 rburton: the error was using wsl ;) Nov 16 11:03:33 oh right yeah don't do that Nov 16 11:04:11 though bonus points if you root cause it and figure out what the problem is Nov 16 11:04:29 brownie points, even? Nov 16 11:05:03 rburton: https://nopaste.xyz/?ded25feb29107b7f#M4DXrrxHJDFTzMtQviEBnbnWsoPjy/uybUslN/Ftmmo= this is closest I got to the problem Nov 16 11:05:21 ah yeah thats a problem Nov 16 11:05:30 so it can't run native binaries that it build for itself Nov 16 11:06:09 might be useful to file a bug so we keep track of where wsl breaks in case someone really does want to fix it Nov 16 11:07:53 Hi guys. What is a best way to generate an different images with a different Linux Kernel patches/configs? For example I have a layer 'foo' which contains the linux recipes and a foo-image recipes.. also I have a layer 'bar' which too has an own linux recipes and own bar-image recipe.. All these layers both are added to bblayers config... Nov 16 11:08:29 e.g. foo layer has: meta-foo/recipes-kernel/linux/ and layer bar has: meta-bar/recipes-kernel/linux/.. Nov 16 11:09:02 kuzulis: if its otherwise completely identical images, just the kernel differs: either select the kernel through PREFERRED_VERSION/PREFERRED_PROVIDER in local.con, or, make it two machines. Nov 16 11:10:20 RP: next looks good Nov 16 11:11:47 LetoThe2nd: "PREFERRED_VERSION/PREFERRED_PROVIDER" but the Linux kernels are identical for both layers... How I can divide it to two different providers? Nov 16 11:12:23 well you'd obviously have to give it distinct names, like linux-foo and linux-bar Nov 16 11:12:48 which could be merely wrappers around a common linux-funky-stuff.inc Nov 16 11:15:34 LetoThe2nd: Hmm.. but, then I need to modify the local.conf file each time when I want to build the foo-image or bar-image.. Yes? But, is it possible to do it without of modifing of local.conf? Nov 16 11:15:47 kuzulis: -> MACHINES Nov 16 11:16:48 in the end you'd basically have two biuld directories. they can share a common sstate, so little performance penalty. Nov 16 11:19:50 LetoThe2nd: So, do I need to imagine an own machine name? Nov 16 11:20:18 if you're lacking imagination, call them machine1 and machine2..... Nov 16 11:22:08 i mean, you need *SOME* kind of distinction *SOMEWHERE* Nov 16 11:27:12 LetoThe2nd: Hmm.. I don't understand a bit... F.e. currently I use an one board 'apalis-imx6' as a basic platform for the different output images... Some of this images has an bluetooth stack enabled, some has an WiFi support enabled and so on... So, it is similar to that a different 'images' belongs to a different 'projects' basen on 'apalis-imx6' machine. Each that project located on own layer (with own image recipe, a main application recipe and so Nov 16 11:27:13 on.)... So, is it an one way to do such customizations - it is create an own machines for each 'project/layer'? Nov 16 11:29:00 it really depends on the variations between the projects. but generally, yes, its very common to have a MACHINE config per project. Nov 16 11:30:08 LetoThe2nd: Ok, many thanks for your help. I try look to this way :) Nov 16 11:31:31 kuzulis: in a nutshell, try to view it as three orthogonal things: MACHINE: defines the hardware/feature support for a given project, DISTRO: defines the ABI for a project, IMAGE: defines what packages go into a specific thing Nov 16 11:33:02 LetoThe2nd: What is means of " the ABI for a project" ? Nov 16 11:35:01 kuzulis: https://en.wikipedia.org/wiki/Application_binary_interface Nov 16 11:35:36 LetoThe2nd: I mean in context of Yocto.. :) Nov 16 11:35:53 kuzulis: its the same in the context of yocto. Nov 16 11:36:05 LetoThe2nd: Ok, manu thanks Nov 16 11:39:36 rburton: thanks Nov 16 12:16:53 now binutils-cross-arm fails. /home/yocto/src/yocto-rpi/plain-rpi-thud/tmp/log/cooker/raspberrypi-cm3/console-latest.log -> http://ix.io/1s5Y and /home/yocto/src/yocto-rpi/plain-rpi-thud/tmp/work/x86_64-linux/binutils-cross-arm/2.31-r0/temp/log.do_compile.25454 -> http://ix.io/1s5X Nov 16 12:17:34 running on branch "thud" and master for meta-raspberrypi Nov 16 12:53:48 moemoe: you do seem to be having some bad luck with this :( Nov 16 12:54:10 moemoe: We build that in our core test builds so it would suggest something rpi related :/ Nov 16 12:54:43 moemoe: you might want to test if qemuarm builds? see if you can at least get that working? We *know* that should work Nov 16 12:56:21 RP: I'm currently trying sumo, as there is no official thud release for meta-raspberrypi and I need a working system :) Nov 16 12:56:42 But as soon as this is okay I can strart a qemuarm build w/o meta-raspi in teh background Nov 16 13:29:44 New news from stackoverflow: How to find which Yocto Project recipe populates a particular file on an image root filesystem Nov 16 13:55:03 regarding dnf and package-management, i did notice that specifying PACKAGE_CLASSES ?= "package_rpm" got rpm into my build, but not dnf. I also could not find any reference to dnf in any of my layers. Nov 16 13:55:19 is it possible that morty did not yet include dnf? Nov 16 13:57:17 or is specifying PACKAGE_CLASSES ?= "package_rpm" in my build/conf/local.conf does not operate properly and i need to have it in my own distro.conf file? Nov 16 13:57:43 yates: which version are you building (which branch?) Nov 16 13:58:06 I need to have internal copies of all the source code used to build the linux image in my company. That means cloning all the github repos and tarballs to our servers, and making the recipes point to them. Nov 16 13:58:06 Poky has a very large number of recipes, and manually rewriting all of them would be a lot of work... Is there any way of doing that in a efficient and reliable way, instead of manually? Nov 16 13:58:31 bernardoaraujo: using our inbuilt mirroring mechanism? Nov 16 13:59:07 bernardoaraujo: PREMIRRORS and BB_GENERATE_MIRROR_TARBALLS Nov 16 13:59:08 hey RP, I'm not aware of it... where can I find more info? Nov 16 13:59:25 RP: i believe it's Mort, yocto project version 2.2, current version 2.2.4, as stated here: https://wiki.yoctoproject.org/wiki/Releases Nov 16 13:59:30 Morty Nov 16 14:00:04 yates: morty contains smart instead of dnf Nov 16 14:00:10 aha. Nov 16 14:00:10 yates: we only moved to dnf later Nov 16 14:00:15 aha! Nov 16 14:01:06 yates: morty is *old* Nov 16 14:01:22 (just in case you didn't already know) Nov 16 14:01:55 rburton_: have you much for the AB right now? Nov 16 14:02:02 was literally gearing up a build Nov 16 14:02:13 rburton_: i do. there are some painful reasons we need to stay here for right now. Nov 16 14:02:15 i can wait, or pull something else in Nov 16 14:02:28 rburton_: can you include -next? I could do with a build to watch the AB UI ;-) Nov 16 14:02:45 rburton_: -next is mainly some bitbake tweaks Nov 16 14:02:47 RP: was firing mut so that's based on current next Nov 16 14:02:59 rburton_: could you quickly rebase please :) Nov 16 14:03:07 top commit right now is the wsl fix Nov 16 14:03:15 rburton_: its not now Nov 16 14:03:18 oh now you've pushed ;) Nov 16 14:03:51 rburton_: just to be awkward :) Nov 16 14:04:04 fired Nov 16 14:04:12 also got mingw master-next with the three new patches in Nov 16 14:04:33 rburton_: thanks. Now lets see if the UI behaves better Nov 16 14:04:39 RP: would it be hard to modify to pull in dnf instead? i've found it in the latest openembedded project here https://layers.openembedded.org/layerindex/branch/master/layer/openembedded-core/ Nov 16 14:06:04 yates: the switch from smart to dnf certainly wasn't trivial Nov 16 14:06:18 the rootfs generation is done with that tool so its not just an swap Nov 16 14:06:45 and wasn’t there an rpm5 issue with dnf, hence why we are also rpm4+dnf now Nov 16 14:07:22 yates: I'd recommend using a later release, it will be easier Nov 16 14:07:36 zeddii_home: pretty sure dnf needs rpm4 Nov 16 14:07:42 correct Nov 16 14:07:49 you have to swap rpm5 for rpm4 Nov 16 14:07:58 yates: at the end of the day dnf and smart both *work* Nov 16 14:08:06 we flipped for numerous reasons Nov 16 14:08:35 backporting all the patches to morty isn't impossible, but its likely easier to upgrade past morty! Nov 16 14:08:57 if you have an OEM who only supports morty, point out how old it is and how its not getting security fixes anymore Nov 16 14:10:43 rburton_: we're using Variscite SoMs, and they do provide newer yocto project versions, but thos new versions use newer versions of the serial driver, and we've made some very painful tweaks on that version of the serial driver. Nov 16 14:11:38 and these tweaks are crucial to the functionality our business is providing Nov 16 14:12:12 that is, our product Nov 16 14:12:24 yates: I suspect using making their morty kernel work on a later release would be easier than swapping in dnf Nov 16 14:12:44 * zeddii_home nods Nov 16 14:14:15 IF we were to switch now, would sumo be right? Nov 16 14:14:54 RP: if I prepend my server to the PREMIRRORS var, how do I know whether the source code will be fetched from the mirror or the actual SRC_URI? Nov 16 14:16:52 bernardoaraujo: BB_FETCH_PREMIRRORONLY = "1" Nov 16 14:17:24 yates: that depends. thud just released, sumo is more stable/tested Nov 16 14:17:35 we release every six months Nov 16 14:21:16 ok, thanks. i'm tempted to just use smart... that's the MUCH more direction option for now. Nov 16 14:21:23 more direct Nov 16 14:22:00 i know upgrading is going to be required, but not TODAY... :) Nov 16 14:49:54 hi, is there a way to install native python six from the standard library? Nov 16 15:09:32 lpapp_: python-six-native? Nov 16 15:10:23 (meta-python) Nov 16 15:39:43 rburton_: that would bring another layer in, so I have decided to eliminate the use of six in our python code, thanks Nov 16 15:40:04 also, I am not sure why people need native python in the sdk... cannot the system-wide python be used ok? Nov 16 15:41:03 lpapp_: sometimes the system-wide python is too old Nov 16 15:41:16 or sometimes the sdk contains python modules that are written in C Nov 16 15:41:43 *if* you can assume the host has a good enough py and *if* you've verified there is no python-written-in-c in your sdk, it's fairly trivial to knock out Nov 16 15:41:58 where does smart get its configuration from? for example the repository uri? Nov 16 15:41:58 is it Nov 16 15:42:28 we already do exactly that for perl Nov 16 15:42:37 yates: /etc/something :) Nov 16 15:43:19 the docs say /etc/smart... but there is no such file/directory. yet it is connecting to the uri i specified in the build... Nov 16 15:43:31 yates: magic! grep for that url? Nov 16 15:43:36 don't tell me it gets hardcoded... Nov 16 15:43:44 no Nov 16 15:43:45 how to knock out Nov 16 15:43:48 must go somewhere else Nov 16 15:43:58 lpapp_: see meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb Nov 16 15:43:59 i ran strace and could see anywhere in /etc Nov 16 15:44:22 -0couldn't see Nov 16 15:54:03 hmm. /var/lib/smart/config Nov 16 15:54:15 berry stwange Nov 16 15:54:50 the magic of unconvention... Nov 16 15:55:52 hooray smart Nov 16 15:56:09 maybe it look in both and the automatic feed configuration should write to /etc instead Nov 16 15:58:05 rburton_: Seeing as this is the first layer I've ever maintainer, don't think your off the hook yet, I will have questions :) Nov 16 15:59:59 JPEW: that's fair :) Nov 16 16:00:51 JPEW: :D Nov 16 16:01:24 JPEW: fwiw i've the last few patches on the list running through the ab now Nov 16 16:01:49 rburton_: for some definition of running ;-) Nov 16 16:01:58 * RP ducks Nov 16 16:01:59 pah Nov 16 16:02:03 this new run is a lot happier! Nov 16 16:02:12 oh forgot to rebase the dnf patch! Nov 16 16:02:45 Ok. that is one of my questions; How do I patches for meta-mingw get run through the AB? Nov 16 16:03:45 JPEW: the nightly-qa-extras run currently exercises it a bit Nov 16 16:03:58 fired as part of the "nightly" build Nov 16 16:04:02 (nightly isn't ran nightly) Nov 16 16:04:23 as you know that's just a build test, doesn't say anything about if it works, so i'm looking forward to your patches :) Nov 16 16:04:40 rburton_: Ok, I think thats fine since the volume of patches is low, is it pulling master-next? Nov 16 16:05:23 JPEW: the actual automated runs pull the relevant release branch. otherwise generally master unless told otherwise: i fired the last run manually and told it to pick up master-next explicitly Nov 16 16:06:41 rburton_: Ok, would it be sufficent then to notify you or RP when there are changes in master-next that need to be tested and you can pull them into the next build? Nov 16 16:07:03 JPEW: absolutely. Nov 16 16:07:15 rburton_: OK, that works for me, Thanks! Nov 16 16:15:46 rburton_, JPEW: we can run qa-extras separately too Nov 16 16:17:49 nrossi: ping... success Nov 16 16:20:22 OutBackDingo: success as in you got it booting and running the encrypted volume? :) Nov 16 16:22:44 * armpit watches JPEW slowly increasing his power Nov 16 16:23:37 * JPEW arches fingers... "excellent" Nov 16 16:25:29 nrossi: Yupp.... Nov 16 16:28:49 armpit: do I need to do some stable merged? Nov 16 16:28:51 merges Nov 16 16:31:23 stable/sumo-next is fine Nov 16 16:32:29 TP: thanks man!!!! bye! Nov 16 16:32:34 RP* Nov 16 16:33:17 armpit: merged, thanks Nov 16 17:00:47 rburton_, vte failed to build in mut.. need to bug it? Nov 16 17:01:59 http://errors.yoctoproject.org/Errors/Build/72139/ Nov 16 17:02:00 armpit: on it already Nov 16 17:02:11 armpit: I added 5 patches to thud-next Nov 16 17:02:12 also there is a warning on do_patch for dnf Nov 16 17:03:05 RP, k Nov 16 17:03:20 yeah on that too Nov 16 19:21:15 Evening all. Quick question about standard practice. I have a program that I would like to run periodically. I will trigger it with cron, no problem there, but it's written in go. Is the correct procedure to (cross) compile it myself, and provide the binary to the recipe, or should the recipe do the compilation itself? Nov 16 19:22:36 Im a little confused here, is the bitbake command available on the eSDK or not? Nov 16 21:01:47 la_croix_: why would you build it outside of bitbake? build it in a recipe along with everything else you ship Nov 16 21:02:36 rburton_ No reason, really, I'm just asking what standard practice is. So I just install go on the build machine and build it in the recipe? Nov 16 21:02:51 la_croix_: use meta-go to get a go cross compiler Nov 16 21:04:20 standard practise is that your layer builds *everything* from sources in a single blast, so you can have *all* the build steps in one place Nov 16 21:04:28 rburton_ Does this not work in regular go? I saw this: env GOOS=linux GOARCH=arm64 go build foo Nov 16 21:04:31 no insert magic binary built using instructions which have got lot Nov 16 21:04:38 la_croix_: no idea, never used go Nov 16 21:04:43 rburton_ That makes sense, thank you Nov 16 21:06:14 er, 'got lost', but you see the point Nov 16 21:06:24 that's the ethos anyway Nov 16 21:07:24 rburton_ Absolutely. Nov 16 21:07:37 rburton_ Never used go myself, actually. This just seems like a decent opportunity to learn it **** ENDING LOGGING AT Sat Nov 17 03:00:00 2018