**** BEGIN LOGGING AT Tue Jul 05 02:59:59 2016 Jul 05 05:41:14 vmeson, there's no visible error, it's just ignored, as far as i can tell. i will look again, antway Jul 05 05:41:21 anyway Jul 05 05:58:28 pfff, it seems that genivi repos are alive, hence i can not reproduce the problem anymore :( Jul 05 05:58:47 but the build is not over yet Jul 05 08:36:45 I am about to do a concept test of an yocto port of an embedded Qt5 application (which runs on armhf target today). What is the possibility to run yocto with an application requiring openGL emulated on intel? Jul 05 08:37:38 sveinse: I think it works... but I havn't tested recently. the default distribution (poky) suppors opengl iirc Jul 05 08:38:38 boucman_work: ok, then I'll test it. But, isn't this more about quemu's capability than poky/yocto per se? Jul 05 08:39:20 you didn't specify that you were targeting qemu :P Jul 05 08:39:47 and to answer your question... i don't know what qemu+opengl does... I think that it kinda works, but I have no first hand experience Jul 05 08:42:48 boucman_work: True, I didn't. I see I forgot that part of the question. Let me explain: The yocto image is going to be run on armhf, but I'd like to prototype yocto on intel for simplicity. I assumed that you had to run it via some emulator to be able to run it from boot. So are there any other methods available? Docker? vbox? Jul 05 08:44:09 sveinse: I usually develop on intel (as in : build a yocto image for intel) then run it on qemu. opengl has a better chance of working that way. HW acceleration might even work Jul 05 08:44:27 but it depends what you want to test. Usually changing architecture on linux causes little problems Jul 05 08:44:41 qemu+opengl is software rendering Jul 05 08:44:57 no matter what hardware target Jul 05 08:44:58 boucman_work: Excellent. Than I'll start with that. Thanks Jul 05 08:45:13 i'd prototype for intel and run on real x86 if you care about opengl Jul 05 08:45:52 rburton: good to know. It does not matter thou. It's a concept test, so getting the build up and running is more important than the performance of the app Jul 05 08:46:08 As pointed out, the game changes slightly when moving to real architecture and HW Jul 05 08:47:09 sveinse: still, prototyping on x86 is way easier... yocto produces bootable usb key for testing, which is pretty handy if you want to avoid qemu Jul 05 08:49:33 boucman_work: why? IMHO if I need to make a bootup a dedicated x86 machine running an image, there is no principal difference from doing the same on the real arm HW instead, right? Jul 05 08:52:11 sveinse: depends if you have the real HW, I thought you didn't and wanted to use qemu instead Jul 05 08:52:28 if you do, then why not... I still tend to do on x86 because it's more practical, but YMMV Jul 05 08:54:16 boucman_work: We do have real HW, but I don't want to throw BSPs into the mix just yet (I'm very new to yocto yet), so I had hoped doing yocto via x86 and perhaps via qemu would smooth up the learning curve Jul 05 08:55:30 sveinse: if your app can work on x86, try with x86, it's easier Jul 05 08:55:45 once you can run it on a usb key on a normal computer, you can switch to the HW Jul 05 08:55:50 that would be my approch Jul 05 08:56:17 boucman_work: It can, if it gets opengl. Qt5 apps require opengl these days Jul 05 08:56:52 So I'll try the sw rendering approach Jul 05 08:57:29 ok Jul 05 09:00:21 hi, it's maybe more of a systemd issue, but I'm trying to get networkd with PACKAGECONFIG_append in a systemd bbappend file, but they do not appear on the target, am I missing something? Jul 05 09:01:19 mathieu1: did you add networkd to IMAGE_INSTALL ? networkd might be in a separate package.. Jul 05 09:02:26 ah that could be the case yes, because the systemd-networkd binary appear in my build folder, it's just not included, I'll try this, thanks Jul 05 09:11:48 mathieu1: the binary should also appear somewere in the package-split directory next to the build folder Jul 05 09:12:01 the exact place where you find it will tell you what package includes it Jul 05 09:23:09 oe-pkgdata-utils list-pkg-files systemd will list all packages/files generated by the systemd recipe Jul 05 09:23:16 erm oe-pkgdata-util, even Jul 05 09:26:51 thanks, it s listed here and appears also in tmp/sysroots/ so maybe I need to clean my image before a rebuild Jul 05 09:29:28 I really need to learn more about oe-pkgdata-utils Jul 05 09:29:54 oe-pkgdata-utils —help is a good starting place :) Jul 05 09:30:07 time is what i'm missing, mainly :P Jul 05 09:30:35 * boucman_work needs to write a mail to the architecture mailing list about building multi-partition yocto builds... Jul 05 09:30:44 it's almost doable :P Jul 05 09:32:38 isn't that what wic is for? Jul 05 09:37:18 rburton: not really. wic is about assembling stuff, my problem was creating multiple .ext4 file from one ROOTFSDIR Jul 05 09:37:37 i.e have /usr on a separate partition Jul 05 09:38:14 the problem is that it's pretty easy to create a new image_type that would only contain /share (just use mkfs on the correct subdir of ROOTFSDIR) Jul 05 09:38:59 but mkfs doesn't have a --exclude option, so creating the "/" partition without the content of /share was tricky. I moved the content of /share to another directory and back, but that's not very error-proof Jul 05 09:49:37 Thank you very much, my issue was that I didn't rebuild my core-image first before my "extended" one so the changes werent propagated into it... (pretty silly) cool to learn about the oe-pkgdata-utils it's quite usefull Jul 05 11:59:21 hi guys Jul 05 12:03:20 i know we can append systemd search paths to check for other unit locations. is there any way i can another search path in my recipe? looking at the systemd.bbclass file, it seems not, but i'd like to generate a kind of a jail environment Jul 05 12:12:30 when I add a "LAYERDEPENDS_baa = "foo"" line to "baa/conf/layer.conf", that layer completely vanishes from bitbake (e.g. not shown anymore with "bitbake-layers show-layers") Jul 05 14:20:06 Reminder: We will have a Yocto Project Technical Meeting in 40 minutes, Jul 05 14:20:06 Ready-Access Number: 8007302996/9139049836 Access Code: 2705751 Jul 05 14:55:47 YPTM - armin is on Jul 05 15:00:10 YPTM: Joshua joined Jul 05 15:00:39 YPTM: Richard joined Jul 05 15:00:47 YPTM: Starting Conference now, Saul is Chairing in Stephen's absense Jul 05 15:01:25 * vmeson joined YPTM Jul 05 15:02:41 armpit: I was going to ask you about running a 2.1.1 build Jul 05 15:03:15 k Jul 05 15:03:44 I'm picking up the pieces here.. if there is anything I need to comment on let me know/ping me Jul 05 15:12:06 * zeddii clearly forgot about the meeting .. again. Jul 05 15:14:28 https://wiki.yoctoproject.org/wiki/TipsAndTricks Jul 05 15:14:33 sgw_: ^^ Jul 05 15:14:48 joshuagl: Thanks Jul 05 15:15:43 YPTM: Richard is requesting interesting idea for short blog entries and the wiki page above is the tracking location, please take a look and add any thoughts/ideas you might have Jul 05 16:08:16 is YP is at lsb4 for 2.2 ? Jul 05 16:20:45 armpit: unless someone sends patches for lsb5 yes, and tbh as lsb5 requires SANE… Jul 05 16:21:17 armpit: i'm currently an advocate of either a) keep lsb at 4.1 or b) remove all traces of LSB support Jul 05 16:21:38 honestly, I'm fine with all of lsb5 and simply document we don't support SANE Jul 05 16:21:57 so compliant no -- but 'close enough' for embedded work Jul 05 16:23:13 curious as to who is asking for "something close to lsb" :) Jul 05 16:23:16 in the past a few things in the LSB we've simply ignored if they're not sane for our environment.. primarily around workstation/dkestop loads Jul 05 16:23:19 not really the point of lsb ;) Jul 05 16:23:25 people who look to buy based on checklists Jul 05 16:23:50 "LSB Compatible *" "* All features of LSB 5 other then ... implemented" Jul 05 16:24:10 it is not unusual for a buy sheet to include it has to support LSB Jul 05 16:24:41 often what that really means is the LSB utilities exist, and a verys mall number of libraries exist -- even though the customer builds everything from source and doesn't care about binary compatibility.. Jul 05 16:31:39 I wonder if a separate layer would make sense. LSB is kinda needed for CGL compatible ie another check list Jul 05 16:32:12 i endorse a separate layer Jul 05 16:32:58 well maybe a meta layer that is just packagegroups and maybe a sample distro config, which depends on all the other layers needed to bring in all the bits Jul 05 16:33:00 ah cgl the spec that just won't die ;) Jul 05 16:33:16 like qt[345], sane, etc Jul 05 16:33:16 zeddii, : ) Jul 05 16:36:45 yeah. QT for headless CGL systems Jul 05 16:37:01 :P Jul 05 16:42:00 * armpit adds another task to TODO list Jul 05 16:44:00 there's a bug about lsb5, feel free to add yourself to the CC list with any thoughts Jul 05 16:45:44 YoctoAutoBuilder: shush Jul 05 18:26:14 lsb could be another layer like meta-lsb Jul 05 18:26:53 I'm not against that either.. my only concern is testing.. if it's managed and tested as part of the YP -- no worry.. if it's managed externally.. then I worry it won't get any attention Jul 05 18:28:42 yeah poky could include it in by default **** ENDING LOGGING AT Wed Jul 06 02:59:58 2016