**** BEGIN LOGGING AT Tue May 31 02:59:58 2016 May 31 07:31:34 hi. Is there a way to disable gobject-introspection globally? It fails to build saying my target kernel is too old. May 31 09:40:34 hi. I have just changed NAME_PREFIX and now I'm having a failure in do_configure of nativesdk-glibc-initial (https://gist.github.com/fredcadete/4aba92fc3c0e12ac9afca4e2d5f51653) May 31 09:41:19 s/NAME_PREFIX/SDK_NAME_PREFIX/ May 31 09:41:59 I've tried cleaning sstate of that and of nativesdk-linux-libc-headers but the issue persists May 31 09:42:19 does anyone know if this is normal? am I forced to start from a clean sstate when I change SDK_NAME_PREFIX? May 31 09:57:35 alternatively, is there a way to clean sstate for all nativesdk* packages but leave the rest alone ? May 31 12:10:48 JaMa, https://bugreports.qt.io/browse/QTBUG-52739 is going to be a Qt mainstream bug. I don't know how long they will take to correct it properly. May 31 12:11:42 JaMa, I can propose a patch for meta-qt5/qtbase during the time they correct it properly. May 31 12:21:57 present: I've already merged the patch you sent earlier, are you saying it wasn't complete fix? May 31 12:22:29 qtbase: Reorder EGL libraries from pkgconfig and defaults: May 31 12:22:45 JaMa, I'm saying they should make a proper correction instead of this swap. May 31 12:22:57 ok May 31 12:23:21 I hope you will be able to remove it soon. May 31 12:23:53 JaMa, thanks! :) May 31 12:26:23 thanks! :) May 31 14:29:53 in the remote case anyone is wondering, my issue earlier this morning was related to the fact that I was making SDK_NAME_PREFIX vary from recipe to recipe (I had put ${IMAGE_BASENAME} in there and it defaults to ${PN}) May 31 14:36:00 Has anyone thought about either directly using the sysroot_stage_ functions or obeying SYSROOT_DIRS* separately, for the SDK target sysroot? There's quite a bit in there that isn't actually likely to be needed in a sysroot, only on target. Maybe I should play with the esdk some more May 31 16:33:18 JaMa: looking into the luajit failure now. wasn't able to repro it with gcc 6.1, but testing with gcc 5.3 now May 31 17:34:23 hello May 31 17:34:38 I have question about aproach to solve one problem May 31 17:34:51 in my case there is an user space app that is build in yocto May 31 17:35:37 and now I wan't to start speciall build for this app let say for unit test May 31 17:35:42 my idea is that May 31 17:35:53 bitbake myapp -c unuttest May 31 17:36:18 this task will properly compile my app and prepare binery to test May 31 17:36:54 I wan to start this application using qemu in my recipe May 31 17:37:23 I was thinking to use already implemented mechanism of imagetest May 31 17:37:41 but I can not have taps on build server May 31 17:37:58 so I want to use prepared image with virtio device in my qemu machine May 31 17:38:31 this imige will automatically start my binary using virtio share May 31 17:39:06 so now I want to write class/inc to achive this, but maybe there is other way to have such functionality? May 31 17:39:30 or maybe my aproach is wrong and migh create many problems? May 31 17:39:35 JaMa: v2 of luajit sent, sorry for the hassle. apparently some gccs handle the -ldl implicitly, since it didn't fail in all cases May 31 17:40:22 Marcin__: we already have the ptest mechanism for running tests on recipes. i'd suggest using that, then running those ptests with the imagetest bits in an image May 31 17:40:39 or manually, or whatever you like once the image is built May 31 17:40:58 kergoth: no problem, thanks for quick update May 31 17:41:11 regardless, the best bet is to not have your recipe doing the testing, instead the recipe should package it up, add that to th eimge, and then test it using those bits at runtime May 31 17:41:21 JaMa: np May 31 17:41:50 JaMa: quite irritating trying to locally test everything the autobuilder might, otherwise can easily submit a fix that breaks the build May 31 17:41:51 heh May 31 17:42:05 kergoth: I was not aware about that mechanism, I need take a look on it then May 31 17:42:08 would be nice if we could quickly and easily sanity test all the same configurations May 31 17:42:21 kergoth: thans fr very fast response May 31 17:42:29 np May 31 17:43:39 if you add ptest to your DISTRO_FEATURES, then any recipe supporting ptest will emit a -ptest package, which can be added to the image manually or by adding all ptest packages with the 'ptest-pkgs' image feature. how you add ptest support to a recipe.. i'm not sure if that's documented, but i'd check the yocto mega manual. worst case there are lots of example recipes if you grep for recipes inheriting the ptest class May 31 17:44:00 at runtime you can either run the individual ptest scripts in /usr/lib/ptest/ or use the ptest-runner May 31 17:44:10 i think the yocto docs cover that, though May 31 18:00:55 * kergoth ponders using the keyring module for credential handling if we could find a secure mechanism to pass those credentials into the underlying fetcher, i.e. provide our own git credential helper May 31 18:01:02 would be nice since keyring can use the gnome keyring, vault, etc May 31 18:04:35 why not just let git use its own credential helper and let it talk to the keyring? May 31 18:05:19 that being said, it's not terribly complicated to write a credential helper for git; the interesting question is how complicated it is to do for other fetch methods. May 31 18:06:27 Neither wget nor curl currently support accessing the keyring, and I don't think either of them have a way to pass passwords securely. May 31 18:06:46 neverpanic: i mainly wanted something that's consistent across the board as much as possible. using keyring as the mechanism means it can be configured in one place May 31 18:06:50 yeah, thatd' be a concern May 31 18:07:23 wonder if it'd be worth writing a curl fetcher that uses pycurl and the curl lib rather than a separate process, so at least it doesn't end up in plaintext in its commandline, it'd be in memory only May 31 18:07:30 last time I looked into this my biggest hurdles were subversion-native not having keyring support and getting the dbus socket into my build container May 31 18:07:34 course memory contents canb e poked at in some cases, so.. May 31 18:07:36 * kergoth nods May 31 18:08:01 i haven't looked into it too deeply, it'd just be nice if the user could configure bitbake to handle credentials in a given way, rather than having to configure every underlying tool May 31 18:08:10 I'd be interested in what curl upstream has to say about an optional keyring interface May 31 18:08:25 anything has to be better than shoving credentials into an svn config file and netrc, no? :) May 31 18:09:49 Yes, fully agree. Unfortunately I haven't found a way around that because of missing keyring support in svn and wget, as I mentioned. Git can be configured manually (although I agree it's tedious to setup) May 31 18:10:44 t.b.h. I'd also be surprised if bitbake could fetch a repo without password prompt, but a checkout outside of bitbake prompts. May 31 18:20:31 neverpanic: hmm, according to https://wiki.apache.org/subversion/EncryptedPasswordStorage, subversion 1.6 and newer at least supports the gnome keyring and kde wallet, if not a pluggable mechanism or use of the python keyring. useful, but doesn't help with the consistency thing May 31 18:20:59 still, good to know, might have to set up a gnome keyring for my automated builds and try using it for that and git at the very least May 31 18:24:21 yes, svn supports that, but AFAIR that needs a library dependency which isn't available in the subversion-native built by bitbake May 31 18:24:31 It's been a while since I checked that, though, so that might have changed. May 31 18:28:02 ah, that's good to know May 31 18:28:52 course we could easily write and use a git-svn fetcher, too :) May 31 18:39:42 Hey is anyone there? I'm very new to the yocto project and was just wondering if there were rules/behaviors that I should be aware of in this chat what I can and should use this for? May 31 18:40:14 it's not that complex. if you have questions, ask them May 31 18:40:16 rules/behaviors are general common sense May 31 18:52:46 If I’m building an accessory from the ground up that is going to need to be using a Yocto distribution that will be essentially a shaved down version of a Legato distro (we want our footprint to be as small as possible but want the core functionality of a Legato system for our project), will I have trouble if I start to build a code base and familiarize myself with Legato app development while we develop our Yocto platform? Wi May 31 18:54:21 Will the crossover be relatively intuitive and lossless? May 31 18:54:51 no idea what legato even is, so couldn't say May 31 18:54:57 maybe someone else knows May 31 18:59:19 Okay, thank you anyways. Is there any way you could put into perspective application development on a Yocto? Specifically does Yocto build stand alone OS's and all functionality is library/application based or what mediums through which can I actually perform actions on a Yocto linux distro? How does it differ from a standard linux system? May 31 19:00:09 I don't really understand the question. Yocto provides a build tool and metadata you can use to build and maintain embedded linux distributions. What you install on your device is really up to you. May 31 19:00:57 You can build an sdk with it that matches up with what you use on target to do your development, and there's an eclipse plugin if that's your thing, but beyond that what you do with it is always up to you May 31 19:01:39 Sorry for being slow, I'm really new to linux based programming haha. But that answer helps a lot thanks May 31 19:01:43 and the answer to the latter is "it doesn't". what it builds is a linux distribution / filesystem for use on your board. you're free to customize it to your liking May 31 19:02:18 it's not a full stack application development solution. it's a flexible tool to let you construct whatever linux distro / filesystem you want to run on your device. what libs/apps are included is entijrely in your hands May 31 19:03:25 fwiw, it's useful to know that Yocto allows you to bake libs/apps directly into your OS image, so that at boot it will be included, or separately as packages that can be deployed to a system that is already running May 31 19:04:05 my impression is that developing a Yocto-based platform in parallel with application development is a fairly common workflow. May 31 19:06:53 it's also common to have a systems developer doing the oe/yocto builds and handing a disk image and sdk to the app or kernel devs who run with that, rather than messing with bitbake themselves May 31 19:07:00 obviously depends May 31 23:58:36 Anyone using the latest linux-imx_4.1.15 release? I'm having troubles having htis kernel detect any previously working sdcard Jun 01 01:18:00 how can i include $packagename-dbg by default on an image? IMAGE_INSTALL_append don't seems to understand the -dbg suffix Jun 01 01:19:21 ok.. forget my question, i had a typo and wrote -dgb instead of -dbg :\ **** ENDING LOGGING AT Wed Jun 01 02:59:59 2016