**** BEGIN LOGGING AT Wed May 03 03:00:01 2017 May 03 04:25:11 Hi All, May 03 04:25:21 is there any way to add layers in local.conf ? May 03 04:25:54 i had a limitation of editing bbalyers.conf ? May 03 04:51:24 vineethchowdhary: no, local.conf is parsed via inclusion from bitbake.conf, and bitbake.conf is parsed after the layers are (and has to be, since bitbake.conf itself is in one of the layers) May 03 04:54:12 kergoth: is there any documentaion of how this parsing happens ?. May 03 04:54:33 can you point to it ? May 03 04:54:52 vineethchowdhary: http://www.aosabook.org/en/yocto.html May 03 04:55:36 kergoth : Thank you May 03 06:46:25 rburton1: you do need to relocate rpm, yeah - look in rpm recipe how it's done for rpm binaries May 03 07:18:14 Hello! Anyone here using the meta-raspberry layer? I'm trying to build for arm64 and I'm getting this: https://paste.kde.org/pvex7wv4x/oeggyq. Any idea why this is happening? It seems those libs coming from the userspace package are not added to the sysroot for some reason... May 03 07:19:13 luc4: This paste is password protected May 03 07:20:03 MarcWel: ah thanks, https://pastebin.com/pL2mei9s May 03 07:38:16 hello, can Yocto generated SDKs via populate_sdk support building qt5 GUI apps with cmake for cross-compilation instead of qmake? May 03 07:47:48 you need a cros qmake for cross platform May 03 07:48:28 i have a inherit populate_sdk_qt5 in my .bb file for qt cross platform. May 03 08:05:30 Looking in image.bbclass it contains "addtask rootfs before do_build" and then later "addtask do_image after do_rootfs before do_build". How come the former does not spell out as do_rootfs? Are they two different tasks? May 03 08:08:58 MarcWel: so cross-compiling qt applications with cmake is not supported with Yocto-generated SDKs at this point? May 03 08:33:01 Hi, I am using autobuilder but I don't get prserv to work (every revision is +git0). It seems there are two instances of prserv running, one global started by autobuilder and one started during build (yocto-worker/.../build/build/cache/prserv.sqlite3). The second seems to be used and the database is replaced each build as it seems. Any ideas? May 03 08:34:04 eduardas_m: i'm not realy sure but if you add: inherit populate_sdk_qt5 to the .bb file you are using to genarate the sdk. it wil genarate a sdk with qt support May 03 08:34:59 MarcWel: I am aware of that, but that only involves qmake and not cmake May 03 08:36:25 MarcWel: my point is this... I can compile a qt5 gui project with cmake on desktop Linux, but I can not do the same with a Yocto SDK for embedded May 03 08:58:23 eduardas_m: did you use the qtcreator.sh May 03 08:58:51 to start qt and set the environment-setup*** as sourche in that file ? May 03 09:02:25 does anyone have a better answer to this question than "just fetch universe": http://stackoverflow.com/questions/40730922/yocto-fetchall-and-populate-sdk ? May 03 09:04:54 kanavin: so an overnight build here failed, error: unpacking of archive failed on file /usr/src/debug/mesa/2_17.0.2-r0/mesa-17.0.2/src/mesa/drivers/dri/i965/brw_sync.c;59091a69: cpio: chown failed - Inappropriate ioctl for device May 03 09:04:56 any idea? May 03 09:22:34 khem: https://autobuilder.yoctoproject.org/main/tgrid May 03 09:27:26 rburton1: no idea, do you have one of my commits in mind? May 03 09:27:54 khem: oh actually not that bad. elfutils because i forgot to use master-next of meta-gpl2. linux-yocto 4.1 still. nativesdk-mingw-w64-runtime for no idea. May 03 09:28:05 kanavin: no, just wondering if you'd seen it before, as its from dnf May 03 09:29:10 rburton1: no, I did not see this before - why is it unpacking to /usr/src/debug? May 03 09:31:24 kanavin: i assumed that was before relocation May 03 09:32:44 Is it easy to make an image on sdcard if it wasn't natively supported in the recipes ? May 03 09:32:53 thanks by advance =) May 03 09:33:55 ChrysD: image format is unrelated to recipes, the recipes generate pacakges. the image classes turn packages into images. May 03 09:34:11 MarcWel: yes, I am aware of all those... those are the basics as described in most tutorials May 03 09:34:41 rburton1 : I mean like if I had IMAGE_FSTYPES ="sdcard" , it doesn't work because IMAGE_CMD isn't set by the project I work with. May 03 11:09:07 Hi. How to add the capability of having a sdcard image build from bitbake ? IMAGE_FSTYPE="sdcard" doesn't work as IMAGE_CMD isn't set. Thanks. May 03 11:18:11 ChrysD: i *think* the sdcard image type is a meta-raspberrypi thing May 03 11:18:22 so what MACHINE are you using? May 03 11:18:46 rburton1 : With phytec, they have an sdcard image. But now i'm using atmel sama5d4-xplained May 03 11:20:16 ChrysD: you can probably just use the standard wic images May 03 11:20:27 afaik, the rpi sdimage type is rpi-specific May 03 11:20:45 rburton1 : Yeah for rpi the name isn't sdcard but another one. May 03 11:21:35 rburton1 : Wic can be mounted easly in sdcard using dd if = ? May 03 11:25:32 rburton1 : apparently yes. Thanks. May 03 11:28:30 Is there a way to force installation of a (deb) package into an image? I've deliberately excluded some packages that this package depend on May 03 11:29:15 sveinse: you want to install foo but not bar, where foo depends on bar? May 03 11:30:04 you're asking for the ability to break dependencies, so obviously that's not trivial :) May 03 11:30:15 can't you append or change the recipe to remove those dependencies somehow? May 03 11:30:20 split up, config option, etc May 03 11:31:13 rburton1: yes. I know it sounds weird, I'm packaging a USB install image with some tools, but it does not need libc and stuff in it, since it runs on an existing system May 03 11:31:56 have a dummy package that provides those things? May 03 11:32:00 I had hoped I could use the image.bbclass as base, as it is very convenient to collect packages to include this way May 03 11:32:29 you'll have *a lot* of fun if the dummy package accidently sneaks into your normal build May 03 11:33:00 exactly May 03 11:33:46 The other approach is to let image install libc and friends, and then in postprocess remove all the extra spank May 03 11:34:44 i think meta-intel does fun with package architecture so it can opt-in to specific packages if required May 03 11:35:45 yeah it defines a new package architecture May 03 11:36:24 you can probably give your dummy package an arch like noarch-dummy and then add noarch-dummy to PACKAGE_EXTRA_ARCHS in your image recipe? May 03 11:37:36 yeah, perhaps that'll work May 03 11:56:26 hello May 03 11:58:10 I have a layer that defines a new machine, and I have to change some stuff for uboot (the .bb is provided by another layer). The ideal way is to just create a uboot.bbappend and add my modifications ? May 03 11:58:54 In the uboot.bb there are stuff like SRC_BRANCH_machine = ; so in my layer I'd have to do SRC_BRANCH_mymachine =, right ? May 03 12:14:31 zeddii: can you backport whatever fix was needed for gcc7 to the 4.1 kernels please? May 03 12:14:41 zeddii: (or do i just need to bump srcrev) May 03 13:17:50 join #oe-meeting May 03 14:22:44 Is it possible to call a python function from within a shell function? May 03 14:35:18 sveinse: no May 03 14:35:30 sveinse: shell functions are executed by writing a shell script and running bah May 03 14:35:31 bash May 03 14:35:42 so no, they can't invoke python functions May 03 15:01:12 Well.. Depends on how complex your python functions are.. May 03 15:01:22 python -c "import time;print time.time()" May 03 15:01:42 presumably he means a function defined in bitbake metadata, given the context May 03 15:01:43 * kergoth yawns May 03 15:04:13 Sorry, should have read my buffer more carefully May 03 15:05:48 you had a good point, just not sure if it applies here or not :) May 03 15:05:50 morning all May 03 15:06:08 morning :) May 03 15:09:50 zeddii: around? May 03 15:19:26 rburton1, I am now. was AFK. May 03 15:19:54 zeddii: gcc7 and kernel 4.1. should it work if i bump srcrevs in oe-core, or does a patch need backporting? May 03 15:20:46 I need to do some integration work. May 03 15:20:56 I've held off on it. do we want it for the release ? May 03 15:22:10 zeddii: no but its blocking the gcc7 merge, and is the major build failure left May 03 15:22:28 obviously we're not ready to merge it yet so it's not urgent but it is a blocker May 03 15:24:41 rburton1, gotcha. May 03 15:25:06 is there a cut & paste local.conf change that I can do to start a gcc7 build ? I can fire it up in the background and do some porting May 03 15:25:46 zeddii: grab ross/gcc7 from poky-contrib May 03 15:26:25 zeddii: see http://errors.yoctoproject.org/Errors/Latest/Autobuilder/?filter=fec6022db098cbbfa03a47e7d77172b4b9642672&type=commit for the specific version/machines May 03 15:26:52 interestingly its not all poky-lsb machines that fail May 03 16:00:37 rburton1, ack'd. will do. May 03 16:00:52 zeddii: merci May 03 16:27:09 I'm setting IMAGE_OVERHEAD_FACTOR="1.0" and IMAGE_ROOTFS_EXTRA_SPACE="0", but still my file system has 72M (approx 20% disk space) available. How can I shrink it even further? May 03 16:41:58 sveinse: how do you measure the free space? May 03 16:45:48 jku, df on target May 03 16:47:16 Can someone please explain backfilling? The term makes no sense to me, so the mans circular reference is of little help unfortunately: "Thus, the OpenEmbedded build system has a mechanism to automatically "backfill" these added features into existing distro or machine configurations." May 03 16:47:34 Is is to remove or to add features? May 03 16:48:14 backfilling is adding distro features by default as they're added in recent releases so people upgrading will get broken systems May 03 16:48:45 like sysvinit as a distro feature is relatively new, so its backfilled by default as otherwise people setting DISTRO_FEATURES and upgrading won't get an init system May 03 16:48:57 if you don't want it, set BACKFILL_CONSIDERED to stop it being added May 03 16:49:36 rburton1: ok, thanks. No, what I want is to remove some features May 03 16:50:24 So MACHINE_remove = perhaps then? May 03 18:36:41 is there a devtool subcommand to remove the workspace and cleanup bblayers.conf after itself? May 03 18:56:02 denix: I do not think so, the closest is devtool reset and bitbake-layers remove-layers May 03 18:57:07 lsandov: thanks. I did reset and was hoping it would do layer removal on its own. will use bitbake-layers, thanks May 03 18:57:08 denix: but that would be useful do the nature of the workspace May 03 18:57:34 np May 03 19:42:21 How do I disable Toaster so I can start a bitbake without waiting for the UI May 03 19:46:20 just toss frozen bagels in it and jam the lever down? May 03 19:46:25 ... i probably misread that nevermind May 03 19:50:17 For some reason I cannot start a bitbake from the command line now. It just waits for UI events or something May 03 19:55:10 Nevermind, I figured it out. Apparently you can type "source toaster stop" and it....stops May 03 19:56:03 https://www.theverge.com/2017/5/3/15534768/google-docs-phishing-attack-share-this-document-with-you-spam May 03 20:32:06 Does anyone use the crops/poky docker? Should pokyuser have sudo? It appears that sudo is being set up, but it asks for a password and it does not appear that account has a password configured. May 03 20:54:02 I am trying meta-java (morty) and I get ERROR: ParseError at /home/giuseppe/research/projects/zynq/yocto/meta-java/recipes-core/jamvm/jamvm.inc:19: Could not inherit file classes/relative_symlinks.bbclass May 03 20:54:20 do you have any guesses about the reason of this problem? May 03 20:58:39 I am trying meta-java (morty) and I get ERROR: ParseError at /home/giuseppe/research/projects/zynq/yocto/meta-java/recipes-core/jamvm/jamvm.inc:19: Could not inherit file classes/relative_symlinks.bbclass openembedded-core but not in morty May 03 21:01:07 gdg: I don't see relative_symlinks.bbclass in OE-core's morty branch May 03 21:01:23 gdg: checkout morty branch of meta-java May 03 21:01:52 it sounds like you're trying to use meta-java master with poky/oe-core morty May 03 21:02:24 I am in morty of meta-java May 03 21:02:40 I am trying meta-java (morty) and I get ERROR: ParseError at /home/giuseppe/research/projects/zynq/yocto/meta-java/recipes-core/jamvm/jamvm.inc:19: Could not inherit file classes/relative_symlinks.bbclass openembedded-core but not in morty May 03 21:02:54 (sorry double post) May 03 21:04:06 I have meta-openembedded and openembedded-core at morty May 03 21:26:36 gdg: hmm, it seems like a patch has been merged to the meta-java morty branch that should not have been May 03 21:26:46 I see May 03 21:27:11 should I rollback to any specific rev? May 03 21:28:40 gdg: that would be the workaround for the moment May 03 21:28:44 you could try 2ca320b5740dc0620661561cb3394ba41b375e0c May 03 21:28:57 since most of the preceding commits I glanced over look OK for morty May 03 21:29:51 I checked out that 2ca32 and it seems to pass the dependency issues May 03 21:33:54 I have just sent an email to the maintainer FYI May 03 22:00:56 Should I be worried by this WARNINGs May 03 22:01:13 WARNING: /home/giuseppe/research/projects/zynq/yocto/meta-java/recipes-core/openjdk/openjdk-8-native_102b14.bb: Unable to export ${CXXFLAGS}: Failure expanding variable CXXFLAGS, expression was -isystem/home/giuseppe/research/projects/zynq/yocto/build/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -D_GLIBCXX_USE_CXX11_ABI=0 ${@version_specific_cfl May 03 22:01:14 ags(d)} ${@jdk_cpp_options(d)} which triggered exception IndexError: string index out of range May 03 22:05:56 I'm not sure, but it's clearly broken... May 03 22:12:11 much more after some time I get this error May 03 22:12:41 | WARNING: /home/giuseppe/research/projects/zynq/yocto/build/tmp/work/x86_64-linux/classpath-native/0.99-r6.0/temp/run.do_configure.23769:1 exit 1 from 'exit 1' May 03 22:12:41 | ERROR: Function failed: do_configure (log file is located at /home/giuseppe/research/projects/zynq/yocto/build/tmp/work/x86_64-linux/classpath-native/0.99-r6.0/temp/log.do_configure.23769) May 03 22:12:41 ERROR: Task (/home/giuseppe/research/projects/zynq/yocto/meta-java/recipes-core/classpath/classpath-native_0.99.bb:do_configure) failed with exit code '1' May 03 22:12:41 checking if /home/giuseppe/research/projects/zynq/yocto/build/tmp/sysroots/x86_64-linux/usr/bin/ecj-initial works... configure: error: The Java compiler /home/giuseppe/research/projects/zynq/yocto/build/tmp/sysroots/x86_64-linux/usr/bin/ecj-initial failed (see config.log, check the CLASSPATH?) **** ENDING LOGGING AT Thu May 04 03:00:03 2017