**** BEGIN LOGGING AT Mon Sep 04 03:00:00 2017 Sep 04 07:07:49 good morning Sep 04 07:20:08 mckoan, good morning Sep 04 10:20:48 hello, something like SRC_URI = "git://~/faustas_git/custom_swupdate.git;protocol=file;branch=faustas" does not work... I want ~ to be replaced with the current user's home folder path? how do I achieve that in a bitbake recipe? Sep 04 10:22:22 does bitbake have a variable for the name of the current user that runs it? that would probably also do Sep 04 10:47:23 eduardas_m: that sounds like something you shouldn't need to do... What problem is that solving? Sep 04 11:23:18 Hi, I'm trying to build some tools needed during build inside the Yocto SDK. The problem is that I want to use the nativesdk gcc toolchain to build binaries (for source code generation) for use inside the SDK. I can't get x86_64-pokysdk-g++ to compile anything. It uses the hosts sysroot which have an incompatible linker. Tried setting --sysroot=${OECORE_NATIVE_SYSROOT}, which helps somewhat, but it still can't find c++ std lib includes Sep 04 11:23:31 jku: to be honest, me and my colleagues don't have infrastructure for a proper git server setup right now, so we use samba shares mounted in home folder to access our git repositories Sep 04 11:24:21 I am aware that is not a very proper way of doing things, but a temporary solution is necessary Sep 04 11:26:06 apparently something like SRC_URI = "git:///home/${USER}/faustas_git/custom_swupdate.git;protocol=file;branch=faustas" works...i.e. bitbake sees the environment variables, so things should work out if the mount points are named the same in the home folder on each machine Sep 04 11:58:43 Dear All, Sep 04 11:59:01 Is there a way to specify -p option to quilt (when it applies patches)? Sep 04 11:59:21 yes pnum in the URL Sep 04 12:00:43 rburton :-) Sep 04 12:00:48 I will check that :) Sep 04 12:01:02 erm striplevel even Sep 04 12:01:06 pnum was deprecated Sep 04 12:01:13 http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-SRC_URI Sep 04 12:15:11 rburton: Thanks, it works :) Sep 04 12:41:04 can anyone tell me what is the proper procedure of adding kernel image and dtb to the rootfs when I do not wish to have a separate boot partition? Sep 04 13:18:23 hello Sep 04 13:18:59 what am i doing wrong is my images are much bigger when building multiple targets on a single bitbake run Sep 04 13:25:16 hmm, apparently the u-boot my yocto is building doesn't have support for mtd or ubifs. is there a way to enable these features? online documentation says they should be in u-boot since 2015 Sep 04 13:48:22 peacememories: since u-boot is configured via menuconfig, I would expect a .bbappend with config fragments or a full defconfig override to work Sep 04 13:49:08 just looked into the u-boot readme and apparently mtd support is enabled by two cflags. i'm not sure how best to inject them into the build process though^^' Sep 04 13:51:50 peacememories: http://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html#changing-the-configuration Sep 04 13:52:37 as far as I understand configuration fragments can be applied not just to the kernel, but also u-boot, busybox and anything else that uses menuconfig Sep 04 13:52:50 thanks a lot :) Sep 04 13:53:06 I was successful in using this mechanism with busybox for example Sep 04 13:55:09 peacememories: no problem... my colleague prefers a full defconfig override though... I suppose that is a matter of taste Sep 04 13:57:59 do these defconfig appends only work with menuconfig based recipes? because running `bitbake -c menuconfig u-boot` doesn't seem to work, with to me indicates that it's not a menuconfig project Sep 04 13:58:20 If I may add my 2$ Sep 04 13:58:40 Why in OE recipies I must have the "whole" defconfig (corresponding to .config) Sep 04 13:58:59 and it doesn't work with arch/arm/config files which are created with savedefconfig ? Sep 04 14:01:47 peacememories: u-boot is certainly configured with menuconfig... -c menuconfig does not work for me either via yocto for some reason Sep 04 14:02:18 which is certainly weird Sep 04 14:03:24 probably a bug in the recipe then? Sep 04 14:03:44 bitbake busybox -c menuconfig works though Sep 04 14:04:35 peacememories: honestly, I am not that much of a yocto expert to answer that Sep 04 14:05:17 well, i'll find out if the append file helps in a few minutes^^ Sep 04 14:08:37 peacememories: I just talked to my colleague, it appears that what we're doing right now is much more blunt than config fragments... instead of using config fragments, we fork the u-boot repository of our SoM vendor and use a bbappend to override the default u-boot source with our own repo Sep 04 14:09:10 i think that would be overkill for me^^ Sep 04 14:09:15 but thanks for asking around :) Sep 04 14:09:40 i'm loading my new u-boot image onto my board and then i'll see if the features are enabled Sep 04 14:10:20 doesn't look like it^^ Sep 04 14:11:02 i have to go offline now, but thanks for your help :) i'll be around^^ Sep 04 14:25:41 robsta: what are you building and how? Sep 04 15:13:44 nrossi: The kernel recipes (linux-xlnx) don't seem to pick up my modifications to ps7_init_gpl.*, only u-boot (u-boot-xlnx) gets rebuilt.. Sep 04 15:14:10 nrossi: How can I tell it to rebuild? Sep 04 15:16:39 can qt5 be used on a build that only uses linuxfb? Sep 04 15:26:09 Experimented a bit with using nativesdk-g++ and it seems like the linker from nativesdk-g++ is broken? Can't get it to say anything else than that it doesn't support sysroots, I think x86_64-pokysdk-linux-g++ uses the host systems linker with a --sysroot and this isn't working. Sep 04 15:28:06 Managed a workaround by using x86_64-pokysdk-linux-g++ for compilation and then linking with the host systems linker with 'g++ -Wl,--dynamic-linker=${OECORE_NATIVE_SYSROOT}/lib/ld-linux-x86-64.so.2 -Wl,--rpath=${OECORE_NATIVE_SYSROOT}/usr/lib -Wl,--rpath=${OECORE_NATIVE_SYSROOT}/lib -L${OECORE_NATIVE_SYSROOT}/usr/lib' Sep 04 15:28:54 Is the nativesdk-g++ compiler supposed to work? Sep 04 15:31:42 JoiF: kernel doesn't use ps7_init_gpl.*, so no need to rebuild :) Sep 04 15:36:57 nrossi: That would explain it... ;) Sep 04 16:24:42 nrossi: Woohoo! Finally got the TX side of the GMII2RGMII block working :D Sep 04 16:25:00 nrossi: But it's still deaf because it's RX clock isn't right yet. :P Sep 04 16:35:57 nrossi: Giving up trying to configure my clocks using ps7_init* helped a LOT. ;) Sep 04 17:49:21 can qt5 be used without x11 and rather directly use linux with the frame buffer driver Sep 04 18:13:39 Is there a prefered way to handle multiple library dependencies in terms of git repos? Assume we have libA which uses libB: At the moment I have two repos but libA has a submodule containing libB. This is the good way for me for native compilation. However, this is not a good way for bitbake workflow, isnt it? For bitbake I have two recipes and libA contains RDEPENDS="libB". It would be nice to have one solution for Sep 04 18:13:40 both use cases. Any ideas? Sep 04 19:42:14 armpit: around? Sep 04 19:42:24 yes Sep 04 19:42:44 armpit: that build I ran showed errors, uninative GLIBC symbol issues in eSDK :( Sep 04 19:43:03 morty with uniative updates? Sep 04 19:44:27 armpit: yes Sep 04 19:45:17 rburton: hello Sep 04 19:46:14 RP1, it was worth a try. Sep 04 19:46:59 armpit: its the getentropy stuff :( Sep 04 19:47:28 armpit: I just logged in and see /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-world/build/build/tmp/sysroots/x86_64-linux/usr/lib/libpython3.5m.so: undefined reference Sep 04 19:47:29 to `getentropy@GLIBC_2.25' on fedora25.yocto.io Sep 04 19:48:40 although this doesn't make sense :/ Sep 04 19:48:50 is that the same error being reported on pyro? Sep 04 19:49:28 armpit: yes Sep 04 19:49:35 k Sep 04 19:49:41 armpit: it does make sense now I wrap my head around it correctly Sep 04 19:50:13 armpit: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=faf20cc3804325b13f0e9679507724a904cbd3a0 was the fix Sep 04 19:50:49 armpit: Also http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=27ea26e3d674476d77257e731703f70faaba780b http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=08128ecf6ba165503e08702d51710eb979d2d1f5 Sep 04 19:50:55 cool. I pull the in for pyro Sep 04 19:51:15 * armpit working on pyro updated today Sep 04 19:52:40 armpit: although the eSDK error is different :/ Sep 04 19:53:06 armpit: I guess we can try it, it might be similar enough... Sep 04 19:54:57 armpit: the python fix cleanly cherry-picks to morty so I may try it Sep 04 19:55:04 k Sep 04 19:55:51 rburton: https://github.com/OSSystems/oe-core/tree/wip/go is where I am working on the Go improvements Sep 04 19:56:41 armpit: have you noticed oe-selftest on morty is hanging? Sep 04 19:58:04 armpit: hmm, just seems logging is messed up actually Sep 04 19:58:13 no. Sep 04 19:58:33 which morty? Sep 04 19:58:43 weekly build? Sep 04 19:58:48 or mine Sep 04 19:59:21 btw, when are the weekly pyro and morty builds kicked off? Sep 04 20:00:19 armpit: not sure, over the weekend is all I know... Sep 04 20:01:01 armpit: the logging on selftest is just quiet which confuses me compared to the way master behaves (which improved) Sep 04 20:04:23 * armpit needs more build systems Sep 04 20:06:18 armpit: you're juggling a lot of releases :/ Sep 04 20:13:30 Heyho Sep 04 20:14:38 Im struggling with CMake and include dir staging. How can I add an include file from libA used by libB so that this include file is visible for libB? Sep 04 20:19:01 Saur, thanks for the wiki edit Sep 04 21:09:58 rburton: khem: a go patchset is sent ;-) Sep 04 21:12:58 Naibaf: Add a dependency on libA into libB.bb and ideally let the libA export its target during installation so that you can simply `find_package(LibA)` & `target_link_libraries(libB libA)` Sep 04 21:13:39 curlybracket: you should add pkgconfig to libA Sep 04 21:13:54 thanks for the reply. Sep 04 21:14:02 What does pkgconfig? Sep 04 21:15:26 otavio: I agree that pkgconfig is more versatile. But if your project is strictly CMake based, it's very convenient to stay with CMake targets Sep 04 21:15:56 curlybracket: there are two options: you make a cmake module or write a pkgconfig .pc file Sep 04 21:16:22 curlybracket: https://github.com/OSSystems/inih Sep 04 21:16:38 curlybracket: this generates the pc froc CMake cache Sep 04 21:17:43 otavio: CMake may write the module for you. https://cmake.org/cmake/help/v3.9/command/install.html#installing-targets Sep 04 21:18:08 uhh never hear before about .pc files. Sep 04 21:18:16 otavio: But yes, it can also write the .pc file for you Sep 04 21:18:23 is there a method with STAGING_INCDIR? Sep 04 21:19:59 otavio: but you'd lose many features including the super-convenient target_link_library(target WHATEVER Namespace::Dependency) one-line link declaration Sep 04 21:20:59 Naibaf: why STAGING? Wouldn't you rather access the files from recipe-sysroot? Sep 04 21:23:31 I think I did not understand the concept of staging yet. What is the difference between recipe-sysroot and STAGING_INCDIR? Sep 04 21:24:08 Naibaf: https://www.openembedded.org/wiki/Legacy_staging Sep 04 21:24:48 tyvm Sep 04 21:24:54 Naibaf: few years of bitbake development, I guess Sep 04 21:28:01 curlybracket: so STAGING_INCDIR was for global include files and recipe-sysroot is only recipe based? Sep 04 21:50:07 yes, you only get access to those packages you explicitly declare a dependency Sep 04 21:59:07 otavio: awesoe Sep 05 01:13:01 rburton: it would be good if you could add the set to MUT Sep 05 01:13:14 rburton: once those are in, I will work on more Sep 05 01:13:27 rburton: will see if I can get the SDK going on **** ENDING LOGGING AT Tue Sep 05 03:00:00 2017