**** BEGIN LOGGING AT Fri Nov 06 02:59:58 2015 Nov 06 08:30:08 halstead: any update on openembedded-commits ML not working last month? Nov 06 08:30:58 morning all Nov 06 08:32:02 morning Nov 06 08:50:28 good morning Nov 06 09:16:52 otavio: http://errors.yoctoproject.org/Errors/Details/21448/ <— fyi, master is going to have a new gstreamer-plugins-bad upgrade soon and it breaks on meta-fsl as you're patching it Nov 06 09:50:34 hi.. how to enable a systemd socket file in fido? Nov 06 09:52:11 just put it like a systemd service file to SYSTEMD_SERVICE_${PN}? Nov 06 10:09:15 ericbutters: apparently yes, looking at examples in our metadata Nov 06 10:21:34 bluelightning: okay, my .socket file has "WantedBy=sockets.target" in [Install] section, but there is no link created in etc/systemd/system/sockets.target.wants Nov 06 10:22:25 i see links there, i.e for sshd.socket Nov 06 10:22:50 could it be related to file permissions of my .socket file? Nov 06 10:25:44 I'm afraid this is beyond my level of expertise, I don't deal much with systemd myself Nov 06 10:39:44 Hi ! Nov 06 10:40:01 I am wondering how the UBOOT_ENV is supposed to be used Nov 06 10:40:17 it is only present in meta/recipes-bsp/u-boot/u-boot.inc Nov 06 10:40:31 but if I want to include my own uEnv.txt in my u-boot recipe Nov 06 10:40:49 can I overrid this variable and it will install this file in /boot for me ? Nov 06 10:41:37 hi Nov 06 10:41:40 jmleo: looking at u-boot.inc, yes, if you also include the file in SRC_URI Nov 06 10:41:46 rburton: sure; I am aware as I work close of Carlos (dv) Nov 06 10:42:09 rburton: when merging, please let me know Nov 06 10:42:11 bluelightning: ok, will try :) Nov 06 10:42:40 hi yann|work Nov 06 10:44:47 I'm still in the fog wrt using GLES with SDL2. Since sdl was definitely not willing to use its opengles backend in the x11 poky, whether in x11 or on the console, I tried with directfb, but there there is no gl at all :) Nov 06 10:44:51 what am I missing ? Nov 06 10:46:00 (and as a sidenote, the directfb image does not get opkg installed, while the x11 image did not cause any surprise on this point) Nov 06 10:46:32 yann, is this on imx ? Nov 06 10:48:33 no, allwinner A20 (bananapi) Nov 06 10:49:06 Oh, well - mybe this will be useful Nov 06 10:49:10 bluelightning: any example I can look at of building for the host (not the target) ? Nov 06 10:49:17 I tried to use SDL2 with OpenGL ES on i.MX6 and it was a terrible mess Nov 06 10:49:41 Tried to use DirectFB and it was even worse (but DFB on i.MX6 has been dropped recently, guess it never worked for anyone) Nov 06 10:49:52 SDL2 made a lot of annoying assumptions which didn't hold in the imx case. Nov 06 10:49:59 raykinsella78: any recipe which either inherits native or has native in BBCLASSEXTEND, we have a bunch - "git grep" should find them Nov 06 10:50:18 Eventually, I dropped SDL2 alltogether and just wrote my own wrapper ... Nov 06 10:50:31 (which was, ironically enough, much easier and performed way better) Nov 06 10:50:32 hm, the gles driver package has PACKAGECONFIG defs only for x11 and wayland, looks like the directfb idea was a complete mistake :) Nov 06 10:50:41 Yeah, DFB seems dead. Nov 06 10:50:50 both the project as well as support for it Nov 06 10:50:54 rink: I'll keep that in mind ;) Nov 06 10:50:58 good luck! Nov 06 10:51:29 bluelightning: thanks blue Nov 06 10:54:05 ok, even directfb.org has disappeared, now *that* is death :-S Nov 06 10:54:29 yann, I actually liked the idea of DFB Nov 06 10:54:56 but it turned out it was such a mess that it was easier to draw inspiration from SDL2 and code something mysel Nov 06 10:55:03 yes, so do I, no need for a heavy graphics layer if we can do without... Nov 06 10:55:05 * rink notes, our application is full-screen OpenGL ES 2.0 only so ... Nov 06 10:56:35 well, on my side I mostly need to render video frames full screen... Nov 06 10:57:33 rink: you had no problem with getting sdl to really use the gles renderer ? Nov 06 10:57:54 I had a lot Nov 06 10:57:59 which is why I ditched SDL too :-/ Nov 06 10:58:15 But this was mainly because the i.MX6 GLES stuff needed different initialisation Nov 06 10:58:25 and SDL2 doesn't understand how to do I/O if you only have GLES Nov 06 10:58:30 so it doesn't do any Nov 06 11:01:20 * rink thinks SDL2 may not be a good choice for embedded things ,but ymmv Nov 06 11:29:58 rburton: there? Nov 06 11:31:17 yann|work: yes, DirectFB will be officially dropped soon, for i.MX ;-) Nov 06 11:31:36 bluelightning: it seems to be working, as in tmp/work/..../u-boot-/image/boot I have the uEnv.txt file Nov 06 11:31:48 bluelightning: but in my rootfs I don't have it Nov 06 11:32:58 bluelightning: and it is in my tmp/deploy/image too Nov 06 11:33:53 otavio: yo Nov 06 11:34:48 rink, yann|work: directfb re-appeared on github Nov 06 11:37:03 rburton: I am trying to fix the u-boot issue Nov 06 11:37:39 rburton: however it seems to be related to other stuff as I couldn't find a change here which triggers it Nov 06 11:37:55 rburton: mut has binutils change? Nov 06 11:37:59 otavio: yes Nov 06 11:38:02 jmleo: AFAICT the u-boot package needs to actually be installed into your image for that to work - is it? Nov 06 11:38:09 rburton: ahhhhhhhhhhhhh Nov 06 11:38:17 jmleo: (normally I guess it wouldn't be) Nov 06 11:38:30 rburton: I bet 2015.07 dies same way Nov 06 11:38:48 otavio: we'll find out in a bit, i fired another run on the ab with it removed Nov 06 12:46:28 has anyone built yocto on F23? Nov 06 12:46:30 I get: Nov 06 12:46:32 | make[4]: Entering directory '/mnt/ssd/vcs/gnome/gnome-sdk-images/freedesktop-sdk-base/build/x86_64/tmp-glibc/work/x86_64-linux/openssl-native/1.0.2d-r0/openssl-1.0.2d' Nov 06 12:46:32 | /usr/bin/ld: libcrypto.a(sha256-x86_64.o): relocation R_X86_64_PC32 against undefined symbol `OPENSSL_ia32cap_P' can not be used when making a shared object; recompile with -fPIC Nov 06 12:46:37 when building openssl-native Nov 06 13:04:28 how would I ask which recipe depends on a specific recipe ? Nov 06 13:10:01 yann|work: bitbake -g -u depexp Nov 06 13:16:53 joseppc: looks nice, but if I request a virtual package it is not included itself in the package list :( Nov 06 13:19:01 I have bitbake complaining about dup provides for opengles*/egl/mesa/libgl, with wanted sunxi-mali only providing opengles*/egl, so I infer someone pulls virtual/mesa and/or virtual/libgl Nov 06 13:25:07 yann|work: maybe without -u ...: bitbake -g and look at the .dot files directly Nov 06 13:37:42 joseppc: did that already, but it includes every target of the relevant recipes (6000+ lines), making it not so useful - also takes ages to format :) Nov 06 15:03:02 yann|work: the .dot files are most useful to examine directly, not with graphviz. just vim the thing and look around, or grep out what you need Nov 06 15:03:13 also there's bitbake's -I argument Nov 06 15:20:34 denix: is there a good way to silence the numerous file-rdeps qa failures/warnings due to the fact that shlibs is exluded for libGLESv2 & friends? Nov 06 15:21:06 short of disabling that check entirely, that is Nov 06 15:27:37 rink: a SDL2 app should select GLES2 if available when run undex x11 if available, right ? Nov 06 15:35:05 hi, i got one recipe that can not deal with BB_NO_NETWORK=1, i had this this week for an other recipe which was related to SRCREV, but this recipe does not have this, pls see here: http://paste.ubuntu.com/13124996/ Nov 06 15:36:19 i don't suppose anyone knows why libaio uses -nostdlib? Nov 06 15:36:47 access requested with command git -c core.fsyncobjectfiles=0 ls-remote git://git.projects.genivi.org/persistence/persistence-common-object.git (for url None) Nov 06 15:40:08 ericbutters: my guess is you might *need* SRCREV to point at the tag commit, but not certain Nov 06 15:43:55 kergoth: i tried that Nov 06 15:44:24 SRCREV="${PV}" Nov 06 15:44:29 i am going to retry Nov 06 15:46:08 patchwork really needs a search function Nov 06 15:46:15 i'm sick of doing a browser find in each page Nov 06 15:53:35 jmesmon: ping if you have some time to talk meta-rust Nov 06 15:53:48 jmesmon: feel free to /query me. Nov 06 15:54:31 Wondering if anyone's seen an error like http://paste.pound-python.org/show/u0J1YBmENInkCBHZV46p/ before? Nov 06 15:54:49 I've added https://github.com/jmesmon/meta-rust to my BBLAYERS and I'm seeing that. I'm using fido for all the other bits. Nov 06 15:57:06 Cardoe: SPDXLICENSEMAP is defined in licenses.conf in oe-core, and the use of it is done in license.bbclass in oe-core. doesn't have anything to do with rust Nov 06 15:57:16 sounds like your layers are either corrupted or have mismatched branches Nov 06 15:57:29 unless meta-rust is overriding a class or config file from the core Nov 06 15:57:42 ah, yes, it is Nov 06 15:57:44 that explains it Nov 06 15:57:46 https://github.com/jmesmon/meta-rust/blob/master/conf/licenses.conf Nov 06 15:57:49 ah Nov 06 15:57:51 it's preventing conf/licenses.conf in oe-core from being parsed Nov 06 15:57:56 remove that file to work around it Nov 06 15:58:26 and probably open a bug in the github issue tracker for the layer :) Nov 06 15:59:01 I guess there's a proper way to do that behavior Nov 06 16:00:22 what they're doing in that .conf is really a distro decision, doesn't belong defined by the layer at all Nov 06 16:00:40 makes me wonder what other questionable stuff is in that layer, honestly.. Nov 06 16:01:05 YOCTOERS: Has anyone noticed on busybox vi (version 1.23.1) that commands/escape sequences are slow to respond? Has anyone seen this or fixed it? Nov 06 16:01:12 Definitely could be some other stuff but unfortunately I don't see any other layers that have Rust support. Nov 06 16:06:51 kergoth: is there a supported way for a layer to say that a license has to be accepted for the layer to be used? Nov 06 16:07:23 that really doesn't make sense. the variable it's setting in licenses.conf isn't about accepting the license, it's telling the old src_distribute class that when you use it to populate sources for license compliance, include that license Nov 06 16:07:55 but 1) we don't use those classes anymore, 2) that decision about what licenses you want sources for is *not* a layer choice, it's a distro decision Nov 06 16:08:13 ok so plain old removal is the best approach Nov 06 16:08:15 it's clear that layer was created against an older yocto release, i'd be curiosu to know which one, since generally we don't expect mixing branches to work Nov 06 16:08:16 yep Nov 06 16:08:56 yeah I'm trying to ask the author as well. Nov 06 16:09:04 I've pinged him here in this channel since he's idling here as well. Nov 06 16:09:42 I'm unfortunately fairly new to Yocto so I'm still in learning mode. Nov 06 16:09:48 would be really nice if he could add the layer to the layer index also... Nov 06 16:11:09 ugh, my devshell is *completely* broken. tmux doesn't work, screen doesn't work, xterm spawns but then the task exits leaving it running (weird, but okay, maybe that was on purpose?) Nov 06 16:11:18 anyone else hitting this? Nov 06 16:11:37 close to master/jethro HEAD (couple weeks behind), on 14.04 Nov 06 16:12:07 works here, but that's on F21 with screen Nov 06 16:12:34 mine does the thing hwere it shows like 12 messages about trying to connect with screen -r and then exits Nov 06 16:12:42 same with tmux Nov 06 16:12:50 I have to say when I've tried to debug the terminal code I've always been a bit frustrated by how hard it seems to be to find the actual error output Nov 06 16:13:09 that's an aside though Nov 06 16:13:12 it seems like a fair bit of its output is not included in the task log at all. don't know how it's managing that, but that's bad Nov 06 16:14:15 the odd thing is, i dont think there've been recent changes to terminal, devshell, or hte LogExecTTY stuff Nov 06 16:14:20 so i'm confused Nov 06 16:14:30 * kergoth tries a different machine Nov 06 16:23:54 kergoth: heh I've read that EXTRA_OEMAKE patch completely backwards.. Nov 06 16:24:19 kergoth: only after reading your reply I've realized that I also want to remove -e from default value Nov 06 16:25:02 that's what happens when people reply to e-mails before first morning coffee Nov 06 16:26:17 the thing is, makefiles will always pick up environment vars, just -e makes env vars *overwrite* the base values in the makefiles. of course, the makefile can use += to add to it anyway. that's why we pass MAKEFLAGS=, to make sure we don't lose those. e.g. FOO=bar in env, toplevel makefile does FOO += baz, you'd expect the child processes to include baz, but if -e flows into submakes, they'd get blown away by the environment again, and it'd end up just Nov 06 16:26:17 bar Nov 06 16:26:22 not pleasant :) Nov 06 16:26:33 better to just pass what we need explicitly for this particular buildsystem Nov 06 16:26:46 * kergoth feels bad for having set the default the way he did :) Nov 06 16:26:53 hindsight is 20/20 though.. Nov 06 16:29:44 too true Nov 06 16:47:36 ugh. touched ASSUME_SHLIBS, watched every recipe rebuild Nov 06 16:55:57 kergoth: should only be repackaging from what I can tell Nov 06 16:56:32 hmm, yes, that should be the case, ibut it's not, i wonder why Nov 06 17:41:53 kergoth: package_do_shlibs should have been the only task chaning the sigs Nov 06 17:42:10 I wonder if its changing ASSUME_PROVIDED somehow Nov 06 17:42:24 package_do_shlibs means re-run do_package which means re-running every task leaning up to it if you had a build directory that was buitl from sstate, since there's no do_install sstate, only do_package and later Nov 06 17:42:26 :) Nov 06 17:42:30 s/leaning/leading/ Nov 06 17:43:51 if we change ASSUME_SHLIBS I guess ipks need to be regenerated right ? Nov 06 17:44:17 sstate shunts that task I see Nov 06 17:44:44 if do_package changes, every task depending on it has to be re-run, inclduing do_package_write*, yes Nov 06 17:45:11 trying to silence the crapton of warnings that show up using meta-ti Nov 06 17:45:18 * kergoth rolls eyes Nov 06 17:45:29 I think the behavior is ok Nov 06 17:45:43 what warning do u see from meta-ti Nov 06 17:46:38 kergoth: patches are welcome :) Nov 06 17:48:23 khem: hundreds of file-deps failures for a bunch of X libs coming from libs in the non-x11 libgles-omap3, plus all the libs listed in PRIVATE_LIBS (libGLES, etc) Nov 06 17:48:42 haven't nailed down the root cause of the latter, but it's an oddball recipe to begin with Nov 06 17:50:30 tempted to just disable file-rdeps entirely for this machine as a temporary hack Nov 06 19:23:47 Cardoe: regarding meta-rust: I haven't seen that error before. I'm also not very yocto-savy :) Nov 06 19:24:12 kergoth: and I'm sure I'm doing lots of funky things in meta-rust Nov 06 19:31:15 jmesmon: I've send you to pull requests to fix the issue. Nov 06 19:31:45 s/to/two/ Nov 06 19:33:31 jmesmon: I've created a new branch called fido and I'm going to do my best to support fido since that's what I'm using. Nov 06 19:35:32 sounds fine to me. Nov 06 20:40:39 does anyone know if ldconfig-native should scan dir other than the ones hardcoded? ie /opt/lib Nov 06 20:40:58 i'd expect it to obey the ld.so.conf in the sysroot / rootfs Nov 06 20:41:10 so you'd have to add to that to get other paths scanned Nov 06 20:41:37 that said, using that to handle paths like that is not ideal. just make sure rpath is appropriate for stuff built in non-standard paths, so they can find their own libs on their own Nov 06 20:41:45 ideally using $ORIGIN Nov 06 20:42:49 kergoth, since its run native the path is absolute or relative ? Nov 06 20:43:12 /home/akuster/oss/maint/mylayers/poky/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/lib/opt Nov 06 20:43:16 i don't understand the question. we wouldnt' run it at all if we ccouldn't point it into our rootfs Nov 06 20:43:25 or just /opt/lib Nov 06 20:43:42 ld.so.conf would have /opt/lib in this case Nov 06 20:44:25 hmm, will give that a try Nov 06 20:48:33 kergoth, thanks. that work Nov 06 20:48:52 np Nov 06 20:52:17 Hi, any experts on populate_sdk here, I'm having an issue getting this working with fido and debian packages. Nov 06 21:00:12 I'm getting E: Unable to locate package nativesdk-packagegroup-sdk-host Nov 06 21:02:00 find gives me 3 debian packages that match in deploy/deb/i686-nativesdk Nov 06 21:02:05 work/i686-nativesdk-biasdk-linux/nativesdk-packagegroup-sdk-host/1.0-r12/deploy-debs Nov 06 21:02:15 and work/i686-nativesdk-oesdk-linux/nativesdk-packagegroup-sdk-host Nov 06 21:12:57 Works when I switch to ipk. The ipk has i686-nativesdk.ipk but the debian package has the target arch (armv7ahf-vfp-neon.deb) Nov 06 21:15:23 I do have DPKG_ARCH ?= "armv7ahf-vfp-neon" in my local.conf. Nov 06 22:24:27 I blew the build away and removed DPKG_ARCH ?= "armv7ahf-vfp-neon" and it was fine. I'll ry putting it back in. Nov 07 00:02:46 Hmm, I want to depend on the do_package_write* pulled in by an image's do_rootfs task, but i don't want to build the do_rootfs task Nov 07 00:02:59 not sure this is doable. I was expecting recideptask to do the job, but not quite Nov 07 00:03:50 oh well, easy enough to work around, just let it run do_rootfs, but was hoping it was a possibility **** ENDING LOGGING AT Sat Nov 07 02:59:59 2015