**** BEGIN LOGGING AT Mon Jul 11 02:59:58 2016 Jul 11 03:43:21 Anyone do a core-image-minimalb build for the wandboard-quad lately? In the past that resulting .sdcard image booted out of the box, but now it appears U-Boot's looking for some sort of bootscript to presumably load the FDT and zImage. Jul 11 03:44:15 Just trying to catch back up on what's changed. Doesn't look like the fsl-images class spits out any sort of u-boot.scr to plop on the boot FAT partition Jul 11 03:50:45 This is on krogoth, FWIW. Should have a sanity check back on Jethro in the AM. Jul 11 05:55:40 Hey guys, I think Im missing something, but my header files of a non cmake/autotools-recipes seems not to be installed into staging dir, even thought theyre inside the generated -dev-package. https://gist.github.com/Flow86/150dfbd30f002c39ebdf619142af9a00 Jul 11 05:56:57 sysroot contents are only installed from specific paths Jul 11 05:57:08 only files in ${D}${includedir} get installed into ${includedir} in the sysroot, by default Jul 11 05:57:31 kergoth Jul 11 05:57:36 either install them where they belong, or append to the sysroot_stage_all() function to stage the non-standard path. see staging.bbclass for examples Jul 11 05:57:45 ? Jul 11 05:57:47 ah okay Jul 11 05:58:13 well I tried to install them into ${includedir} but it seems theyre still not populated? Jul 11 06:05:26 kergoth: thank you, sysroot_stage_all was the missing hint! Jul 11 07:37:38 good morning Jul 11 08:29:06 hey all Jul 11 08:35:13 General yocto question Jul 11 08:37:47 I have an image which contains a server (video streaming, but that's irrelelvant for the server) and I would like to "edit" that server's configuration file so the image has a different version than the one in the generated package Jul 11 08:38:13 (the package itself is reused in multiple images, so I can't .bbappend the config file) Jul 11 08:38:23 what is the proper way to do this ? Jul 11 08:38:25 Jul 11 08:39:02 my current idea was to reactivate "do_fetch" in the image recipe, add the config file to the SRC_URI of the image and overide in a postinstall_cmd Jul 11 08:39:13 but that would probably screw up package management Jul 11 08:42:59 having some kind of dummy package containing a script that would be called on postinst to replace/edit the config file? Jul 11 08:43:42 one per image, and installing the proper one... Jul 11 08:43:43 That's what I currently do to customize a package I send on multiple machines, it's far from perfect so if some better idea pops up I would happily try it too Jul 11 08:44:06 doesn't yocto protest if a file is part of multiple packages ? Jul 11 08:44:33 (i.e do you actually override a file, or is there multiple packages providing the same file and only one installed) Jul 11 08:44:37 in my case I just edit the values of my config file Jul 11 08:45:31 right... post-install, not file installation Jul 11 08:45:35 I misread that Jul 11 08:46:12 that will cause problems at package upgrade time, unless the files are also marked as CONFFILES in the main package, though, but that could work Jul 11 08:46:55 yeah that's what I'm fearing too, so my workflow feels quite bad having to install this dummy package on each upgrade too Jul 11 08:47:55 did you mark the file as CONFFILE ? (i'm asking because I don't know how well that feature works... Jul 11 08:48:13 if you did, it's supposed to not be overwritten at upgrade time Jul 11 08:48:13 no, I'll read a bit about this Jul 11 08:48:18 ok Jul 11 08:49:03 that could be useful for me because this configuration shouldn't be updated Jul 11 08:49:15 cool, happy I helped :P Jul 11 08:49:55 yes thanks, that will save me some potential headscratches Jul 11 10:25:14 hi guys Jul 11 11:33:41 Hi Jul 11 11:33:51 Is there a way to restrict a recipe so that it only works on x64 machines? Jul 11 11:35:01 see COMPATIBLE_HOST Jul 11 11:35:36 ross@flashheart ~/Yocto/poky/meta (mut2) Jul 11 11:35:36 $ git grep COMPATIBLE_HOST|wc -l Jul 11 11:35:36 51 Jul 11 11:35:39 plenty of examples :) Jul 11 11:35:59 Thanks! Jul 11 11:37:14 Is there a way to get $BB_TASKDEPDATA of a different task in the same recipe? Jul 11 11:37:26 I have a task that runs before do_configure, but I'd like to read do_configure's dependencies Jul 11 11:38:07 Or maybe I should change my approach; is there a way to inject a task between "dependencies of do_configure are available" and do_configure itself? Jul 11 11:38:23 do_configure[prefuncs] Jul 11 11:38:40 or just do_configure_prepend, depending on what you're doing Jul 11 11:38:53 trying to implement separate sysroots with hardlinks Jul 11 11:39:14 you mean sysroot-per-build? Jul 11 11:39:16 yes Jul 11 11:39:27 with only the declared dependencies available Jul 11 11:39:54 not sure i'd be implementing that without deep hackery in the core classes Jul 11 11:40:00 I guess a prefunc would be better than just do_configure_prepending this Jul 11 11:40:13 you could prepend to prefuncs and hope that nothing else gets there before you Jul 11 11:40:20 not impossible to rule out of course Jul 11 11:40:45 Yeah, that's exactly my concern; ideally there would be a separate task before do_configure so that that doesn't happen Jul 11 11:40:55 But then I don't have all the dependencies that do_configure has, which I need Jul 11 11:40:57 or, just implement it in the core classes Jul 11 11:41:14 so its how the sysroot works instead of bolted on afterwards Jul 11 11:41:27 Basically I'd have to move every DEPENDS to add the dependency to do_prepare_sysroot rather than do_configure Jul 11 11:42:07 what about recipes that stop their do_configure running? Jul 11 11:42:07 I'm trying to do that but still make it optional by having a "write changes to sysroot here" and "read from sysroot here" variable set, but both are the same by default Jul 11 11:42:49 Yeah, this needs to happen in a separate task. do_configure[noexec] = "1" is far too common Jul 11 11:43:20 So I'll just globally add a do_prepare_sysroot task and change DEPENDS to modify that, then make it empty for the non-isolated sysroot case Jul 11 11:43:37 Thanks for being my rubber duck :) Jul 11 11:44:42 :) Jul 11 12:29:02 hey guys, I have another question: I use systemd inside my yocto image added 'less' since without it i.e systemctl status only printed the ansi color codes, and not interpreted them. now they're still wrongly shown. what am I doing wrong here, or does somebody know how to get rid of those color codes inside the pager function of systemd? Jul 11 12:33:39 hi, i have a recipe which fetches the sources from git. i've used SRCREV="sha1" because that seems to be common sense to avoid checking the upstream git repository. so far so good. unfortunately, some (?) tags from the upstream repository are not fetched (and the underlying packet figures out its version by git tags) Jul 11 12:46:06 Flow86 : I use it with --no-pager and the colors do show up in my terminal, I tried and have the same issue within the pager Jul 11 12:48:58 Hi guys, I'm getting the following error: "error: Failed dependencies: /usr/src/kernels is needed by kernel-devel" Jul 11 12:49:12 while trying to deploy a kernel-devel package on a Yocto machine. Any idea on how to tackle this problem? Jul 11 12:53:02 Flow86 : check $SYSTEMD_PAGER Jul 11 13:16:54 anyone here? Jul 11 13:20:14 yeah, jsut ask away Jul 11 13:31:26 I'm looking for the grub config in Yocto Jul 11 13:31:56 I installed a new kernel but it won't show up in the grub menu... Jul 11 13:58:40 mathieu_la: hmm SYSTEMD_PAGER is less, but it seems that that less has some problmes with those ansi colorcodes. --no-pager works fine Jul 11 14:20:02 I seem to have put together some very messed-up packages. according to the dependency explorer, the packagegroup RDEPENDS on it (and also itself, but that also appears with packagegroups I didn't make), but the package doesn't appear in the list of packages on the left. I'm investigating it because building the packagegroup doesn't start building the package - though it does if I do `bitbake $PACKAGE` Jul 11 14:20:37 I'm having some packaging problems relating to REPLACES. It seems opkg does not take it into account, and then complains about the conflicts. Although it installs the new version anyway. Jul 11 14:20:53 After a bit of snooping in bitbake's code, that comes from the depgraph's 'pn' list, rather than the 'rdepends-pn' list Jul 11 14:22:06 I've simply put RREPLACES_pkg-a = "pkg-b (< version)" in the recipe and verified that the information shows up in the ipk Jul 11 14:22:46 * kergoth yawn Jul 11 14:22:55 Flow86: Try less -R Jul 11 14:23:23 Using more instead also works Jul 11 14:26:05 anyway, the end result I'm seeing is that pkg-b is uninstalled (since is is now unused with the updated packages no longer depending on it) but pkg-a is missing my moved files Jul 11 14:26:50 force reinstalling the package solves that, but I wonder what I may be doing wrong to cause this behavior? Any common gotchas? Jul 11 14:31:01 Obviously I don't want to have to hack some force-reinstall stuff into my upgrade process :P Jul 11 14:41:38 gm all Jul 11 14:42:00 so now all qemu machines in OE-core build world for musl Jul 11 14:42:02 https://gist.github.com/kraj/8d0799b348a488bdde8a110ca0536b90 Jul 11 14:43:28 khem: nice, grats Jul 11 14:59:10 I have a package that is refusing to build when I `bitbake $PACKAGEGROUP`. http://pastebin.com/vZZdJXHJ has the package and the packagegroup recipes. I'm doing something slightly perverse, which is why my packagegroup has DEPENDS. Jul 11 15:00:12 hello. due to an upgrade situation with a bunch of changes, i need to mark some debian packages produced by yocto as "Conflicts:" and / or "Replaces:" wrt some other packages. Jul 11 15:01:01 I've tried commenting-out DEPENDS and PACKAGE_ARCH in the packagegroup, and the PROVIDES in the package already. Jul 11 15:01:10 how can i do that in yocto? i seem to remember that there is some way to add arbitrary lines to debian control files... that would sort of do it. ideally there'd be explicit support for conflicts and replaces. Jul 11 15:03:28 just use RCONFLICTS+RREPLACES, which map to Conflicts and Replaces in the deb control file Jul 11 15:13:40 kergoth: you don't happen to know any gotchas relating to that? Jul 11 15:14:14 afaik they're used as is in the binary package metadata, so the capabijlities depend on the package manager you're using Jul 11 15:14:47 maybe I need to look at opkg to understand how and why it works like it does then Jul 11 15:16:44 that would be best, if you're using opkg, yes Jul 11 15:24:41 kergoth: nice, thanks! Jul 11 15:25:13 np Jul 11 15:33:08 RREPLACES and RCONFLICTS are *really* hard to google for some reason... Jul 11 15:33:28 i've found them in the manual now but only with search in page Jul 11 15:34:47 maelcum: have you tried to put them in quotation marks in your search? Jul 11 15:34:55 So Google won't try to autocorrect you Jul 11 15:35:08 https://www.google.com#safe=off&q="RREPLACES"+yocto Jul 11 15:35:14 first 3 links are all appropriate Jul 11 15:35:16 indeed, quote Jul 11 15:36:27 right, that works. Jul 11 15:36:46 i liked google better when it still supported + / - operators :) Jul 11 15:37:17 heh, taht brings back memories of altavista, painstakingly constructing a useful query :) Jul 11 15:37:33 finding anything used to be an art form Jul 11 16:25:53 i used to use AltaVista ;) Jul 11 16:26:28 has anyone done any work with XIP with Yocto/ARM? Jul 11 16:32:45 challinan: I heard people talk about it periodically, then nothing again Jul 11 17:35:38 challinan: heh XIP good old days .. now its coming back for IoT I guess Jul 11 17:35:58 yeah, seems a bit obsolete, right? LOL Jul 11 17:36:28 very hardware dependent, there are usually better ways to get fast boot ;) Jul 11 17:39:42 are you restricted on RAM ? Jul 11 17:42:14 khem: this was more of a generic question posed by someone here. the person asking was thinking more about fast boot than tiny systems. Jul 11 17:43:03 * zeddii remembers tossing XIP patches in the bin .. and being very happy Jul 11 18:04:29 XIP is like credit card :) performance wise you pay later Jul 11 18:16:28 I am seeing a new problem for some weeks now, its more prominent with clang based compiler what I see is that --sysroot option on cmdline does not replace STAGING_HOST dirs properly and what I see is --sysroot= /tmp-glibc/sysroots/qemux86-64 as you can see it has put a space for the ${STAGING_DIR} Jul 11 18:16:40 for more see http://errors.yoctoproject.org/Errors/Details/70740/ e.g. Jul 11 18:17:08 anyone seen this ? Jul 11 18:19:32 weird Jul 11 18:20:33 kergoth: I see it happen on ubuntu 14.04 as well as on centos 7 Jul 11 18:20:47 and usually happens during world builds Jul 11 18:21:28 it could be related to clang playing with TOOLCHAIN_OPTIONS but then it should be deterministic Jul 11 18:23:03 * kergoth plays with pkgconf to see how it does instead of pkg-config Jul 11 18:52:55 khem: hm, i've seen that. Jul 11 18:53:29 dig out the temp/run.do_whatever for the broken task and look at what the shell is. iirc there was something broken there. Jul 11 19:35:47 rburton: I am using dash Jul 11 19:36:43 khem: i mean the script, find the broken line and see what variable is messed up. sure a colleague saw this recently. Jul 11 20:24:34 hi there, is possible via local.conf define that symlinks in deploydir will be created with absolute path? Jul 12 00:00:06 it looks like that missing prefix in sysroot is not repeated when rebuilt however the error which was originally reported still remains and it not connected Jul 12 00:00:14 qemu: uncaught target signal 4 (Illegal instruction) - core dumped Jul 12 00:00:24 which is qemu: uncaught target signal 4 (Illegal instruction) - core dumped Jul 12 00:00:50 so may be its only that its fooling the prints Jul 12 00:01:54 so now i wonder where do we use qemu during builds for gstreamer1.0-plugins-bad Jul 12 00:03:03 bitbake -g should show that Jul 12 00:07:09 yes I see that its inheriting gobject-introspection Jul 12 00:07:17 which does call out for qemu usermode Jul 12 00:07:30 so now I need to see why it fails with clang Jul 12 00:08:11 its possible that some intruction thats now generating by clang in some binary is not understood by qemu Jul 12 00:08:28 and the usermode binary pukes it out **** ENDING LOGGING AT Tue Jul 12 02:59:58 2016