**** BEGIN LOGGING AT Mon Apr 25 02:59:58 2016 Apr 25 03:36:48 yo Apr 25 06:29:58 there was a comment that mesa-gl is supposed to be the "big" gl api provider .. so there it only is PROVIDER for virtual/libgl but is it correct that it also is provider for virtual/mesa ? Apr 25 09:53:21 question about INHIBIT_DEFAULT_DEPS and http://www.yoctoproject.org/docs/2.0.1/ref-manual/ref-manual.html#var-INHIBIT_DEFAULT_DEPS : does this disable runtime dependency detection (e.g. ldd) completely? Apr 25 10:45:12 INHIBIT_DEFAULT_DEPS just stops the recipe having a dependency on gcc glibc etc Apr 25 10:48:56 morning all Apr 25 10:49:46 I'm sure I used to have a command written down that I could use to generate a list of packages used by a recipe and dump out all the licenses of them? Am I imagining that as I don't seem to be able to find it any more... Apr 25 10:55:54 rburton, by the way here are the patches for gpgme-pthread.pc https://mail.gnome.org/archives/commits-list/2016-February/msg07290.html https://mail.gnome.org/archives/commits-list/2016-February/msg07291.html Apr 25 10:56:17 rburton: I'm seeing a race related sstate cache where recipe for binary shared libs with INHIBIT_DEFAULT_DEPS sometimes gets correct libssp etc gcc runtime deps filled in, but sometimes not. Only difference is sstate cache. Apr 25 10:57:21 well don't use INHIBIT_DEFAULT_DEPS on a recipe that uses gcc libs Apr 25 10:57:30 as the entire point of the variable is to remove those deps Apr 25 10:57:45 first but is that the recipe says INHIBIT_DEFAULT_DEPS but is missing libssp but the builds should have failed always but didn't Apr 25 10:57:46 so if you remove the deps but it uses them then you *will* have differing behaviour Apr 25 10:58:15 its very difficult to do a build without gcc being built, so they still likely got built after gcc existed Apr 25 10:58:39 but it could be old gcc before the new one was built Apr 25 10:59:38 /first but/first bug/ Apr 25 11:05:36 to recap, problem isn't building, it's installing to image. Recipe uses INHIBIT_DEFAULT_DEPS but somehow sometimes triggered dependency analysis and correctly added libssp to RDEPENDS and to images. I have two builds locally with same recipes but with different results, one where binary package pulls libssp into image, and one where it does not. Only difference is sstate cache. Apr 25 11:06:43 so the problem is that you a recipe that uses INHIBIT_DEFAULT_DEPS but then links to libssp Apr 25 11:06:57 if you're linking to anything, don't inhibit default deps Apr 25 11:07:35 also, libssp existing or not can depend on what else was built. make the recipe force the choice either way instead of it apparently looking to see if libssp is present. Apr 25 11:10:09 rburton: yes, I'm fixing the recipes and removing all INHIBIT_DEFAULT_DEPS, but I'm still wondering how sometimes dependencies were added despite INHIBIT_DEFAULT_DEPS.. Apr 25 11:10:39 because some build systems look to see what they can find Apr 25 11:10:55 ie the configure might look to see if it can find libssp, and if it can, will link to it Apr 25 11:11:21 if you don't override that autodetection or add say libssp to DEPENDS then whatever is currently in the sysroot will change how the recipe builds Apr 25 11:12:23 rburton: the recipe is for a pre-built $VENDOR binary, with patch, configure and compile tasks set to noexec. Apr 25 11:12:34 oh, fun Apr 25 11:12:37 yep Apr 25 11:12:58 then its probably got a dependency on libssp and whether or not its in the sysroot at build time is changing the linkage, and so the dependencies Apr 25 11:13:19 i bet if you read the package log from a clean sysroot it will say there's a dangling dependency Apr 25 11:14:46 and when deps are not detected, from do_package log I see things like NOTE: Couldn't find shared library provider for libssp.so.0, used by files: path/to/file Apr 25 11:14:56 yeah that :) Apr 25 11:15:35 ideally you DEPEND on all the stuff that your prebuilt binary links to, so the package dependencies get inferred and created properly Apr 25 11:16:12 sigh, yea. So there isn't anything else that we can do? Apr 25 11:16:31 shared sysroot, sigh Apr 25 11:16:38 if you don't want any dependencies created you can turn them off iirc Apr 25 11:16:55 but i'd suggest you depend on the bits the binary uses so the packages you create have proper library dependencies Apr 25 11:18:03 so this a general rule for writing recipes for binaries, always fill in DEPENDS. Apr 25 11:22:07 yes Apr 25 11:25:32 hmm, anyone else seen an off-by-one pattern with sstate cache rebuilds. I had uptodate sstate cache, wiped sysroot, rebuilt my binary only recipe which should only depend on glibc, and I get a glibc recompilation from scratch as a result. Apr 25 11:38:39 in older yocto versions, sstate cache built using a state cache, cached all executed tasks (at least more that now, or at least created symlinks from sstate cache to sstate mirror). But now since 1.7 only last executed task is symlinked from the mirror to sstate cache. Thus if sstate cache is converted into a new mirror, many cached tasks are now lost. If anyone now needs any of the tasks, then a rebuild is Apr 25 11:38:45 triggered. Like that glibc one I described. Apr 25 12:59:36 would be nice to read about how yocto build machinery is using/sharing sstate caches. Maybe our deployment has some design issues. Apr 25 13:42:40 khem: I sent a question on the mailing list regarding a, EGL surface (0x300b) error in Qt when trying to run an app without x11 or wayland. You responded with adding directfb to DISTRO_FEATURES which I had. Do you know of any other reasons why this might happen? Apr 25 14:27:57 Is there a safe way to stop a bitbake build? Apr 25 14:32:04 Ctrl-C once will send it a shutdown signal and it will try to stop the process gracefully. Another Ctrl-C during that shutdown will kill it immediately Apr 25 14:33:25 tjamison: thanks, that is what I have been doing, but just wantd to be sure it is the bst option and does not corrupt the buils Apr 25 14:33:28 build Apr 25 14:34:50 I haven't had a problem with that :D Apr 25 14:36:17 sometimes the second ctrl-c may not clean up correctly Apr 25 14:38:14 ok. got it. Thanks Apr 25 15:17:36 I am getting the following error during the final stage of the image creation http://pastebin.com/pnXxGnye Apr 25 15:20:50 how can I trace where the SYSLINUXCFG variable is being set? Apr 25 15:21:52 http://pastebin.com/WbgRvktX is the failing function Apr 25 15:59:49 khem: could it be something with screen depth and having to export QT_QPA_EGLFS_DEPTH? Apr 25 16:20:34 rburton: ping Apr 25 16:20:50 denix: literally walking away, send a mail Apr 25 16:20:52 ? Apr 25 16:21:08 :) Apr 25 16:21:26 rburton: comment on the mesa thread on ML? Apr 25 16:21:37 oh yeah i said i'd do that :) Apr 25 16:21:52 thank Apr 25 16:21:56 thanks Apr 25 16:24:16 is bluelightning/Paul out for few days? Apr 25 17:19:31 riz__: yes I think you should pass the QT_QPA_EGLFS_PHYSICAL_WIDTH QT_QPA_EGLFS_PHYSICAL_HEIGHT and QT_QPA_EGLFS_DEPTH Apr 25 17:21:04 khem: thanks. I am gonna try that in a minute. Out of curiosity, have you noticed any performance differences between EGLFS direct to framebuffer and using wayland? Apr 25 20:24:52 If I get a build error, "satisfy_dependencies_for: Cannot satisfy the following dependencies", is there any way of ignoring this dependency? Apr 25 20:25:32 It is from a 3rd party binary and I can't just remove the dependency Apr 25 20:46:55 eek Apr 25 20:47:07 * gtristan makes a mess of using git send-email :-S Apr 25 20:47:22 * gtristan will try to just send the emails manually next time Apr 25 21:26:27 zeddii: I have couple of patches for linux-yocto here https://github.com/kraj/openembedded-core/tree/kraj/master/meta/recipes-kernel/linux/linux-yocto Apr 25 21:27:20 zeddii: primarily fixing build with gcc6, ppc one is submitted and looks like will be accepted, mips one I am discussing with Leonid **** ENDING LOGGING AT Tue Apr 26 02:59:58 2016