**** BEGIN LOGGING AT Fri Mar 24 03:00:00 2017 Mar 24 06:40:38 I'm still trying to get SGX drivers work. I got weston compiled with patches from meta-arago etc. As I need to run qt app, I've selected qtwayland. Qtwayland build fails because x11 is removed from DISTRO_FEATURES. I think, I hit this very problem that is solved in Qt upstream: https://codereview.qt-project.org/#/c/187132/. Is there any idea how to move further? The patch isn't in meta-qt5 yet :-( Mar 24 06:41:41 it's libxkbcommon that is the problem. I think it is possible to have is without all the X stuff, but then I need to .bbappend a dependency in libxkbcommon so it builds prior to qtwayland Mar 24 06:53:19 error: undefined reference to 'xkb_keysym_to_utf32' Mar 24 06:53:20 :-( Mar 24 07:26:58 we'll, there's libxkbcommon depend in qtwayland, but somehow the linker doesn't include the lib Mar 24 08:09:51 oh, i see https://patchwork.openembedded.org/patch/136744/ Mar 24 08:23:42 I'm wondering about occasional very long build times on autobuilders... looking at e.g. https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/225 Mar 24 08:24:00 jku: They're caused by fetch issues and slow clones onto NFS Mar 24 08:24:16 oh right, I remember you discussed that Mar 24 08:24:26 jku: joshua has been looking into it Mar 24 08:24:34 didn't realize it was that bad Mar 24 08:24:42 jku: its bad :( Mar 24 08:36:03 RP: I'm sure you've also seen test_devtool_virtual_kernel_modify take forever? Should I file a bug on that or is that likely to have the same root causes? Mar 24 08:38:08 (forever meaning over 4 hours) Mar 24 08:51:21 there's a handful of other tests that take a very long time, even ones that don't seem like they should... I think I'll file bugs, we can close them if the times turn out to be 'reasonable' Mar 24 09:07:40 jku: its the same issue - kernel clone problem Mar 24 09:07:58 jku: the other ones may warrant further attention though Mar 24 09:08:12 jku: I'm already poking at the clone issue Mar 24 09:08:36 yeah I've found some filed issues already , I'll file a couple of new ones Mar 24 09:24:08 jku: the failures on the main ab are worrying, particularly as they're around kernel sources Mar 24 09:24:21 ed probably needs to look at https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/854/steps/Running%20oe-selftest/logs/stdio :/ Mar 24 09:25:58 oops I didn't notice those. Just admired the green on new cluster... I'll try and triage Mar 24 09:39:13 jku: thanks. Both builds are near enough the same revision so the differing results are worrying :( Mar 24 09:41:23 Hi there ! I was wondering why yocto is using the installed gcc (my machine has gcc6 but the target I am compiling for will have gcc 4.9) ? It semmes like yocto is using local host gcc to build its host tools, and not compiling its own gcc for these too ? Mar 24 09:41:34 is it possible, maybe, to force this ? Mar 24 10:24:22 jmleo: the system will use your gcc to build a gcc-cross for the target, then use that gcc-cross to build for the target Mar 24 10:24:41 RP, could it use its own gcc instead ? Mar 24 10:24:53 jmleo: what would you build that gcc with? Mar 24 10:24:54 which would be distro independant btw Mar 24 10:25:12 RP, download a precompiled Mar 24 10:25:21 it may be stupid though Mar 24 10:25:37 jmleo: we do have build appliance images which contain all the tools needed to build Mar 24 10:25:47 jmleo: in general we've not found it necessary Mar 24 10:25:56 RP, how can I use it ? Mar 24 10:26:22 jmleo: another option are the containers we have, you could build in one of those Mar 24 10:26:52 RP, I'll have a look... I thought something like docker could have been a solution :) Mar 24 10:27:34 jmleo: http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.1/build-appliance/ are the build-appliance images from the last point release Mar 24 10:28:04 jmleo: there are lots of different ways of addressing this, it just depends what you need to do Mar 24 10:32:14 RP, I need to compile an old yocto (poky) on a modern distrib :D Mar 24 10:32:46 jmleo: depending on how old that is, you may be better off on a older distro Mar 24 10:33:39 RP, yes, sounds like it but I don't want to do that... Mar 24 10:41:02 I had built weston/qtwayland/sgx-drivers from meta-ti. When I start weston with -B drm-backend.so the screen hangs with "initializing drm backend" as the last line. How do I debug it? Mar 24 10:46:44 libgbm.so.2 is used everywhere Mar 24 10:48:37 hi. anyone using meta-raspberrypi, on morty? Mar 24 10:49:49 i'm having a problem with the kernel: there's no matching commit for the hash specified in SRCREV Mar 24 11:22:53 :-( still hanging on "initializing drm backend". I guess I need to deal with all usb_gadget BBB stuff to read possible logs remotely as the screen becomes inaccessible Mar 24 11:26:44 Ok so I'm getting this error when building runtimes on aarch64 host: https://gnome1.codethink.co.uk//logs/build-2017-03-24-102001/build-freedesktop-sdk-base-aarch64.txt Mar 24 11:27:08 It would seem that, libjpeg-turbo received an *unconditional* dependency on nasm-native Mar 24 11:29:13 This is what I had done, when we were building libjpeg-turbo in our own layer, to support the aarch64/arm builds: https://github.com/flatpak/freedesktop-sdk-base/commit/a576b1bdaf1d689cee1f93152e4370eb27ae731f Mar 24 11:29:54 seems that when it appeared in recipies-graphics, it came with unconditional dep: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-graphics/jpeg/libjpeg-turbo_1.5.0.bb?h=morty Mar 24 11:47:57 Ok so, I guess I have to do two things... file a bug + patch to make nasm-native arch conditional, and in the meantime, is there a way I can override the way libjpeg-turbo depends on nasm-native in my own layer ? Mar 24 12:06:08 gtristan: a .bbappend in your layer should work fine (and yes, please send a patch) Mar 24 12:09:24 jku, I'm trying to work out how I would do that, I guess I would just set 'DEPENDS =' in the .bbappend to first wipe out the depends list, and then do my DEPENDS_append_{arch} lines after that ? Mar 24 12:10:25 also, in our older custom layer, we only cared about x86 and x86-64 (because we really only cared about two intel arches) Mar 24 12:10:52 If I want to submit a proper patch, I suppose I would want something different, which would just capture every intel arch no ? Mar 24 12:13:46 gtristan: actually now that I think about it... does that even work? you want to modify DEPENDS based on _native_ arch... Mar 24 12:14:00 DEPENDS_remove_aarch64 = "nasm-native" ? Mar 24 12:14:21 remove could work indeed (/me didnt know about remove) Mar 24 12:14:36 it's super nice and semi-recent Mar 24 12:14:38 joshuagl: but doesn't that work based on target arch? Mar 24 12:14:42 yeah that's target Mar 24 12:14:48 jku, I can attest to it having worked in the past yes, but we always use a host compatible arch to build Mar 24 12:14:56 oh sorry, I didn't fully digest the backlog Mar 24 12:15:55 So in that case, I had fixed it for our use case, but the /correct/ way is to case the host arch, how would I do that ? Mar 24 12:16:20 what about a HACK like a DEPENDS_remove = "${@some_host_arch_wrangling()}" ? Mar 24 12:16:27 (i.e. was fixed because we always use aarch64 to build for arm targets) Mar 24 12:17:11 somewhat inspired by: meta/recipes-devtools/qemu/qemu.inc:PACKAGECONFIG_class-native_remove = "${@'kvm' if not os.path.exists('/usr/include/linux/kvm.h') else ''}" Mar 24 12:17:50 i think there might be a host override, one sec Mar 24 12:18:53 no, maybe not Mar 24 12:19:22 yeah vile hack like josh said would work Mar 24 12:19:33 i missed the original context, whats the problem? Mar 24 12:19:52 rburton, one sec, few links will clear it up... Mar 24 12:19:55 rburton libjpeg-turbo uses nasm-native Mar 24 12:20:15 which is x86* only I guess Mar 24 12:20:15 rburton, this is what I had before in our custom layer: https://github.com/flatpak/freedesktop-sdk-base/commit/a576b1bdaf1d689cee1f93152e4370eb27ae731f Mar 24 12:20:32 to build libjpeg-turbo for arm/aarch64 on aarch64 host Mar 24 12:20:37 hm Mar 24 12:20:55 now libjpeg-turbo appeared in recipies-graphics with: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-graphics/jpeg/libjpeg-turbo_1.5.0.bb?h=morty Mar 24 12:20:57 no condition Mar 24 12:21:32 Appears like only cross intel -> aarch64 is working, but not host aarch64 Mar 24 12:21:53 rburton: fyi, I filed some bugs on your mut build as they looked scary enough. If they're not relevant let me know Mar 24 12:22:02 presumably nasm is only actually needed by jpeg when its targetting x86 Mar 24 12:22:34 so that change looks right? Mar 24 12:23:01 True, so is it possible even to target x86 on an aarch64 build machine ? Mar 24 12:23:04 jku: yeah thanks for that Mar 24 12:23:30 gtristan: indeed, the next question is can a aarch64 build a nasm-native that works. you'd expect so. Mar 24 12:23:50 i lost my aarch64 vm from linaro Mar 24 12:25:11 could anyone please review my weston startup log on SGX/BeagleBone Black? http://pastebin.com/sA9QtpVm . What's wrong with it? Mar 24 12:28:16 gtristan: https://packages.debian.org/sid/nasm suggests that nasm builds on all platforms, so we just need to have target specific overrides on DEPENDS Mar 24 12:32:37 rburton, ok going to lunch now, I'll try to cook up a patch this afternoon Mar 24 12:33:43 ok, --current-mode for weston seemed to work :-D Mar 24 12:39:37 ed2: thanks for the quick patch, respinning selftest now Mar 24 12:44:21 I piece of software produces and .so file that is needed for the -dev package only, but putting it in FILES_${PN}-dev fails with the message: "QA Issue: -dev package contains non-symlink .so" Mar 24 12:45:05 Can I somehow force it to accept it in that variable? Or have I simply misunderstood the purpose of it? Mar 24 13:06:29 Hi all. I would like to know if there is a way to compile G++ for the target (armhf). I didn't find any recipe for it. Mar 24 13:08:40 Maximusk, It's included in gcc, so simply installing that should suffice Mar 24 13:09:35 Well, I did it, but when I use GCC on the target, it's working, but not when I use G++ Mar 24 13:09:51 (g++ : command not found Mar 24 13:24:09 'OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Broader Use with Other FOSS Projects and Products' Mar 24 13:24:11 :O Mar 24 13:24:36 it did sound like they have a non-standard license at the moment Mar 24 13:26:08 Hello, i have a recipe which use a EXTERNAL Source : INHERIT += "externalsrc" EXTERNALSRC = pathToSrc, the problem is that when i want to build this recipe the first time, it delte all files in this directory. As Build tool I'm using cmake. Do you know this problem or have a solution how I can solve this ? Mar 24 13:28:42 Crofton|work: the current license is a disaster Mar 24 13:29:20 I'd be all angry if just changing to permissive for no good reason, but can deal with this Mar 24 13:33:14 Hunk: that sounds like a nasty bug. Can you share the whole recipe and do you know where during the build the files are deleted? Mar 24 13:36:17 jku: Mar 24 13:36:18 DESCRIPTION = "Desc" SECTION = "devel" LICENSE = "MIT" LIC_FILES_CHKSUM = "" DEPENDS = "" INHERIT += "externalsrc" EXTERNALSRC = "${THISDIR}/../../../../src" S = "${EXTERNALSRC}/project" inherit catkin Mar 24 13:36:43 catkin is using cmake Mar 24 13:37:13 How I can check in which when the build deletes the files ? Mar 24 13:38:13 not an expert on externalsrc but I don't think you should be setting S Mar 24 13:38:39 I DO Mar 24 13:38:48 S = "${EXTERNALSRC}/project" Mar 24 13:38:50 sry for caps Mar 24 13:39:17 oh missread Mar 24 13:39:20 i will test it Mar 24 13:40:26 also you probably want to set EXTERNALSRC to a hard coded path, not depend on THISDIR Mar 24 13:40:48 I mean an absolute path Mar 24 13:41:42 hm ok but a hardcoded absolut path is not good ;) I want to share the project with other developer Mar 24 13:44:40 Hunk: well that's more of a feature of externalsrc... if you want things to "just work", put the code in git and don't use externalsrc, right? Mar 24 13:48:48 jku that was my first intension Mar 24 13:48:58 but i have a huge git project with a lot of submodules Mar 24 13:49:42 for that I have to use gitsm: but gitsm does not support symlink it copies everytime the full git repo for every recipe Mar 24 13:51:53 which takes really long Mar 24 13:52:02 copying ( 2 mins ) Mar 24 14:16:11 ed2: why does test_qemu_efi(self) in meta/lib/oeqa/selftest/wic.py assert that commands exit with 1 as return code? For example: Mar 24 14:16:11 cmd = "grep vda. /proc/partitions |wc -l" Mar 24 14:16:11 status, output = qemu.run_serial(cmd) Mar 24 14:16:11 self.assertEqual(1, status, 'Failed to run command "%s": %s' % (cmd, output)) Mar 24 14:16:23 Shouldn't that be assertEqual(0, status)? Mar 24 14:19:57 pohly: probably a typo. I'll look at it. thanks for pointing out. Mar 24 14:20:50 Well, it seems to work, but that's probably a problem elsewhere. Mar 24 14:21:28 Like not actually finding the actual status. Mar 24 14:36:08 ed2: RP: last oe-selftest run failed in Wic.test_systemd_bootdisk Mar 24 14:36:11 https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/227/steps/Running%20oe-selftest/logs/stdio Mar 24 14:36:44 joshuagl: patch already in mut Mar 24 14:36:59 great! Mar 24 14:44:24 is yocto support provided in this channel? Mar 24 14:44:53 just ask the question Mar 24 14:46:18 I'm looking for a way to force a recipe to be executed everytime (i.e. don't cache sstate) Mar 24 14:46:29 pohly: it looks like run_serial returns 1 on success Mar 24 14:46:43 pohly: don't ask me why :) Mar 24 14:46:52 ed2: but I do ask you ;-} Mar 24 14:47:08 wic.py is almost the only user of run_serial. Mar 24 14:47:43 grep -r run_serial ../meta/lib/ |wc -l Mar 24 14:47:43 17 Mar 24 14:47:58 My situation is I have a recipe which generates files destined for the rootfs but I need to guarantee these files are generated at the time of build and not stale Mar 24 14:48:05 That includes the implementations. Mar 24 14:48:38 As far as actual tests are concerned, I think wic.py is the only user. Mar 24 14:49:22 pohly: it was there when I started to use it. Who knows where else it's used. I'd not touch it. Mar 24 14:50:28 I'll file a bug. I think run_serial() is broken. runqemu.py uses echo $? to get the status of the command and tries to get value. Mar 24 14:50:40 So the result should be 0 for successful commands, not 1. Mar 24 14:50:57 pohly: look further. if it gets '0' it returns 1. Mar 24 14:51:34 Hmm, right. How weird. Mar 24 14:51:53 yep, it's weird by design :) Mar 24 14:52:08 dctrvenkman, what is the input for the generated files? Mar 24 14:53:37 pohly: i can only guess, but probably it was designed to be used like this: if run_serial(): echo 'success' Mar 24 14:53:40 The current use is to generate a file with the contents of a 'git describe' command Mar 24 14:54:33 This allows me to track in the final image the working tree state that the build was generated from Mar 24 14:54:57 dctrvenkman: probably easier to do that in a rootfs postprocess hook Mar 24 14:55:23 it looks like do_rootfs is the only task Mar 24 14:55:40 how would I hook into it between the create_rootfs and create_image calls Mar 24 14:57:30 I've investigated this approach but didn't see an easy way Mar 24 14:58:42 do_rootfs appears to install the packages into the staging rootfs and generate the image all in one task Mar 24 15:06:59 dctrvenkman: use ROOTFS_POSTPROCESS_COMMAND, which is explicitly after rootfs construction but before image construction, as rburton suggested Mar 24 15:09:13 kergoth: thanks I will give this a try Mar 24 15:24:55 verified ROOTFS_POSTPROCESS_COMMAND does exactly what I need. Thanks all. Mar 24 15:28:32 How do I skip qwebkit from bitbaking meta-toolchain-qt5? Mar 24 15:30:24 as a follow up, out of curiosity why was the choice made to provide this functionality through variable definitions versus say splitting the task and allowing functionality to be shimmed in using the existing addtask feature? Mar 24 15:31:48 dctrvenkman: the task *is* split in the current version Mar 24 15:31:58 each image type has its own task, and do_rootfs only constructs the rootfs Mar 24 15:39:55 so this has changed in a later version? On my version I only ever see the do_bootimg, populate_lic, and do_rootfs tasks being run Mar 24 15:41:31 yes, as i said Mar 24 15:42:25 alright well thats good to know when/if we ever move to the latest release. thanks Mar 24 15:44:00 * I just used bitbake do_populate_sdk instead and it went ok as there is no qwebkit used in my image Mar 24 15:49:11 rburton, so here is a patch which should work, I'm only unsure if 'x86' and 'x86-64' captures all the targets which are intel Mar 24 15:49:13 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11240 Mar 24 15:49:14 Bug 11240: normal, Undecided, ---, ross.burton, NEW , libjpeg-turbo fails to build for aarch64/arm targets on aarch64 host Mar 24 15:49:22 Also, hope I filed this in the right place :) Mar 24 15:50:40 hi, I think I have an issue where two different recipes have the same name for their source tar.gz archive, so I think one replaces the second one in the downloads Mar 24 15:50:51 seems it was assigned to rburton, must be the right place then :) Mar 24 15:51:50 is there a way to specify the name to which the archive is saved to Mar 24 15:52:32 or do I just have to find a different mirror / source Mar 24 15:56:53 gtristan: thats good, but patches to the list please. openembedded-core@lists.openembedded.org. Mar 24 16:01:04 oh /me forgot about that, perhaps I unsubscribed Mar 24 16:01:16 i think you can join as post-only Mar 24 16:43:36 no, not done this correctly yet :-( how do I omit building qwebkit from "inherit populate_sdk_qt5" in my image .bb and bitbake -c populate_sdk? Mar 24 16:45:49 and from meta-toolchain-qt5 alike Mar 24 19:39:54 I made a recipe to build baresip (SIP client: https://github.com/alfredh/baresip) as well as its dependencies libre and librem. Would it make sense to submit this as a new, separate layer, or to contribute to an existing layer? Mar 24 19:41:15 hello Mar 24 19:41:55 I need to execute the git command at the build time Mar 24 19:42:56 but when I am using the find_package(Git), it would tell me "Could NOT find Git (missing: GIT_EXECUTABLE) " Mar 24 19:43:12 I do just the git at host, what is wrong with that? Mar 24 20:06:27 anybody try to install geany-plugins lately? Mar 24 20:07:21 i got it to build with a sed hack but the plugin packages have install/depend issues during do_rootfs Mar 24 20:08:58 i see run.set_metapkg_rdepends build artifacts for gst-plugins but nothing for geany-plugins Mar 24 22:08:10 so, turns out one plugin is failing silently and dorking up the whole install Mar 24 22:26:07 and using the right .m4 file from sysroot (instead of the old crufty failing one) fixes it... **** ENDING LOGGING AT Sat Mar 25 03:00:02 2017