**** BEGIN LOGGING AT Thu Sep 29 02:59:58 2016 Sep 29 04:02:17 kergoth: Thanks for reply Sep 29 04:02:33 kergoth: Where can I find such patch? Sep 29 06:39:20 My recipe is using externalsrc and is thus nostamp-ed on do_compile. However, between two compilation where MACHINE is changed, the recipe will try to use the old machine's sysroot settings since configure is not being run in the second invocation. What should I do about that? Sep 29 06:40:51 hi .. how do i debug DISTRO_FEATURES, some wiki mentions a command called 'bb show DISTRO_FEATURES' which is not available on my side ? Sep 29 06:49:27 rob_w: try "bitbake -e | grep ^DISTRO_FEATURES" if you just want to look at what it is set to Sep 29 06:49:53 thx Sep 29 07:08:57 Can I setup a nostamp rule within a recipe? Sep 29 07:16:04 hello Sep 29 07:16:37 is it possible to buil intel-gpu-tools without x11 support? (in yocto, of course) Sep 29 07:59:51 What variable can I use to access the sysroot's /usr/include? I want to add -I/usr/include/opus to CC Sep 29 08:00:43 ..or the path to the sysroot for that matter Sep 29 08:03:56 STAGING_INCDIR <-- is that it? Sep 29 08:05:28 Hello guys Sep 29 08:05:56 I have question about linked library Sep 29 08:06:26 ask it Sep 29 08:06:55 sveinse: when cross compiling with the generated sdk toolchain? Sep 29 08:08:14 sandmark: not necessarily sdk, also when compiling yocto from scratch Sep 29 08:08:22 ok. after package build/install, I can see sw linked file like below Sep 29 08:08:41 libtest.so.1.10 and libtest.so Sep 29 08:09:04 libtest.so is linked to libtest.so.1.10 Sep 29 08:09:45 But it does not help really, since do_configure is run only once, so all the makefiles are pointing to the wrong location Sep 29 08:09:49 but when I build whole image, generated rootfs include only libtest.so.1.10 Sep 29 08:10:30 I need link file too in generated rootfs Sep 29 08:11:48 sveinse: how to include it to rootfs? Sep 29 08:13:47 onionfra: bb/oe considers libtest.so a -dev library if it is a symlink to libtest.so.1.10 Sep 29 08:15:48 hmm.. that means, If I add test-dev(for test package), can see link file in rootfs. right? Sep 29 08:16:58 onionfra: yes Sep 29 08:17:08 ok I will try Sep 29 08:17:16 thank you sveinse Sep 29 08:17:22 np Sep 29 09:09:08 Hi, is there a best practice adding new systemd targets to an image? Sep 29 09:09:08 Should i write a separate recipe adding the targets to /lib/systemd/system or Sep 29 09:09:08 is it better to append systemd_%.bb? Since i have to set a new default target too Sep 29 09:12:47 Hi there, hiw can I remove the waiting time and set boot parameters of u-boot before create the image ? Sep 29 09:12:53 *how Sep 29 09:23:02 guys .. i trying to upgrade from a fido to krogoth build, but the package names changed from cortexa9hf-vfp-neon to cortexa9hf-neon which i suspect with this change http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/conf/machine/include/tune-cortexa9.inc?h=krogoth&id=e9b2ffc0feeefdd03115f1e9495e9be48ee749b2 Sep 29 09:23:19 what is my next step to get this compatible again ? Sep 29 09:29:27 rob_w. I Sep 29 09:29:45 I've seen the same. That vfp is removed from the name Sep 29 09:30:07 But the output/contents are the same, afaics Sep 29 09:30:55 the issue comes when pointing to the new package index and using opkg upgrade .. it doesnt pull the different packages .. at least i suspect the name change is the reason for that Sep 29 09:31:08 rubiccube: The timeout is set in the environment. Either there is a way in your u-boot recipe to set additional environment variables or you have to patch the default environment of your u-boot sources Sep 29 09:31:46 Thank fl0v01 I will check Sep 29 09:34:55 ok fixed it myself .. need to add this arch to etc/opkg/arch.conf ;-) Sep 29 09:37:05 After build yocto image, I can see udev-dev in image.menifest file Sep 29 09:37:35 But I can't file udev-dev in source/*.bb Sep 29 09:37:51 Who added udev-dev ? Sep 29 09:38:20 Sorry "But I can't find udev-dev in source/*.bb Sep 29 10:36:27 I keep using these constructs from local.conf: PACKAGECONFIG_pn-sp="${@bb.utils.contains('MACHINE', 'lm-sp', 'sp', '', d)} ${@bb.utils.contains('MACHINE', 'lm-lb', 'lb', '', d)}" Sep 29 10:36:39 Are there any less tedious ways of doing this? Sep 29 10:41:17 assuming you have more than one machine to support, use a machine override Sep 29 10:43:04 sveinse: I have a different manifest branch for every machine which then checks out a different conf folder. Sep 29 10:43:04 I tried to use machine overrides, but it was always a hassle. Especially because the layer masking did not work properly Sep 29 10:43:31 speaking of overrides... is it possible to do image overrides? Sep 29 10:45:37 PACKAGECONFIG_pn-sp_lm-sp = "sp" should work fine Sep 29 10:46:12 ernstp: you can't manipulate a package based on what image it goes into as packages are built once and re-used for multiple images Sep 29 10:48:15 rburton: suspected so... Sep 29 10:48:53 rburton: Can I use overrides for any variable? SOMEVAR_lm-sp="something" Sep 29 10:49:02 I'm building image-client1 and image-client2 for the same machine Sep 29 10:53:03 sveinse: yes Sep 29 12:02:14 What is the opinion in putting MACHINE specific depends into a (core-)image based recipe? That is make a recipe pack an image differently based on MACHINE settings vs. having two distinct different recipes? Sep 29 12:03:45 there are often machine specific depends, like graphics drivers for example Sep 29 12:04:00 yeah the example images and package groups do that all the time Sep 29 12:05:02 does 2.1.2 have a planned date? Sep 29 13:36:49 bah, opkg doesn't like https urls, I guess busybox' wget doesn't support ssl? Sep 29 13:38:29 sandsmark: for what it's worth, opkg can be configured to use curl as well. that supports a bunch more protocols. Sep 29 13:38:40 I can't find where the grub_live.cfg referenced as grub-efi.bbclass:GRUB_CFG_LIVE comes from - my eyes are crossing, obviously... Sep 29 13:38:46 yeah, but my core-image-minimal doesn't have curl yet Sep 29 13:41:27 not even vim, which is almost as unbearable :P Sep 29 13:43:11 yann: ${S} points to unpacked source code, so i'm guessing whatever inherits grub-efi is supposed to make sure it's included in the downloaded sources Sep 29 13:43:22 not familiar with that class though Sep 29 13:43:59 sandsmark: :( Sep 29 13:51:43 ah, that's build_efi_cfg generating it Sep 29 13:52:56 yann: ah, yeah, that seems to be it. didn't read that carefully. Sep 29 13:53:17 can't understand how I missed it so long - lack of sleep maybe ;) Sep 29 14:02:49 Hi! I'm getting strange Segfaults with Qt5.5.1 on an i.mx6 system within libGLES. See: https://paste.ee/p/9kEJY. Sep 29 14:03:04 Can someone help with this? Sep 29 14:05:08 yann: looks like set_live_vm_vars() in live-vm-common.bbclass will set GRUB_CFG to either ${GRUB_CFG_VM} or ${GRUB_CFG_LIVE}, depending on the 'suffix' argument Sep 29 14:05:43 and image-vm.bbclass and image-live.bbclass do set_live_vm_vars(d, 'VM') and set_live_vm_vars(d, 'LIVE'), respectively Sep 29 14:06:12 always nice to grep for dynamically generated names... Sep 29 14:07:19 yep :) Sep 29 16:08:01 Should meta-toolchain (and things that extend it) be used anymore? The docs I'm reading here: https://www.yoctoproject.org/docs/2.2/adt-manual/adt-manual.html only mention using `-c populate_sdk` (and variants). meta-toolchain still exists though, and meta-qt4 appears to extend it. Any guidance here? (The images I'm working with use qt4, and the sdk users are going to want to build qt4 apps) Sep 29 16:11:13 fishey1: meta-toolchain is pretty much dead, use populate_sdk (or _esdk) on images instead. Sep 29 16:34:09 have to say i'm quite surprised to see bitbake listed at http://awesome-python.com/ .. considering it's not particularly useful without metadata Sep 29 16:36:09 kergoth: its still awesome Sep 29 16:36:15 true. Sep 29 16:54:54 ERROR: Package Version (3.14-xilinx+gitAUTOINC+2b48a8aeea) does not match of kernel being built (3.14.2). Please update the PV variable to match the kernel source. Sep 29 16:55:24 I'm seeing non-deterministic failures trying to build linux-xlnx which feeds off linux-yocto Sep 29 16:56:02 patch on the list already Sep 29 16:56:48 ah Sep 29 16:57:20 gettting some determinism might help me find underlying problem where a patch from a bbappend is apllied twice Sep 29 16:57:24 with poor restuls Sep 29 16:57:28 * Crofton goes to drink Sep 29 17:00:21 who is jku__ I just ignored them :) Sep 29 17:00:27 crap Sep 29 17:01:01 oh jussi you're spamming irc Sep 29 17:01:32 lol, just silenced joins Sep 29 17:01:38 now to un ignore him Sep 29 17:01:42 grrr Sep 29 17:06:03 hello, can anyone point to a lead to get .NET Core into Yocto? Sep 29 17:07:43 meta-mono? Sep 29 17:13:44 Mono was to support the .NET Framework before .NET Core is available Sep 29 17:13:56 .NET Core by default is cross platform Sep 29 17:21:11 layers.openembedded.org Sep 29 17:21:13 might help Sep 29 17:21:59 I'll check it out. Thanks Sep 29 17:38:40 jku__: you come and go~ Sep 29 18:34:15 someone knows which package creates the daemon group? Sep 29 18:43:21 rburton: ok, so I should prefer populate_sdk (or populate_sdk_ext, I suppose) then. In that case, is it possible for sdk users to build qt4e applications after sourcing the sdk? (I've inherited a group of users who are used to using a meta-toolchain-qte + a few appended packages from an old poky release, so I'm trying to avoid breaking their process too much while upgrading them) Sep 29 18:43:53 and by "build" I mean run `qmake && make` Sep 29 19:30:51 zeddii_home, awake? Sep 29 19:31:02 I'm seeing some weird stuff patching things Sep 29 19:31:08 in kernel builds Sep 29 19:31:45 http://pastebin.com/hSxrynXK Sep 29 19:31:54 note first and last patch are the saem Sep 29 19:32:38 barely awake after my red eye last night. Sep 29 19:32:55 this is with master ? i can definitely take a closer look. Sep 29 19:33:24 but I’ll need to pull together the right layers, assuming they are something I can see. Sep 29 19:34:53 should be able to see them Sep 29 19:35:07 I was hoping this was an aha moment ... Sep 29 19:35:18 all master Sep 29 19:35:53 I'll email my mrconfig file :) Sep 29 19:36:41 perfect. things are very simple on master, it just takes what’s on the SRC_URI and generates a series. it won’t generate parts any more like it used to. so i expect it should be easy to find. Sep 29 19:36:59 but I have the time to debug it right away. so shoot over that config and I’ll fire it up. Sep 29 19:37:36 OK, I am getting some lunch and looking also Sep 29 19:37:38 gah Sep 29 19:37:44 you need a patch for oe-core Sep 29 19:38:25 the kernel recipe is funny, since I fighting to keep an old one building, but this fail is weird Sep 29 19:39:49 cool. i see the email. i’ll drop an email and a message here if I figure it out. if you also find someting out, let me know. Sep 29 21:19:24 hello Sep 29 21:19:34 hello Sep 29 21:21:20 im using cmake and all my code is relative to PROJECT_SOURCE_DIR in cmake. however since I have generators making source, they get put in build/ . rather than hacking to get to that folder with ../../build/foo syntax is there a way to access them using cmake variables as set by bitbake? Sep 29 21:25:55 davis: not a cmake expert and not sure i'm following, but ${B} points to the build directory. for e.g. autotools and cmake, that will be separate from the ${S} (source) directory by default. Sep 29 21:26:38 Ulfalizer: i'm not either, but I've been rewriting these cmake files so that I can do native and target Sep 29 21:27:07 things work much better, but I have a problem where generators build src files Sep 29 21:27:39 so I have some files which are src in build subdir and some files in git Sep 29 21:27:43 do those need to be compiled in a separate step? what's the output of the cmake step? Sep 29 21:28:25 so on standalone, I do one cmake and it builds/run/builds all. Sep 29 21:30:19 davis: ${S} will refer to the source tree (e.g. the git repository). ${B} refers to the build directory, where the build output shows up (e.g. what would ordinarily be the build/ subdirectory where you run 'cmake ..', though it's put outside the source directory when building with the cmake class in yocto). Sep 29 21:31:09 so if you need to do something with the build output (be it generated source files or something else), then ${B} is the place to look Sep 29 21:31:33 I have have to pass a folder location to cmake with the ${B} setting to cmake Sep 29 21:32:12 many thanks Sep 29 21:32:17 I got something to work on Sep 29 21:32:20 that seems weird. cmake should already know what the build directory is. :S Sep 29 21:32:27 but as long as you got wiser ;) Sep 29 21:42:03 some of the poky code could use more tuples Sep 29 21:43:38 if x in ("foo", "bar", "baz") compiles down to much smaller/faster bytecode than if x in ["foo", "bar", "baz"]. in the first version, ("foo", "bar", "baz") is stored as a constant and loaded with a single instruction. in the later version, all the elements have to be assembled into a list. Sep 29 21:43:55 so tuples are much better for lists of constant things (like strings in python) :| Sep 29 22:06:20 heh... looks like it optimizes 'x in [*constants*]' to 'x in (*constants*)', so i probably whined unnecessarily. doesn't change 'for x in [*constants*]' though. Sep 29 22:13:32 that sounds like pointless optimization of non-critical codepaths causing statistically insignificant performance issues Sep 29 22:15:05 looks ugly once you know about it though, like people writing x = x + 1 instead of x += 1 Sep 29 22:15:12 plus a dash of OCD~ Sep 29 22:16:04 doesn't look ugly to me, you're using a tuple for things a tuple isn't meant for, for performance reasons Sep 29 22:16:11 write pythonic, clean code, then optimize only if and where it's needed Sep 29 22:16:53 nah, i'm using it because it makes more sense as an immutable collection conceptually. any small performance gains are a bonus. :) Sep 29 22:16:58 if you're really concerned about testing 'in' a group of values, you should be using a set() anyway, so it's O(1), not O(n) Sep 29 22:17:58 that's where it becomes meaningless optimization to me, if it makes the code more convoluted Sep 29 22:18:10 and you haven't nailed down some really tight spot Sep 29 22:18:14 using a set isn't any more convoluted than a tuple, particularly with python 3 which has set definition syntax Sep 29 22:18:35 nah, might be alright there Sep 29 22:18:57 well don't expect us to accept a rash of useless patches changing things to tuples Sep 29 22:19:08 wasn't planning to submit any Sep 29 22:25:52 zeddii_home, check your email Sep 29 22:26:11 * kergoth ponders Sep 29 22:27:52 where i'd actually consider changing it would be for stuff like foo = [...] where the list is actually immutable and never meant to be extended at runtime. there it becomes a readability issue, because {} or () would send a signal that it's constant. Sep 29 22:28:08 still usually a silly patch though Sep 29 22:28:16 and often people use CAPS for stuff like that Sep 29 22:31:13 then do it for literals for consistency and driving the concept home~ Sep 29 22:31:20 Sep 29 23:21:08 did the u-boot git repot for x86 change? **** ENDING LOGGING AT Fri Sep 30 02:59:58 2016