**** BEGIN LOGGING AT Thu Jan 12 03:00:01 2017 Jan 12 06:25:17 Hi! I have a general question for process management. I have a C++ file and execute it in boot with Yocto. I use to run a command for playing audio with GStreamer. It's working but, I need to stop this process in some cases. So I have to kill process. How can I stop a process while its running? Jan 12 06:31:48 Geera: the simplest option is probably to sind the process SIGTERM/SIGKILL Jan 12 06:35:35 I am getting this issue ERROR: Nothing RPROVIDES 'qtwebengine' Jan 12 06:36:17 but I have recipe file qtwebengine_git.bb placed in meta-qt5/recipes-qt/qt5 Jan 12 06:37:17 and meta-qt5 is placed in build/conf/bblayers.conf Jan 12 06:37:46 how can I get qtwebengine gets compiled and packed into rootfs ? Jan 12 06:40:59 Ramose: add it to your IMAGE_INSTALL Jan 12 06:42:28 LetoThe2nd : I tried adding to build/conf/local.conf as IMAGE_INSTALL_append = " qtwebengine" Jan 12 06:42:40 but still seeing same error messages Jan 12 06:43:30 Ramose: and did you verify that it actually gets built? bitbake -e your image maybe Jan 12 06:43:42 yes Jan 12 06:43:52 bitbake imagename Jan 12 06:45:32 Ramose: i presume you are using a machine that supports qtwebengine? (https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtwebengine_git.bb#L49) Jan 12 06:46:34 nrossi; Yeah its arm machine Jan 12 06:47:56 nrossi: CPU type is ARM Cortex™-A9 Jan 12 06:48:54 Ramose: that should be fine as long as you are using the meta arm includes Jan 12 06:56:57 nrossi: its there in bblayers.conf also other packages like qtwebkit gets compiled Jan 12 06:57:08 but not qtwebengine Jan 12 06:57:31 hi Jan 12 06:57:48 I get error when I do Jan 12 06:57:49 bitbake-layers layerindex-show-depends meta-openembedded ERROR: Cannot get BBLAYERS_LAYERINDEX_URL Jan 12 06:58:09 Ramose: and if you "bitbake qtwebengine" does it build? Jan 12 06:59:59 nrossi: https://paste.ubuntu.com/23785606/ Jan 12 07:02:46 Ramose: well there you go, the issue is the License. Are you setting license restrictions in your build? Jan 12 07:03:29 nrossi: sorry but how do I check it ? Jan 12 07:04:57 nrossi: COPYLEFT_LICENSE_INCLUDE ? Jan 12 07:07:31 Ramose: I'm not entirely familiar with all the license tools in oe. But the error you are getting is due to "INCOMPATIBLE_LICENSE". Check its value in bitbake -e Jan 12 07:08:21 ok. Jan 12 07:15:46 LetoThe2nd: This Process ID changing in every boot up. Jan 12 07:16:10 Geera: um, so what? Jan 12 07:16:25 nrossi: bitbake -e INCOMPATIBLE_LICENSE gives me nothing Jan 12 07:16:30 Ramose: also, just reading the license string in the recipe. It seems wrong, since it says "LGPL AND GPL AND BSD..." which seems odd. I would have expected something like "(LGPL AND BSD) OR GPL..." Jan 12 07:16:56 but I could see here few things Jan 12 07:16:57 build/tmp/deploy/licenses/ Jan 12 07:17:04 Geera: there is stuff like pidof or pgrep. still its an ugly solution. Jan 12 07:17:49 Geera: I personally would have the process open some kind of communication channel, and wait for an abort command there. then cleanly abort and close all ressources. Jan 12 07:18:48 LetoThe2nd: I'm using a C++ file for playing audio. Like system("gst-launch-1.0 ..... ") command. Some special case I need to kill process while its running. Jan 12 07:19:07 Geera: i don't get the problem. Jan 12 07:23:25 nrossi: ok, I think its getting compiled now Jan 12 07:27:03 nrossi: just replaced the LICENSE = "LGPL-3.0 & BSD" with LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 | LGPL-3.0)" Jan 12 07:27:22 nossi: does it look ok to you ? Jan 12 07:27:26 If I use SIGKILL command, I need to know Process ID. But I dont know the ID before boot up. I use SIGKILL command in c++ file so how can I use this command without ID? A button pressed, play audio. B button pressed, stop audio. After then if A button pressed, it must play audio again. Jan 12 07:28:00 I'm very new to Yocto, thanks for helping me. Jan 12 07:28:45 Ramose: Seems fine, though I would send a patch for the layer. And also check the proper licensing agreement to be safe (if you are distributing a product with this) Jan 12 07:29:06 nrossi:sure. Jan 12 07:30:22 nrossi: if you like you can have mine tested-by or reported-by ;) Jan 12 07:31:15 Ramose: you can submit the patch, I don't use QT stuff :P Jan 12 07:32:31 nrossi: sure , I love to but for better understanding I still didn't get the difference between LICENSE = "LGPL-3.0 & BSD" and LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 | LGPL-3.0)" ;( Jan 12 07:32:54 Geera: this is totally not yocto related at all. if button b is pressed, find the process id and kill it. there are ways to find process ids given some criteria, and two means i already mentioned are pidof and pgrep Jan 12 07:34:08 nrossi: I mean why did expect this "It seems wrong, since it says "LGPL AND GPL AND BSD..." which seems odd. I would have expected something like "(LGPL AND BSD) OR GPL..." " ? Jan 12 07:34:40 Geera: yet thing probably get way easier if you wouldn't call system(), but directly use the c++ api of some library to play your media Jan 12 07:36:17 nrossi: oh sorry , I mean why did *you* expect this Jan 12 07:36:21 Ramose: well the AND operator implies both licenses are applied together, as in you must comply with GPL and LGPL. However that pointless, since LGPL is intended to be used in place of GPL, so i would have expected it to be GPL or LGPL. Jan 12 07:37:45 nrossi: ok, got your point . Jan 12 08:12:00 is there any way I can force build a package Jan 12 08:12:45 I mean need to run bitbake qtwebengine again Jan 12 08:13:58 Ramose: You can use -f to force a task to run Jan 12 08:14:41 nrossi: bitbake -f qtwebengine, like this ? Jan 12 08:18:29 nrossi: earlier when I run "bitbake qtwebengine" I got qtwebengine folder in /home/build/tmp/work/cortexa9hf-vfp-neon-mfr-linux-gnueabi Jan 12 08:19:20 nrossi: but now when I run it again I couldn't find qtwebengine folder at same path( I just deleted it after first compilation) Jan 12 08:19:27 Ramose: "-f" requires a specific task, like "-f -c compile" ... Jan 12 08:20:09 ok let me try this bitbake -f -c compile qtwebengine Jan 12 08:20:51 jku: Thanks, got it again Jan 12 08:21:29 jku : but its almost empty folder Jan 12 08:21:57 jku; is it required fetch nd all that ? Jan 12 08:22:44 Ramose: "-c cleansstate" (and then building normally) is often useful if you want to be sure you have all the artifacts in the workdir Jan 12 08:24:40 jku: ok, fine. Jan 12 08:25:05 note that when you do "-f -ccompile recipe" it only does the compile step, not e.g. packaging (you'll have to "bitbake recipe" for the default task) Jan 12 08:34:33 from time to time I get task-hash mismatch on do_configure in my custom linux and u-boot recipes. Any pointers on how to debug it? Jan 12 08:35:10 I been looking around in temp/run.do_configure, but nothing time-related in there Jan 12 08:37:11 hundeboll: try bitbake-diffsigs, might be able to tell you what is causing the hash to change Jan 12 10:33:11 hey everyone Jan 12 10:33:32 I'm trying to use devtool to use a c library in my bbb Jan 12 10:33:37 this one https://github.com/vsergeev/c-periphery Jan 12 10:34:15 but when I run "devtool build c-periphery" Jan 12 10:34:46 I get "OSError: [Errno 13] Permission denied: '/../dl'" Jan 12 10:41:59 anyone? https://paste.debian.net/908390/ Jan 12 10:55:13 | sed: warning: failed to get security context of /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/work/i586-poky-linux/lttng-tools/2.9.3-r0/image/usr/lib/lttng-tools/ptest/tests/Makefile: No data availableinstall: failed to access ‘/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/build/tmp/work/i586-poky-linux/lttng-tools/2.9.3-r0/image/usr/lib/lttng-tools/ptest/tests/destructive’: No such file or dir Jan 12 10:55:16 argh Jan 12 11:00:32 * ed2 surprised that there is no way to call python function from shell function in .class Jan 12 11:16:47 rburton: ping Jan 12 11:17:07 rburton: I submitted https://patchwork.openembedded.org/patch/135074/ and https://patchwork.openembedded.org/patch/135074/ Jan 12 11:17:14 on which I got some feedback from you Jan 12 11:17:51 and then submitted https://patchwork.openembedded.org/patch/135208/ and https://patchwork.openembedded.org/patch/135209/ Jan 12 11:18:02 to address your comments Jan 12 11:18:19 haven't seen any movement on these since... Jan 12 11:18:28 yeah theyre in the queue Jan 12 11:18:37 great then Jan 12 11:18:42 rburton: thanks :) Jan 12 11:35:13 guys, I need some help appending my own defconfig. I dont understand why it doesnt work, it's only an appending isnt? Jan 12 11:36:35 appending patches doesn't work neither, throwing error moreover Jan 12 11:41:36 http://pastebin.com/EgV4Xexz Jan 12 11:45:09 aV_V: what is in your extended layer layer.conf? Jan 12 11:45:26 aV_V: does it tell it there are bbappend files? Jan 12 11:46:30 RP: I think so. http://pastebin.com/yWwUX8p9 Jan 12 11:46:43 aV_V: bitbake-layers show-appends can be helpful Jan 12 11:47:26 aV_V: looks ok... Jan 12 11:47:57 aV_V: try show-appends, see if yours is listed Jan 12 11:49:05 RP is there, I also checked if defconfig is set, and it doesn't. But when I build, I just dont see expected changes Jan 12 11:49:18 it does set* Jan 12 11:51:58 aV_V: so bitbake linux-compulab -e | grep SRC_URI= -C 10 (or similar) shows defconfig in your SRC_URI variable? Jan 12 11:54:36 Hmm Jan 12 11:54:51 it doesnt appear my bbappend Jan 12 11:55:14 aV_V: I wonder how linux_compulab sets SRC_URI Jan 12 11:55:30 aV_V: you could try SRC_URI_append = " file://..." Jan 12 11:55:45 _append is a little harder for the system to override Jan 12 11:55:59 will try Jan 12 11:56:28 Now appears! Jan 12 11:57:14 will try appending patches too Jan 12 12:25:56 joshuagl: the reason loading tests is so slow is: selftest/base.py: self.distro = get_bb_var('DISTRO') Jan 12 12:26:16 can anyone spot where that is actually used? Jan 12 12:26:41 rburton: Jan 12 12:26:49 selftest/runtime-test.py: if self.distro == 'poky-tiny': Jan 12 12:27:03 but that can be moved Jan 12 12:28:47 rburton: hmm, my grep skills clearly failing me Jan 12 12:28:54 RP: its only in mut :) Jan 12 12:29:02 rburton: ah Jan 12 12:30:08 patch incoming Jan 12 12:31:22 rburton: thanks Jan 12 12:31:33 hi everyone Jan 12 12:32:03 did anyone ever heard about webrtc on yocto/openembedded? Jan 12 12:33:11 rburton: makes an amazing difference to loading speed Jan 12 12:39:31 RP: i can imagine! Jan 12 12:40:08 aurele: do you mean, has anyone used webrt on oe? Jan 12 12:40:11 RP: ross: should we cache results of get_bb_var to avoid running bitbake every time? functools.lru_cache? Jan 12 12:40:59 ed2: i expect some tests read the value, write a config fragment, read the value, etc. Jan 12 12:41:28 ed2: memory resident is the way forwards: just replace the bitbake -e shell call with a RPC call to bitvake Jan 12 12:42:50 ed2: right, memory resident bitbake is the way forward for this Jan 12 12:46:01 rburton, yep this could be the question, I could not find any receipe Jan 12 12:46:30 aurele: chromium? Jan 12 12:46:49 gstreamer? Jan 12 12:47:33 rburton, , pulseaudio-8.0 can use it also, but you have to build webrtc first no? Jan 12 12:47:40 * rburton shrugs Jan 12 12:49:58 rburton, anyhow I just read about a webrtc-audio-processing for pulseaudio Jan 12 12:50:19 rburton, maybe this will be easier to get Jan 12 13:24:55 ed2: I could use your help in fixing wic to work with recipe specific sysroots Jan 12 13:26:00 RP morning.. I see some reds on 2.2.1 but I did receive mail to start QA... what is the status ? Jan 12 13:26:55 RP: sure, I'll be glad to help. Jan 12 13:28:16 JosePerez: good question, the AB auto sends that when the build completes then we need to make a decision Jan 12 13:29:04 JosePerez: the nightly-arm looks like a random failure we've seen before which happens rarely (smart issue), the ESDK one worries me more, I think we're missing a patch for that. The checkuri one I have a patch ready to backport Jan 12 13:29:16 JosePerez: not sure what to do. Jan 12 13:29:42 joshuagl, armpit: any opinions? Jan 12 13:36:07 hmm, that eSDK one looks interesting. There are several ERRORs then a bunch of backtraces, I wonder if later tests rely on earlier tests succeeding Jan 12 13:36:51 joshuagl: I;'m sure we ran into this and have fixes in master Jan 12 13:37:05 joshuagl: I think it was a patch from ed2 Jan 12 13:37:14 RP: oh, neat. I just checked and that test suite doesn't appear to differ between morty and master Jan 12 13:38:16 ed2: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip-rss is my recipe specific sysroots branch. If you run the wic tests there you'll see the failures that need fixing Jan 12 13:38:26 hi all Jan 12 13:38:35 ed2: the trouble is there is now no common location for wic to find the tools in :/ Jan 12 13:38:48 hmm, did we backport uninative fixes to morty? Jan 12 13:38:57 joshuagl: yes :/ Jan 12 13:39:02 joshuagl: but not all of them Jan 12 13:40:13 ed2: there is now a "build-sysroots" target which combines all the output back into a common sysroot and we use that for the eSDK but I'm not sure how we could make wic rely on that. The alternative is a recipe specific sysroot. build-sysroots doesn't have any dependencies Jan 12 13:40:26 (deliberately) Jan 12 13:45:11 RP: currently wic gets native sysroot path from either command line or from STAGING_DIR_NATIVE Jan 12 13:45:59 RP: is it enough to change this logic to get common sysroot patch instead or something more sophisticated is needed. Jan 12 13:46:02 ? Jan 12 13:53:10 ed2: there is no common sysroot path anymore Jan 12 13:53:20 ed2: each WORKDIR has its own sysroot Jan 12 13:53:53 and each sysroot is constructed for a specific set of dependencies Jan 12 13:56:58 RP: I see a couple of related bugs, just trying to replicate locally Jan 12 13:57:46 RP: about my issue above. Now patches applies, but not the defconfig. Jan 12 13:58:13 this is the original recipe: https://github.com/compulab-yokneam/meta-compulab/blob/krogoth/recipes-kernel/linux/linux-compulab_4.1.15.bb Jan 12 13:58:53 and this is what I did http://pastebin.com/euvtvNde Jan 12 13:59:04 RP: is there any info about recipe specific sysroots? Is wic the only tool that runs native tools? Jan 12 13:59:08 I also tried changing the machine override Jan 12 14:01:12 ed2: There is info that I previously sent to the arch list but I've not gotten to docs yet. wic is one of the few things that does this externally, yes Jan 12 14:02:12 aV_V: very hard to say without looking into the includes and seeing how that kernel generates its config by default Jan 12 14:02:50 this is the include used https://github.com/compulab-yokneam/meta-compulab/blob/krogoth/recipes-kernel/linux/linux-compulab_cm-fx6-evk.inc Jan 12 14:06:24 aV_V: i think you might be getting caught by the fact that the kernel recipe uses overrides to get the path for the defconfig. And those overrides have a higher priority than no-override. Jan 12 14:08:23 nrossi: bad news for me then :( Jan 12 14:08:51 aV_V: not really, just put your defconfig in a "cm-fx6-custom" directory and your machine should win out :) Jan 12 14:12:47 guys....is there a "common way" to realize ReadOnly embedded devices? I mean... i wanna use just an sdcard to store configuration and whatever of my custom device with yocto. I'd like to lock the internal memory of the device for data loss protection. Is there a well known procedure? Jan 12 14:13:22 nrossi: did it, but I dint see the changes. Maybe I'm doing wrong the process to test it. Jan 12 14:13:27 What I do Jan 12 14:13:53 1. cleansstate 2. preconfig 3. menuconfig Jan 12 14:15:24 aV_V: look at the "log.do_unpack" of in the workdir of your kernel. See if its pulling defconfig from the right place Jan 12 14:17:57 MrBrown: have a look at http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-a-read-only-root-filesystem Jan 12 14:25:24 nrossi: finally, I fixed it. At first I did what u told me, I created a sub-directory containing the defconfig and patches. THe problem was that I specified that sub-directory on FILESEXTRAPATHS_prepend, but it must be on SRC_URI instead Jan 12 14:25:43 thanks nrossi and RP :) Jan 12 14:26:58 aV_V: Well if that works for you, great :). I did however mean move defconfig to ${THISDIR/${PN}-${PV}/cm-fx6-custom/deconfig without changing anything in the recipe. Jan 12 14:28:46 RP: does RECIPE_SYSROOT_NATIVE directory contains native tools that wic can call? Jan 12 14:28:52 nrossi: yes, is what I did. Sry I'm not expressing well. I mean that I did FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}/cm-fx6-custom:" but that doesnt work Jan 12 14:29:10 and I did SRC_URI_append_cm-fx6-custom += "file://cm-fx6-custom/defconfig" Jan 12 14:30:09 RP: I think I didn't fully get what's the difference between current and recipe specific sysroots in terms of native tools. They look similar to me. Jan 12 14:33:47 with a little bit of shame, i discover today that wonderful resource that the Yocto Dev Manual is Jan 12 14:33:51 O_O Jan 12 14:34:55 Talorno: wait until you discover the "mega-manual" :) Jan 12 14:35:01 wwwwhaaaat? Jan 12 14:35:06 you tell me! now! :D Jan 12 14:35:26 Talorno: http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html :D Jan 12 14:36:21 OH-MY-GOD. Jan 12 14:36:29 nrossi, i may fall in love with you Jan 12 14:37:12 RP joshuagl so an 2.2.1 rc2 is the option ? Jan 12 14:37:21 ed2: yes, RECIPE_SYSROOT_NATIVE contains native tools you can call Jan 12 14:37:45 ed2: the difference is that only things which are direct dependecies of the recipe in question are included there Jan 12 14:37:54 ed2: so wic would have to know a specific recipe was built Jan 12 14:38:09 ed2: if we can know that, we can just use this path Jan 12 14:38:22 JosePerez: I think we need to understand this eDSK failure, yes Jan 12 14:38:44 rburton: any thoughts on the morty eSDK failure. I'm having trouble deciding which patch caused that :/ Jan 12 14:38:54 rburton: the fix I thought we needed from you is in Jan 12 14:39:17 * rburton looks Jan 12 14:40:09 that output isn't very helpful is it Jan 12 14:40:17 RP: currently wic complains if it doesn't find native tool and user has to build it. Is it possible to do for recipe specific native sysroot? Jan 12 14:42:23 RP: do you mean that required tool can be built, but to find it wic have to look at all available recipe specific native sysroots? Jan 12 14:44:12 ed2: perhaps we need a wic-tools recipe/target which builds a sysroot containing the tools we need? Jan 12 14:44:36 hm Jan 12 14:44:44 RP: odd Jan 12 14:45:22 only happened on two of the buildsets Jan 12 14:45:35 rburton: machines with ccache on maybe? Jan 12 14:45:45 only happened on the centos machine Jan 12 14:45:56 rburton: hmm Jan 12 14:46:08 but if PATH was set correctly it should have just worked Jan 12 14:46:29 RP: yes, that will work. However, those tools may be already built for other recipes. So it would impact performance, disk space, etc. Jan 12 14:47:41 RP: rburton I reproduced locally andhave ccache, trying again with ccache removed Jan 12 14:48:18 ed2: ah, this is where the implementation comes into play. It will reuse them, they're created from hardlinks Jan 12 14:50:04 RP: that's cool! ok, let's go the way you propose: let's have wic-tools or recipe for this. Jan 12 14:50:36 ed2: that works Jan 12 14:51:03 RP: great! Jan 12 14:51:44 RP: how wic should get path to wic-tools native sysroot? Jan 12 14:52:17 ed2: It will be WORKDIR/recipe-sysroot-native Jan 12 14:53:41 RP: some tools like parted are unconditional dependency, but most of tools are not always used. It depends on plugins used in wks, type of bootloader, type of partition table etc. Jan 12 14:54:05 ed2: that is going to be more of a problem :/ Jan 12 14:54:28 ed2: the recipe would need to know which tools to build and put in this sysroot Jan 12 14:55:21 RP: generally it's not possible as it depends on wks content, that can be changed by user anytime. Jan 12 14:55:55 RP: as a workaround we can build all possible tools. Jan 12 14:56:07 ed2: that may be what we need to do then Jan 12 14:56:09 RP: the amount is not that big. Jan 12 14:56:34 RP: ok. how and when you want me to implement it in wic? Jan 12 14:57:28 RP: can you point me to your branch I can play with? Jan 12 14:57:31 ed2: I want to create a recipe system sysroot branch that works on the autobuilder including oe-selftest so I could really do with patches for my branch Jan 12 14:57:41 ed2: I gave you a branch earlier? Jan 12 14:58:28 RP: it's mentioned in your e-mail. http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip-rs, right? Jan 12 14:58:55 ed2: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip-rss Jan 12 14:59:07 ok, thanks. Jan 12 14:59:34 pohly: I put a specific task event in that series too btw Jan 12 14:59:59 pohly: I want to better define what that event means and what such a handler should/shouldn't do Jan 12 15:00:14 RP: do you want me to make wic oe-selftest pass? When? Jan 12 15:00:40 ed2: please, sooner than later if possible Jan 12 15:00:52 ed2: the rss work is due for M2 Jan 12 15:02:17 RP: RecipeTaskPreProcess I suppose. I'm curious about that extended documentation and how you intend to handle potential conflicts when rm_work.bbclass adds do_rm_work in that events. Jan 12 15:02:48 As I said in my email, I think the same ordering problem still exists, just at a smaller scale. Jan 12 15:02:49 pohly: I'm going to propose it *not* add/remove tasks, only change their dependencies Jan 12 15:03:41 pohly: basically we minimise the cross section of problem to be small enough that if it ever happens, the handlers would likely have to be taught about each other Jan 12 15:04:40 Fair enough. Jan 12 15:05:18 So initially, the only user would be rm_work.bbclass? Jan 12 15:05:25 pohly: and my rss code Jan 12 15:05:35 RP: ok. I'm finishing my work on bug #10835. After that I'll try to do that. Is it ok if I start on Monday? Jan 12 15:05:36 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=10835 normal, Medium, 2.3 M3, eduard.bartosh, IN PROGRESS DESIGN , WIC should not rely on hddimg creation for finding all needed artifacts Jan 12 15:05:40 pohly: thankfully the rss code won't conflict Jan 12 15:05:48 RP: how will those two cooperate? Jan 12 15:06:09 pohly: they shouldn't conflict Jan 12 15:07:04 rm_work.bbclass does an "addtask do_rm_work before do_build", and in the event adds all other tasks as dependencies? Jan 12 15:07:16 pohly: yes Jan 12 15:07:51 pohly: I want the event to have a list of tasks but not the internals of __BBTASKS like it does in my branch Jan 12 15:08:29 I'm not sure what we get from requiring that do_rm_work gets added without proper dependencies - that part seems a bit overly complicated to me. Jan 12 15:09:18 pohly: it means that the list of tasks is complete when the event is fired Jan 12 15:09:21 We do ensure that the *list* of tasks is correct at the time that the event fires, but not their dependencies - is that why? Jan 12 15:09:27 pohly: yes Jan 12 15:09:39 Okay. Jan 12 15:09:40 pohly: that seems a sane API guarantee to make now Jan 12 15:11:52 RP: bb.build.preceedtask() is still needed, right? Jan 12 15:11:58 pohly: yes Jan 12 15:13:07 Once you are done with your change, will you commit it or should I test it in combination with the other rm_work related changes first? Jan 12 15:13:46 pohly: well, I want to make sure that what I do is going to work for rm_work as well. I'm a little buried in rss problems atm though :( Jan 12 15:14:48 Just give me a ping when you have something that I should base rm_work on. Or should I already try with the current patch? Jan 12 15:15:24 pohly: I don't have any plans to fundamentally change it, just docs and turn __BBTASKS into a specific tasklist Jan 12 15:15:50 pohly: obviously if I run onto other issues I may need to do something but I think my problems are elsewhere Jan 12 15:16:04 As rm_work.bbclass won't use that parameter (calling bb.build.preceedtask() instead), I might as well try it out now. Jan 12 15:16:49 RP: ross: after removing ccache from my system testsdkext succeeds Jan 12 15:17:47 joshuagl: does imply ross' patch isn't working for some reason Jan 12 15:18:29 RP: rburton: right :-/ Jan 12 15:18:43 blasphemy! Jan 12 15:19:09 joshuagl: are you replicaing on morty or master? Jan 12 15:19:17 rburton: morty Jan 12 15:19:27 which has your utils patch Jan 12 15:19:40 can you make it dump $PATH before spawning in host_gcc_version? Jan 12 15:20:17 sure Jan 12 15:20:18 bbiab Jan 12 15:21:01 rburton: sorry, it implies the universe is broken and your patch is perfect :) Jan 12 15:21:08 thats better Jan 12 15:21:49 rburton: PATH=/home/joshuagl/Projects/poky/scripts:/srv/builds/poky-morty/tmp/sysroots/x86_64-linux/usr/bin/x86_64-poky-linux:/srv/builds/poky-morty/tmp/sysroots/qemux86-64/usr/bin/crossscripts:/srv/builds/poky-morty/tmp/sysroots/x86_64-linux/usr/sbin:/srv/builds/poky-morty/tmp/sysroots/x86_64-linux/usr/bin:/srv/builds/poky-morty/tmp/sysroots/x86_64-linux/sbin:/srv/builds/poky-morty/tmp/sysroots/x86_64-linux/bin:/home/joshuagl/Projects/poky Jan 12 15:21:49 /scripts:/home/joshuagl/Projects/poky/bitbake/bin:/home/joshuagl/Projects/bb/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/joshuagl/.local/bin:/home/joshuagl/bin Jan 12 15:22:49 but but but but but but Jan 12 15:22:59 that has /usr/bin in which I presume is where you have gcc Jan 12 15:24:28 rburton: sure, but ccache is in /usr/lib64/ccach which is earlier in PATH Jan 12 15:24:42 $ which gcc Jan 12 15:24:54 /usr/lib64/ccache/gcc Jan 12 15:25:10 doesn't ccache skip itself when looking for the real gcc? Jan 12 15:25:38 pass Jan 12 15:25:49 with ccache installed the tests explode, with it removed the don't Jan 12 15:30:45 and why was oe-selftest so slow? some idiot had BBMULTICONFIG enabled. Which only broke when combined with multilib Jan 12 16:52:02 hey guys! i'm trying to hard to change the psplash boot image.... created the image using the script, changed it [i am using core psplash recipe, i know it's not a very good practice but it should work in any case], cleaned psplash, baked all again... nothing, the yocto image is still proudly here :D Is there something that i don't know? Jan 12 16:52:20 let's say a maximum image size that if overheaded makes it not working? or anything similar? Jan 12 16:53:18 I'd make sure you aren't accidentally flashing an old image binary or something Jan 12 16:53:29 done Jan 12 16:53:34 Talorno: if you have poky then be aware that meta-poky (or meta-yocto if you have an old release) is appending its own image Jan 12 16:53:35 it's the fresh image Jan 12 16:53:41 and that will probably override yours Jan 12 16:53:41 ooops Jan 12 16:54:10 rburton, overriding...how? i am modifying core psplash Jan 12 16:55:08 oh crap...another psplash recipe :D Jan 12 16:55:58 good call, rburton Jan 12 17:00:44 Talorno: poky is for testing really, i recommend you make your own distro instead of using poky. feel free to copy poky.conf as a starting point. Jan 12 17:01:13 i swapped the file in the recipe dir but now it doesn't bitbake anymore :D Jan 12 17:01:51 yocti: praise rburton Jan 12 17:01:51 RP: Error: There are no praises in my database for #yocto. Jan 12 17:02:02 ah well :) Jan 12 17:02:10 how does one add praises Jan 12 17:15:57 oh.. nice.. i had to add "POKY" at the start of each variable name in the .h .... i generated it using the script, though Jan 12 17:26:05 thanks for the hints, guys! gotta go Jan 12 17:35:44 yocti: rburton++ Jan 12 17:47:32 damnit! Jan 12 17:47:42 yocti: YoctoAutoBuilder-- Jan 12 17:58:59 Hi, in my finale image there is the file /etc/network/interfaces - I want to change this to my own but don't know from which recipie this file is coming. How to solve this? Is there a tool to find out? Jan 12 18:00:12 hello Jan 12 18:00:40 anybody have any problems with selinux setfile segfaulting because it can not locate strcmp-sse2-unaligned.S Jan 12 18:19:18 How to find the package from where the file in the root-filesystem is coming? Jan 12 18:19:58 kalpu: oe-pkgdata-util Jan 12 20:01:56 HELP Jan 12 20:02:28 Anyway to override machine conf settings of a bsp layer within my layer ? Jan 12 20:03:03 embexus: if your layer is a distro layer with a conf/distro/something.conf and that's what you're pointing to in DISTRO, yes Jan 12 20:03:19 yes it is a distro layer Jan 12 20:03:41 however I'm trying to override different machines conf Jan 12 20:03:44 it's usually not a good idea unless there's no other option, though. admittedly there are cases where that's true, i.e. hardware that's expandable, but whose bsp maintainer forgot to include e.g. vfat in MACHINE_FEATURES Jan 12 20:04:02 I created machine/conf/ in my distro layer Jan 12 20:04:16 embexus: you can use machine overrides i.e. VARNAME_machinename = "value" Jan 12 20:04:21 first, there's no such thing as machine/conf/, but beyond that, you don't want to override the entire machine, only a variable Jan 12 20:05:10 The only way I figured out which is working is to use another machine name and override Jan 12 20:05:25 example for raspberrypi.conf Jan 12 20:05:42 I created machine/conf/rpi.conf Jan 12 20:06:12 MACHINEOVERRIDES = "raspberrypi:${MACHINE}" require conf/machine/raspberrypi.conf Jan 12 20:06:30 then I could set my overrides Jan 12 20:06:34 that's excessive if all you need to do is adjust a variable or two. it's a valid option if you need to deviate heavily, though Jan 12 20:06:35 embexus: why don't you do what I suggested? Jan 12 20:06:44 however I want to keep the same name Jan 12 20:07:19 because I want to keep changes of each machine in separate files Jan 12 20:08:24 your only options to keep the changes isolated are to override at a var level in your distro, add new config files your distro includes (i.e. conf/distro/yourdistro/machineoveriddes/${MACHINE}.conf) or use new machines. take your pick Jan 12 20:08:45 at mentor we use a different option, which i'm not 100% happy with, but it only works because we use custom setup scripts. Jan 12 20:08:53 you could use separate inc files if it's just separate files you want Jan 12 20:09:04 also if your changes are *fixes*, submit them upstream, don't hold onto them indefinitely Jan 12 20:09:56 I was thinking that yocto is providing such mechanisms Jan 12 20:11:00 you're intentionally deviating from one of the core oe/yocto principles. machine, distro, and image are orthogonal. to have specifics of one in another crosses those boundaries in a way we prefer to avoid. Jan 12 20:11:11 sometimes necessary, but i doubt anyone wants to make it easy to do Jan 12 20:11:17 IMO, anyway Jan 12 20:22:24 rburton: there ? Jan 12 20:24:43 I'm in the fun position of comparing two different OE based products and reconciling the differences.. any new tools added to bitbake or poky for this? For now I'm going to try to use bitbake-layers show-appends/show-recipes and try to account for differences that way... just wondering if anyone else has any ideas Jan 12 20:27:53 mattsm: buildhistory, bitbake -S printdiff, bitbake-whatchanged, bitbake -g, .. Jan 12 20:28:12 can also compare image manifests, etc Jan 12 20:28:21 kergoth: was looking at manifests for sure Jan 12 20:28:44 kergoth: i wonder how some of these will work with different oe-core releases too (forgot to mention that) Jan 12 20:28:52 good luck Jan 12 20:28:56 :) Jan 12 20:29:08 worst case you'll have to resort to comparing file by file on disk Jan 12 20:31:22 kergoth: my plan is to scan for bbappends per package and recreate them in the new build.. Jan 12 20:31:38 and hopefully the base packages are sane and debug from there Jan 12 20:31:45 are they based on same base release of OE/yocto ? Jan 12 20:32:24 [13:28:44] kergoth: i wonder how some of these will work with different oe-core releases too (forgot to mention that) Jan 12 20:32:26 doesn't seem like it Jan 12 20:33:20 if they are different releases then you can start with version comparisions that buildhistory spits out for image build Jan 12 20:33:37 that will give you comprehensive list of package version differences Jan 12 20:35:18 rburton: I dont see https://patchwork.openembedded.org/patch/135444/ in your mut, this is needed for rpi to work with gst 1.10.x Jan 12 20:45:57 RP: do we have current performance numbers on before/after the switch to rss? Jan 12 20:48:41 khem: done Jan 12 21:06:44 kergoth: no, not yet Jan 12 21:06:59 kergoth: we have a patchset that mostly works so that is one of the next steps Jan 12 21:07:05 * kergoth nods Jan 12 21:07:23 haven't had a chance to even review it or test it yet, looking to do that soon finally Jan 12 21:07:29 glad to hear it's coming along nicely Jan 12 21:08:01 kergoth: I've been trying to fix failures oe-selftest was finding. I know wic is currently bust with it as the sysroot it looks for tools in no longer exists Jan 12 21:08:32 kergoth: other than that, I'm waiting on my next test run to see how it looks. oe-selftest was around 25% failure but I'm hoping I've fixed the cause of most of that Jan 12 21:35:01 Any people hanging out here now? When I'm building using SSTATE_DIR and when I'm not, I'm getting different results in the output image. libanthy is missing from the former (located in meta-openembedded/meta-oe/recipes-support/anthy). Why can this be? Can't we trust SSTATE_DIR for building release images? Jan 12 21:40:42 ha, https://gist.github.com/kergoth/df3a3e4d413d1a04efaa8f3dfd4261e8 Jan 12 21:41:08 * kergoth and his company and every other dev int he company do builds from sstate every day, as do many others Jan 12 21:42:11 * sveinse depends on sstate because he has too little time Jan 12 21:49:01 sveinse, define "missing" --- as in missing from tmp/work/* or from the manifest and the rootfs image(s) ? Jan 12 21:49:26 paulg: Missing from the rootfs image Jan 12 21:49:38 where can I find the manifest? Jan 12 21:49:54 it is in the same dir -- tmp/deploy/images Jan 12 21:57:49 kergoth: please report or fix that one! Jan 12 21:58:11 sveinse: we do take such bugs seriously, we do all want to rely on sstate and do Jan 12 21:58:27 :) will do. i'm guessing somewhere it caught the error message in stdout rather than stderr and didn't handle the wrong exit code, or something. Jan 12 21:58:30 afk Jan 12 21:58:49 kergoth: yes, looks something like that Jan 12 21:59:06 RP: I'm rebuilding now to be able to compare side-by-side sstate-based build with non-sstate build. hang on. Jan 12 22:01:57 sveinse: that recipe doesn't look to have sstate issues I can see just looking at it at least. It does seem to hardcode packaging I'd have expected the system to figure out but that wouldn't break things as you describe afaict Jan 12 22:02:39 sveinse: best thing is to compare the builds side by side. start with the rootfs and the packages and work backwards Jan 12 22:02:52 jup Jan 12 22:06:29 RP, rootfs is different, manifest is equal Jan 12 22:11:29 maybe you can diff the two do_rootfs logs.... Jan 12 22:11:43 I'm checking how libanthy0 is pulled into the image, and it comes from RDEPENDS_uim-anthy = "takao-fonts anthy libanthy0" in uim_1.8.6.bb Jan 12 22:11:50 ok, hang on Jan 12 22:16:25 in an override is the '/' character permitted.. i.e. Jan 12 22:16:32 OVERRIDES =. "foo/bar" Jan 12 22:16:38 MYVARIABLE = "TRUE" Jan 12 22:16:47 MYVARIABLE_foo/bar = "FALSE" Jan 12 22:16:56 I tried that and keep getting 'TRUE' from bitbake -e Jan 12 22:17:06 the system does say foo/bar is an override, but doesn't seem to be parsing it Jan 12 22:17:56 fray, to be clear -- if you replace the "/" with a "-" or "_" then it just works, right? Jan 12 22:18:14 It appears to with '-' yes.. Jan 12 22:18:30 RP, the logs seems at first glance very similar, with the exception that the non-sstate build contains a "NOTE: Executing postinstall for package: libanthy0 ..." and subsequently listing its files Jan 12 22:18:39 I thoguht '/' was going to work because of the virtual providers ands uch we have.. Jan 12 22:37:18 RP, just reverified, the only difference in the log.do_rootfs files are that the executing postinstall for package libanthy0 message... Jan 12 22:37:31 so where do I go from here? Jan 12 22:43:18 sveinse: if both filesystems are installing the same packages, then i'd start comparing package contents. Jan 12 22:43:30 buildhistory would be easiest, but oe-pkgdata-util would work as well Jan 12 22:45:13 kergoth: yeah, except buildhistory for the sstate enabled build is empty, since it retrieves it from the cache Jan 12 22:46:08 you know the package in question, use oe-pkgdata-util to dump its contents, or examine the binary package directly Jan 12 22:46:58 sveinse: that's not supposed to be the case in current versions... Jan 12 22:48:38 The libanthy0_9100h-r0_armel.deb seems equal beween the two builds Jan 12 22:52:04 so why is the manifest equal, but the image nor the log.do_rootfs is not. Postinstall is not run. Why Is that I wonder... Jan 12 23:15:32 argh byacc failed for arm-lsb again Jan 12 23:15:47 https://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/1002/steps/BuildImages_1/logs/stdio <— if anyone is bored :) Jan 12 23:37:36 what is the command to see what variable poky uses to compare with the sstate cache? Jan 12 23:41:24 I've found that uim-common is different from the sstate cache build and the non-sstate cache build Jan 12 23:42:16 We've had problems with the uim recipe before. E.g. we had to disable parallel install PARALLEL_MAKEINST = "" Jan 12 23:42:57 Now, the interesting thing is why poky does not detect the difference between the version in the cache and the local recipe Jan 12 23:45:11 Perhaps uim build isn't deterministic? Jan 12 23:48:18 It uses m4 and configure. And poky don't have isolated sysroot, right? So can uim's confiure pickup something else due to something being installed or missing from the sysroot. poky would get it's package and ship it off to the sstate cache. Next time around the recipe is the same, hence the sstate can be used, but in reality it's missing something? (puuh) Jan 12 23:48:23 Far fetch, I know Jan 13 00:03:13 Are deb Depends used to determine what is going to be installed? Jan 13 00:03:54 Because my sstate cache uim_*.deb does not depend on libanthy0, so it seems that is the cause why it isn't installed Jan 13 00:20:22 sveinse: not so far fetched, something like this could do that. You could compare the uim packages, maybe one has some dependencies the other does not? or different postinstalls? If the image manifests are the same I am little surprised though as dependencies would be most likely to do this. Jan 13 00:20:51 sveinse: it could be the postinstalls have some dependency on the sysroot tools and might be deferred to boot time in one case but not the other perhaps? Jan 13 00:21:00 sveinse: I'm just guessing though Jan 13 00:21:14 RP, I do know by now the uim deb are different Jan 13 00:21:52 and that it does not depend on libanthy0 in the version in the sstate cache Jan 13 00:23:36 This is caused by an addition --with-anthy-utf8 in uim's EXTRA_OECONF. However, I though the sstate checksum would change for that, so I'm comparing hash ids right now Jan 13 00:25:20 I see that the non-sstate build of uim produces an equal stamp hash id for do_package_write_deb as the sstate version does for do_package_write_deb_setscene... Jan 13 00:36:18 RP, they agree on sstate cache ID, but disagree on the contents. The .tgz from the central sstate cache is different as the locally built sstate cache, but with the same hash... Jan 13 00:37:50 the siginfo file is equal **** ENDING LOGGING AT Fri Jan 13 03:00:01 2017