**** BEGIN LOGGING AT Thu Mar 01 03:00:00 2018 **** ENDING LOGGING AT Thu Mar 01 04:44:32 2018 **** BEGIN LOGGING AT Thu Mar 01 04:46:03 2018 **** ENDING LOGGING AT Thu Mar 01 04:54:46 2018 **** BEGIN LOGGING AT Thu Mar 01 04:55:11 2018 **** ENDING LOGGING AT Thu Mar 01 05:02:41 2018 **** BEGIN LOGGING AT Thu Mar 01 05:05:00 2018 Mar 01 06:55:17 I got this error while configuring windows sdk on eclipse oxygen ide Mar 01 06:55:21 java.lang.NullPointerException Mar 01 06:55:21 at org.yocto.sdk.ide.YoctoSDKChecker.checkYoctoSDK(Unknown Source) Mar 01 06:55:21 at org.yocto.sdk.ide.YoctoUISetting.validateInput(Unknown Source) Mar 01 06:55:36 Can anyone help please? Mar 01 06:56:13 I'm using eclipse plugin from http://downloads.yoctoproject.org/releases/eclipse-plugin/2.4/oxygen/ Mar 01 08:14:19 khem: gobject introspection is broken with systemd and musl - known issue? Mar 01 09:31:45 does recipe specific sysroot approach also remove all host tools from PATH of recipe build environment, unless -native dependencies are specified? Mar 01 09:32:40 seeing an epidemic of using host gcc in our project for target builds and stuff just happens to work due to x86 architecture.. Mar 01 09:39:30 mcfrisk: host tool pruning isn't related to recipe-specific-sysroots but was part of the same "reproducibility" issue. its called hosttools, we symlink the commands we need from the host into the build dir and remove /usr/bin etc from PATH Mar 01 09:44:56 rburton: thanks, I'll check that out.. Mar 01 09:45:21 if you've recipes using 'cc' explicitly then yes that will fail, they should be changed to use BUILD_CC Mar 01 09:45:35 as people may want to use a different compiler to build natively Mar 01 09:46:49 did you consider adding file system namespaces to the mix to capture offenders using host tools with direct paths? Mar 01 09:47:55 mcfrisk:would that allow hosttools->/usr/bin/gcc to work but direct access to /usr/bin/gcc to fail? Mar 01 09:48:49 rburton: I guess not, but one could bind mount instead of symlink.. Mar 01 09:49:15 mcfrisk: sounds good patches welcome :) Mar 01 09:49:21 other related thing is capturing build logs. Is it possible with rm_work and sstate caching? Mar 01 09:49:33 rm_work doesn't delete logs Mar 01 09:50:47 yes it does. our build is too big to work without rm_work, but capturing build logs to sstate cache would be nice, or at least adding build log based sanity tests to capture wrong compiler calls or missing build flags, e.g. hardening Mar 01 09:51:07 logs to sstate? that doesnt really make sense Mar 01 09:52:00 well it would be nice to archive all build logs somewhere so that they can be pulled in for processing if needed. Mar 01 09:52:19 there are numerous projects to archive logs Mar 01 09:52:49 should be fairly simple to write a class to push the logs somewhere for archiving/mining Mar 01 09:53:20 "patches welcome" :) Mar 01 09:53:38 pretty much ;) Mar 01 09:55:50 i cant remember then one i found before but greylog.org might be interesting Mar 01 09:59:53 rburton: hmm, right now I just want a tar ball of all build logs to get an overview of compiler flags, missuses of host compiler, compiler warnings... enabling hardening exposes part of the bugs Mar 01 10:00:59 mcfrisk: add a build postfunc or something to archive the log files? Mar 01 10:01:11 that would only archive on success though Mar 01 10:07:01 rburton: that would be enough, I'll check the details. thanks! Mar 01 10:09:33 rburton: sent a v2 for static-pie issue in glibc Mar 01 11:15:02 New news from stackoverflow: Yocto procedure to write generated image to hard disk Mar 01 11:45:01 Guys, what the difference between 'devtool build-image ' and 'bitbake '? Mar 01 11:45:02 New news from stackoverflow: Yocto procedure to write generated image to HDD Mar 01 11:59:31 zks: use devtool in a sdk, use bitbake if you're using the build system directly Mar 01 12:00:46 rburton: I've got it now - when working with devtool in a build system - I have to use 'devtool build-image'. Mar 01 12:01:18 rburton: Because I 'devtool build-image' also builds the devtool-workspace recipes. Mar 01 12:02:09 rburton: E.g., I do 'devtool add' or 'devtool modify' - now I *must* use 'devtool build-image' to include the added (or modified) recipe. Mar 01 12:02:25 no, thats not right Mar 01 12:11:51 rburton: This is what I see on 12th slide here: https://www.yoctoproject.org/sites/default/files/yocto_devday_advanced_class_berlin_1.pdf Mar 01 12:15:06 rburton: I'm trying 'devtool add' gRPC project to the build system (devtool add https://github.com/grpc/grpc.git). But it fails non-gracefully. Error in pastebin: https://pastebin.com/SS5EfPeG Mar 01 12:15:07 New news from stackoverflow: what the difference between 'devtool build-image ' and 'bitbake ' Mar 01 12:15:56 zks: please file a bug Mar 01 12:16:12 rburton: Ok. How can I do it? Mar 01 12:16:23 bugzilla.yoctoproject.org Mar 01 12:16:31 rburton: Doing... Mar 01 12:16:36 are you using the esdk *and* the build system? Mar 01 12:16:49 confused why it says starting bitbake more than once Mar 01 12:17:24 zks: http://layers.openembedded.org/layerindex/recipe/72419/ btw Mar 01 12:18:20 rburton: 10x!! Checking it now... Mar 01 12:56:24 rburton: Yeah. This grpc_1.8.5.bb exists only in master branch. I cherry picked these two commits (07f015f, 38f6ef9). How I can make a pull request to include gRPC also in the rocko branch? Mar 01 13:01:05 Hi all! I'm having a little trouble with a recipe. I've been trying to use do_build[nostamp] = "1" to try and make sure all my tasks are rerun in my recipe, however it seems that it's still pulling from the sstate. Is there someway I can exclude this one recipe from the sstate? Mar 01 13:03:11 maybe a noob beginner question but: can i use the information from RRECOMMENDS in bb files somehow? (like automatically building/including the listed kernelmodules etc. in my build, so that i do not have to check those manually?) Mar 01 13:13:18 hello, i have the following issue using krogoth: in my im agre recipe i have a ROOTFS_POSTINSTALL_COMMAND where i use ${DATETIME} to create some files, however this gives me taskhash and basehash mismatch errors. Mar 01 13:13:20 I have tried setting various vardepsexclude things like `IMAGE_CMD[vardepsexclude] = "DATE TIME DATETIME"` to no avail. the recipe inherits from core-image. anybody has an idea how to fix this issue? Mar 01 13:14:17 zks: stable branches don't get version upgrades. just copy/paste it to your layer Mar 01 13:14:41 rburton: Got it. Thanks! Mar 01 13:16:02 ok guys, nvm. i just found the right array for vardepsexclude :D Mar 01 13:16:05 problem solved Mar 01 13:41:10 Hello! I'm writing my first recipe but I am a little unsure about this error: https://pastebin.com/PJE4WdaR. Those files are installed as part of my makefile and the path is correct. I guess that message means I need to explicitly set those as files packaged in the deb files created by yocto, but how should I explicit those files? I need those to be installed in the same path used by the "make install" command, which in turn depends on the path Mar 01 13:41:12 specified by qmake. Mar 01 13:42:05 luc4: You need to put them in some instance of FILES_${PN}, e.g. FILES_${PN} += "${libdir}/qt5" Mar 01 14:11:09 neverpanic: so FILES_${PN} should be just a single path were the libs are to be installed by the package? So in my specific case libopenmaxilmediaplayer.so.1.0 for instance will be placed in the path specified by FILES_${PN}? So I should set it to ${libdir}/qt5/plugins/mediaservice? Mar 01 14:12:19 No, FILES_${PN} (or FILES_${PN}-dev or whatever package you want to contain these files) should contain a wildcard or prefix that will match those files Mar 01 14:14:57 neverpanic: ah, so I guess that tells the yocto what files to put in the package? Mar 01 14:15:22 and it will use the same identical path right? Mar 01 14:21:01 Yes Mar 01 14:25:02 neverpanic: now I see thanks! Mar 01 14:45:43 New news from stackoverflow: How to determine dependencies of recipes in yocto? || Yocto procedure to install generated image to HDD from a USB-pendrive Mar 01 15:15:48 * kergoth yawns Mar 01 17:04:19 that weird host contamination issue may now be fixed. i'm optimistic; i can't reproduce the failure mode easily, but i can reproduce a failure mode which is very similar and which highlighted a flawed assumption which would result in deleting an entry on OP_CREAT Mar 01 17:05:37 seebs: that is good news! Mar 01 17:07:35 RP morty-next needs a rebuild. the changes staged I can't tell when last built Mar 01 17:07:55 armpit: ok Mar 01 17:16:13 basically, i assumed an OP_CREAT would never come in that *precisely* matched an existing entry (both path and inode). Mar 01 17:29:37 seebs: ah, interesting. And in reality we can do that... Mar 01 17:43:45 hey all, i'm learning yocto and bitbake by jumping in the deep end of a code base written by other engineers and reading manuals at the same time. i'm experiencing and issue that i'm not sure what is wrong... Mar 01 17:45:07 https://www.irccloud.com/pastebin/UhR2jozm/ Mar 01 17:45:22 sure enough, layer.conf is absent Mar 01 17:45:30 so i'm reading the docs for bitbake Mar 01 17:45:47 and it's not clear to me whether layer.conf is something that should already be there, i.e., written manually Mar 01 17:45:59 ullbeking: it should already exist Mar 01 17:46:05 or if it's normally automatically generated and somehow got missed Mar 01 17:46:16 ullbeking: meta-poky exists in some branches and not in others so it could be a branch mismatch issue Mar 01 17:46:40 ullbeking: are you using bitbake/oe-core/meta-yocto spearately? Mar 01 17:47:11 ullbeking: the other option is the file referencing this is wrong (conf/bblayers.conf usually) Mar 01 17:48:42 17:46 ullbeking: are you using bitbake/oe-core/meta-yocto spearately? Mar 01 17:48:42 i'm doing the following: Mar 01 17:49:07 wow that is some awful code in this example of pseudo allegedly failing with clone() Mar 01 17:49:21 https://www.irccloud.com/pastebin/8kSSdiqF/ Mar 01 17:49:35 it fails on the bitbake command Mar 01 17:49:52 perhaps the oe-init-build-env should have already set up layer.conf? Mar 01 17:50:37 RP: so i don't know if this answers your question about "using bitbake/oe-core/meta-yocto spearately"? Mar 01 17:50:44 ullbeking: I suspect your template config files don't match the layout of the code you're using Mar 01 17:51:03 RP: that sounds plausible Mar 01 17:51:23 you mentioned something about a branch mismatch issue earlier Mar 01 17:51:49 also the documentation for clone(2) appears to be wrong Mar 01 17:52:36 huh, that's really weird. Mar 01 17:52:45 it is built on a specific, older, stable revision of facebook's known-working openbmc repository Mar 01 17:52:51 ullbeking: compare http://git.yoctoproject.org/cgit.cgi/poky/tree/meta-poky/conf/bblayers.conf.sample with http://git.yoctoproject.org/cgit.cgi/poky/tree/meta-yocto/conf/bblayers.conf.sample?h=jethro Mar 01 17:52:55 this person's test case uses [alloced_stack]+stack_size-1 as the child_stack pointer, and crashes. Mar 01 17:53:10 ullbeking: I think you're trying to use a codebase which expects one with a config file in the other format Mar 01 17:53:15 if i use, say, alloced_stack+stack_size, or alloced_stack+stack_size-16, it's fine. Mar 01 17:53:18 ullbeking: meta-yocto became meta-poky basically Mar 01 17:53:27 but their code works okay as long as it's *not* under pseudo, and I have no idea why. Mar 01 17:53:28 RP: ah i see Mar 01 17:53:40 ullbeking: I'm having to guess based on the info I have though Mar 01 17:53:52 RP: i think i know what the issue is... Mar 01 17:54:15 seebs: please do point out their bug, the fact it works is curious :/ Mar 01 17:54:16 as i mentioned, this is based on a specific revision of facebook's openbmc Mar 01 17:54:40 i honestly don't know whether the clone documentation is right or not Mar 01 17:54:56 but my intuition would be that your stack pointer should not be precisely-not on a power of two boundary. Mar 01 17:54:56 but i was using _that_ readme to try to build this project, even though it's out of date by the very fact that the new stuff builds on top of it Mar 01 17:55:00 ullbeking: layer.conf is pre shipped, the generated file is bblayers.conf which references where to find layer.conf file Mar 01 17:55:03 files Mar 01 17:55:48 i just love this person asking whether pseudo can allow them to use any syscalls similar to fork Mar 01 17:55:59 nope, never solved that one, this is why we have to invoke every single process separately and cannot use a shell Mar 01 17:56:24 seebs: If you don't understand what pseudo does, I can see how you might wonder. But yes, if that breaks we have problems Mar 01 17:56:33 ok, thank you RP, i'm going to try something different using different info. i hope you don't mind these bumbling questions, i'm still just starting to learn my way around the hugeness of yocto Mar 01 17:57:13 ullbeking: np, I just happen to know something about that as I worked on the meta-yocto -> meta-poky change Mar 01 17:57:42 RP: what is "the meta-yocto -> meta-poky change" all about? Mar 01 17:57:46 can you point me to a link? Mar 01 17:58:14 ullbeking: it got renamed between jethro and morty Mar 01 17:58:47 RP: i'm going to need to go back to basics and read up on the naming scheme Mar 01 17:58:52 obvi Mar 01 17:58:59 ullbeking: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=morty&id=9d5483c37523ff3d334c98cafb848282b54962cd Mar 01 17:59:49 does this mean the project name also changes from yocto to poky? Mar 01 17:59:50 ullbeking: but that probably doesn't help you much, it just tells me you're mixing up configs and revisions which don't match Mar 01 17:59:52 ;-) Mar 01 18:00:19 17:59 ullbeking: but that probably doesn't help you much, it just tells me you're mixing up configs and revisions which don't match Mar 01 18:00:19 that is hugely useful information for me though Mar 01 18:00:19 ullbeking: "yocto" and "poky" both exist and mean specifiic things, this was an attempt to clarify a piece of that Mar 01 18:01:44 RP: so "poky" is the name of the reference distribution. but that page doesn't say what "yocto" now means. what /does/ it mean? Mar 01 18:02:38 ullbeking: yocto project is the overall entity which is working on bitbake, OE-Core, poky, and several other pieces and pulling them together as an ecosystem Mar 01 18:06:21 RP: ty for the helpful explanation Mar 01 18:06:38 ok, it's time to try something a bit different... Mar 01 18:06:59 see you soon again probably ;-) Mar 01 18:09:01 looking for opinions - if you needed to put a filesystem on a bit of SRAM (1-2MB), what would you choose? Mar 01 18:09:49 ntl: vfat? Mar 01 18:10:23 RP: yeah, on top of mtdblock? Mar 01 18:12:57 ntl: why would you want to use mtd* on SRAM? Mar 01 18:15:48 RP: I don't, really. Is there another way to get a block interface to it without writing a driver though? Mar 01 18:16:37 ntl: depends how this SRAM is connected really, I can't answer that Mar 01 18:22:31 RP: it's just "there" in the memory map. currently the device node uses a mtd-ram compatible property but I the mmio-sram binding might be more appropriate. Mar 01 18:22:42 *I think Mar 01 18:23:51 ntl: probably Mar 01 18:25:41 RP: mut and glibc builds were both green. i'm doing my happy dance Mar 01 18:26:07 rburton: nice! Mar 01 18:26:11 uhh completely unrelatedly... has anyone ever heard of using a minix fs in a Linux deployment in production, for any reason other than minix compatibility? Mar 01 18:26:16 rburton: we're ready to merge a few things then? Mar 01 18:26:20 yes Mar 01 18:26:35 ntl: I have heard of that for license reasons before Mar 01 18:26:45 RP: glibc series sent Mar 01 18:26:51 RP: i'll clean up mut and post that later Mar 01 18:26:55 rburton: thanks Mar 01 18:27:04 rburton: was -next ok as is? Mar 01 18:27:28 rburton: need to drop dbus? Mar 01 18:28:09 RP: ah interesting. thanks for your responses Mar 01 18:59:11 Hello! I'm trying to write my first recipe but it seems I'm stuck. I'm getting this error: https://pastebin.com/pCYNvDz9. It says I should remove those files in do_install. But what patch should I use? I tried with rm "${D}${libdir}/qt5/plugins/mediaservice/libopenmaxilmediaplayer.so.1.0" but it seems it is incorrect. I see a few versions of that file in my build dir. Which one should I remove? The one from the "sysroot-destdir" directory? Mar 01 19:19:53 luc4: add FILES_${PN} += "${libdir}/qt5/plugins/mediaservice/" Mar 01 19:20:20 4 Mar 01 19:47:48 khem: yes, I tried that already, but yocto tells me that those are symlinks and should not be packaged. Mar 01 19:49:02 khem: the proper way actually seems to be the last warning yocto gave me. Removing those files from the sysroot should be ok, I do not strictly need those. Mar 01 19:50:20 I have a quick question: When would I want to inherit pkgconfig in my recipe? The docuemntation isn't very clear Mar 01 19:50:35 I think removing in do_install should be ok, but I'm not able to find out what path I should use. I see some are using the D variable for this case. Mar 01 20:12:38 i admit, btw, to being totally stumped on why there's sets of arguments for which clone() crashes under pseudo but not outside of pseudo. Mar 01 20:13:26 huh. i am not getting core dumps. i wonder if i have to enable those. Mar 01 20:13:57 ... apport, of course. Mar 01 20:17:01 Hello friends - suppose I have a library/application in git, that uses a version file (e.g. version.txt or version.h) to advertise its version. Would it be reasonable for my recipe to dynamically set PKGV based on that file? Mar 01 20:17:08 oh weird. Mar 01 20:18:29 It appears it's tied vaguely to the horrible magic trying to get the "right" version of regcomp to avoid some versions of find(1) providing their own. Mar 01 20:22:48 okay, so the answer is: if the stack isn't word-aligned, some stack operations can segfault. but the specific operation in question only *happens* under pseudo. Mar 01 20:24:33 if you call regcomp in the cloned process you get the segfault. Mar 01 20:28:13 so, 12568 is Not My Fault, and my belief that "sizeof(char)" indicates that the code containing it is buggy continues to pay off. Mar 01 20:42:16 seebs: thanks for digging into it! Mar 01 20:46:56 New news from stackoverflow: How to remove unneeded files after those are installed by Yocto? Mar 01 22:04:31 RP: my dbus is fixed (i squashed a PRIVATE_LIBS patch into juro's commit) Mar 01 22:15:29 rburton: did PRIVATE_LIBS need a fix? Mar 01 22:15:42 RP: yes, in the branch Mar 01 22:15:54 let me scrub mut after this meeting and i'll post a cpull Mar 01 22:17:32 rburton: static PIE was ok in the end? Mar 01 22:17:48 RP: v2 restricted it to some arches Mar 01 22:18:38 rburton: ah Mar 01 22:18:57 rburton: I've pushed a few things Mar 01 22:29:53 If I add a receipt, ie apache2, how I use my own httpd.conf file ? Mar 01 22:30:08 Where do I have to place it? Mar 01 23:26:36 JoseBravo: Have a look at how meta-webserver does it: Mar 01 23:26:38 JoseBravo: http://layers.openembedded.org/layerindex/branch/master/layer/meta-webserver/ Mar 01 23:27:08 JoseBravo: Also, consider using that layer instead of rolling your own. That might save you some time. Mar 01 23:40:48 does bitbake have anything like a "make clean" command? Mar 01 23:45:15 ullbeking: bitbake -c clean recipe Mar 01 23:45:41 hmm should probably say package rather than recipe Mar 01 23:46:14 but anyway, that's a lot like make clean. good way to force a rebuild if the recipe doesn't know its sources have changed for example. Mar 01 23:46:34 there's also a cleanall but tbh i don't know how it's different from clean Mar 01 23:46:34 recipe is the right word Mar 01 23:46:47 rburton: well, i'm just rusty then :) Mar 01 23:47:02 cleanall cleans downloads and sstate Mar 01 23:47:07 read the source ;) clean wipes tmp/work cleansstate does clean and removes sstate for that recipe, cleanall does cleansstate and removes anything in downloads too Mar 01 23:47:08 clean only cleans tmp I think Mar 01 23:47:09 *but* Mar 01 23:47:19 if you just want to rebuild a recipe then 1) it should do it magically as files changes Mar 01 23:47:26 and 2) use bitbake recipe -C unpack Mar 01 23:47:37 "please mark unpack as needing to rerun and build " Mar 01 23:47:43 rburton: does it check file hashes? Mar 01 23:48:10 BCMM: file: entries in SRC_URI are hashed yes Mar 01 23:48:15 i know i probably shouldn't have the entire package source in files/ as a tarball, but i was under the impression it wouldn't notice that tarball being replaced Mar 01 23:48:30 yeah it will notice that Mar 01 23:48:43 hmm i've been doing more things wrong than i thought Mar 01 23:49:05 either that or i've forgotten why i needed to force a rebuild Mar 01 23:49:23 tldr never use cleanall cleansstate or clean unless you have a good reason to Mar 01 23:49:35 and you generally don't as -C is faster and neater Mar 01 23:49:57 doesn't blow away the old logs for example, which is annoying when you have a transient failure and the old logs would have been useful for debugging Mar 01 23:50:02 anyway bed Mar 01 23:50:20 hmm i wonder if https://www.openembedded.org/wiki/Bitbake_cheat_sheet#Clean_up needs changing Mar 01 23:51:55 * armpit think 4.1 is fixed.. Mar 01 23:53:10 armpit: I filed yet another test_qemu_efi bug, this time for master :) Mar 01 23:53:53 nice Mar 01 23:54:07 armpit: fedora27 was a mistake Mar 01 23:54:15 hehe Mar 01 23:56:28 thank you BCMM, rburton, and clsulliv Mar 01 23:56:58 * armpit now has got and fix Rocko core and meta-oe Mar 01 23:58:13 https://www.irccloud.com/pastebin/zrgQJ4BF/ Mar 02 00:00:33 ok, so it seems that this is not a standard thing, and that the project i'm working on hasn't implemented and cleaning functionality Mar 02 00:01:18 ok, s Mar 02 00:01:38 ullbeking: recipe should be the name of the recipe you're wanting to clean Mar 02 00:01:40 now i get it. i've made the same mistake as looking for the "any" key Mar 02 00:01:44 clsulliv: lol Mar 02 00:01:54 i think it's time to wrap up and go to bed Mar 02 00:02:09 thanks for all your help everyone Mar 02 00:02:34 yocto is a huge project and i've just landed in the deep end, the help i've gotten here so far has been great Mar 02 00:02:56 it's quite an overwhelming thing if you look at from the outside Mar 02 00:03:15 i do wonder if it ever stops being overwhelming Mar 02 00:03:34 have written a few recipes and still have little idea how or why anything works Mar 02 00:03:41 but it's crazy powerful Mar 02 00:03:42 BCMM: so i'm not the only one then? Mar 02 00:04:10 i'm still a fan of autotools and makefiles personally, but yocto seems like on a different level Mar 02 00:04:29 gnu make is crazy powerful when you really get into it Mar 02 00:04:40 yeah that seems like apples and oranges really Mar 02 00:04:50 i mean, probably most recipes makes use of make Mar 02 00:05:16 it's more comparable to a package manager or a linux distro than to autotools Mar 02 00:05:21 i mean technically i guess it is a linux distro Mar 02 00:05:27 oh i haven't seen any makefiles yet Mar 02 00:05:43 it seems very cool and very interesting Mar 02 00:06:03 i have so much to learn about it Mar 02 00:06:06 ullbeking: i mean, a lot of recipes build software which uses autotools Mar 02 00:06:22 i.e. basically calls upstream's Makefile **** ENDING LOGGING AT Fri Mar 02 03:00:02 2018