**** BEGIN LOGGING AT Thu Apr 19 03:00:06 2018 Apr 19 04:25:02 New news from stackoverflow: Adding a partition in Yocto Generated Image Apr 19 05:25:13 New news from stackoverflow: about building a small docker image from Dockerfile Apr 19 05:55:18 New news from stackoverflow: CROSS COMPILE Paho-MQTT-C library for ARM? Apr 19 07:49:05 Hi, folks! Apr 19 07:49:55 Can i add files to image recipe? Apr 19 07:51:26 acrap: what is it that you *ACTUALLY* want to do? Apr 19 07:52:40 LetoThe2nd i need to run rootfs postprocess script (bash). Apr 19 07:52:51 hello, I have problems building qtwayland: https://pastebin.com/E3GHNvbb Apr 19 07:53:52 it looks like the build process does not see libwayland-egl library for some reason which is strange since I have definitely built the libwayland-egl package Apr 19 07:54:38 One more question... Can i have the access to Yocto variables in external bash script (it will be executed from the image recipe) Apr 19 07:55:31 the tmp/work/armv7at2hf-neon-imx-fod-linux-gnueabi/qtwayland/5.10.1+gitAUTOINC+db36bc0d9c-r0/recipe-sysroot/usr/lib directory actually contains libwayland-egl.so Apr 19 07:56:43 this is being done using yocto release 2.4.2 rocko and meta-qt5 5.10 vendor branch from the Qt Company Apr 19 07:57:44 acrap: no, i don't think either work. might be mistaken, but as far as i can tell the script has to be in the recipe Apr 19 07:59:12 LetoThe2nd: it makes sense. Thank you. Apr 19 07:59:45 acrap: have you looked at ROOTFS_POSTPROCESS_COMMAND variable for rootfs postprocessing? Apr 19 08:01:06 eduardas_m: yep. It works fine. I just want to use external bash script there. Apr 19 08:01:56 acrap: can't you put variables in argument ? Apr 19 08:03:44 nayfe: sure i can. I am just interested in opportunity to don't do that. Apr 19 08:04:54 anyone have any idea why does my qtwayland build process miss detecting a library that is actually present in the recipe-sysroot? Apr 19 08:05:14 how can I better debug such issues? Apr 19 08:06:06 acrap: maybe generate an environment script to source in external one, or wait rburton to wake up :D Apr 19 08:06:23 HI, is there a way to append package.bbclass Apr 19 08:08:54 eduardas_m: did you look log.do_configure.15885 and config.log ? Apr 19 08:14:44 prabhakarlad: what do you want to do? Apr 19 08:14:47 nayfe: its is basically the same as the output here: https://pastebin.com/E3GHNvbb Apr 19 08:15:23 says libwayland-egl is not detected, even though it exists in recipe-sysroot Apr 19 08:16:04 funny thing is that when I enter devshell and execute qmake, it detects libwayland-egl Apr 19 08:16:05 eduardas_m: did you check PACKAGECONFIG? Apr 19 08:18:44 just finished successfully compiling in devshell, wonder why it did not work from bitbake, will try a cleanall Apr 19 08:21:10 nayfe: so a bitbake qtwayland -c cleanall seems to help after all, not sure why I have ended up in such a weird state in the first place Apr 19 08:21:23 nice :) Apr 19 08:24:06 oh. I can't export environment variable... Apr 19 08:24:21 i do 'export VAR_NAME' Apr 19 08:24:51 and use like this 'echo $VAR_NAME' inside a function Apr 19 08:26:05 i have this variable in env, it isn't empty. But echo prints nothing Apr 19 08:27:12 echo prints to file. File is empty. ''echo $VAR_NAME > ${IMAGE_ROOTFS}/hello.txt Apr 19 08:33:48 export YOCTO_EXT_RPM_DIR Apr 19 08:33:49 my_postprocess_function() { Apr 19 08:33:49 echo $YOCTO_EXT_RPM_DIR > ${IMAGE_ROOTFS}/hello.txt Apr 19 08:33:49 } Apr 19 08:34:06 ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function;" Apr 19 08:34:27 it creates an empty file Apr 19 08:35:29 but in this terminal i can do echo $YOCTO_EXT_RPM_DIR and got right value Apr 19 08:38:10 i mean i use the same terminal to run bitbake Apr 19 08:39:23 i tried to use curly braces around variable (like for IMAGE_ROOTFS), but it doesn't help. Apr 19 08:47:47 Does somebody have an experience with exporting variables from env? Apr 19 08:48:29 bitbake prunes the environment when it starts, so an export when you start bitbake will be wiped Apr 19 08:48:46 best practise is to do the assignment in the configuration file instead Apr 19 08:50:16 rburton: i didn't know that. You saved my day! Apr 19 08:50:36 10x Apr 19 08:53:16 i should set up a tipjar! Apr 19 09:00:43 rburton: with whiskey in the jar? Apr 19 09:25:57 New news from stackoverflow: How to cross compile Paho-MQTT-C library for ARM? Apr 19 09:46:09 LetoThe2nd: works for me! Apr 19 09:56:04 New news from stackoverflow: I stuck on startup screen because I put my script on rc3.d and it is infinity while loop Apr 19 09:57:59 nayfe: sorry for the delay, I wanted to replace file fs-perms.txt but found a way to do it using FILESYSTEM_PERMS_TABLES, but after doing this now I get the following issues xxx is owned by uid 1004, which is the same as the user running bitbake. This may be due to host contamination Apr 19 10:03:06 prabhakarlad: maybe pastebin your custom fs-perms.txt ? Apr 19 10:06:03 Its exactly similar to the default once except a symlink removed to /var/log, https://www.pastiebin.com/5ad869e6875e0 Apr 19 10:06:51 my bad here is the link https://www.pastiebin.com/ Apr 19 10:08:24 Oops sorry here it is https://www.pastiebin.com/5ad86a86b942f Apr 19 10:08:55 my guess is its not actually being used Apr 19 10:17:40 nayfe: so di I need to fix all the packages with this qa, with similar patch https://git.congatec.com/yocto/meta-openembedded/commit/9fc5f4b83188da24270097d1675557c3c3b95f4f Apr 19 11:02:40 prabhakarlad: what exactly do you want to do with /var/log? maybe https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-VOLATILE_LOG_DIR is better for what you want? Apr 19 11:07:47 nayfe: I am using a bit older version of yocto where VOLATILE_LOG_DIR isnt supported, so what I did was refereed this patches http://lists.openembedded.org/pipermail/openembedded-core/2016-November/129039.html and used .bbappend instead of patching it everthing works apart from the above mentioned of contamination Apr 19 11:53:33 prabhakarla: can't you just do that at the very end with ROOTFS_POSTPROCESS_COMMAND Apr 19 11:56:28 New news from stackoverflow: install keyword significance in yocto recipe Apr 19 11:57:39 nayfe: thanks for the suggestion I'll try it out and let you know Apr 19 12:13:36 My rocko target is dependent on dhcp-client. I see that my system is running named, which is coming from bind being dependent on dhcp-client. Do I really need to run named on the target? Apr 19 12:44:25 sveinse: I dont think you need a dns cache to run a dhcp client, maybe you could change your dhcp client for one without this dependency ? I saw dhcpd is ok. Apr 19 12:50:23 jww: Do you know how I can configure it not to be included? Apr 19 12:54:00 I'm pretty new to yocto, but I think you can do that with PACKAGE_EXCLUDE , see https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE Apr 19 12:55:56 nayfe: ROOTFS_POSTPROCESS_COMMAND works perfect! Apr 19 12:57:21 cool Apr 19 13:05:11 any help regarding network proxy in vmware workstation Apr 19 13:08:05 pawan: can you be more explicit? :p Apr 19 13:13:43 how to set proxy in vmware workstation for build appliance Apr 19 13:14:32 I am unable to remove bind since dhcp depends on it Apr 19 13:15:20 I am curious if there is a buried FEATURE_ somewhere, where I can select not to install bind. Any ideas anyone? Apr 19 13:16:37 read the dhcp recipe, or look for a different dhcp client recipe, there are many options. udhcpc, dhcpcd, etc Apr 19 13:20:59 is it normal, that postinst is not being run during 'opkg install xxx' ? Apr 19 13:21:35 while building core-image-minimal resulting in proxy error, anyone had idea about the proxy settings Apr 19 13:22:02 in vmware workstation Apr 19 13:22:04 at the same time, postrm is being run on opkg remove, that doesn't make any sense to me Apr 19 13:22:33 kergoth: yes. I just don't understand why dhcp is dependent on bind Apr 19 13:23:49 Or more correctly, named running on target Apr 19 13:34:18 sveinse: it's for dynamic dns handling Apr 19 13:36:36 sveinse: dhcpcd is probably much more appropriate for embedded systems Apr 19 13:37:36 pawan: maybe pastebin your proxy error Apr 19 13:39:18 Another tricky detail is that I've included 'packagegroup-core-full-cmdline' because I want well, a full cmd-line. It however, down the line include rpcbind which I don't want due to the open network services. So now the challenge is how to remove these services with the minimum effort while still using the packagegroup. I really don't want to take over the recipe, yet I want to amend to it Apr 19 13:39:47 Create a bbappend for the packagegroup Apr 19 13:42:02 From a security point of view, the packagegroups should ideally not start any services without it being declared as such. I wouldn't expect that rpcbind and rcp.statd were started as a consequence of 'packagegroup-core-full-cmdline'. No ranting, just my 2 cents Apr 19 13:42:56 sveinse: create your own packagroup with exactly what you want in it, or IMAGE_INSTALL_remove = "xxx" Apr 19 13:45:20 nayfe: IMAGE_INSTALL_remove will break deps, won't it? Apr 19 13:52:23 IMAGE_INSTALL_remove will only help if the package you want to remove is explicitly listed in IMAGE_INSTALL. but as he says, bbappend the packagegroup, create your own, or explicitly list the packages you need Apr 19 13:54:23 indeed :) Apr 19 13:54:50 time for a nap Apr 19 14:07:36 * armpit woohoo rocko clean Apr 19 14:10:31 * armpit pyro builds on the new system too time to check morty Apr 19 14:13:39 I'm trying to make a recipe for a cmake project, but I have compilations error it say doesn't find iostream .can somebody help please ? here is my recipe and the error message : http://dpaste.com/0QB38Z7 Apr 19 14:22:44 jww: find out which package install iostream and then explicit dependency using DEPENDS_${PN} += "" Apr 19 14:23:30 i guess that package will be something like libstdc++ Apr 19 14:32:41 binarym: I searched for this earlier, I found only libcxx but it fail to compile. Apr 19 14:33:04 stephano, mmmm coffee Apr 19 14:38:51 * stephano shakes his fist at his lack of coffee Apr 19 14:38:53 binarym: DEPENDS_${PN} is not a thing. RDEPENS_${PN} exists and so does DEPENDS, but there is no package-specific DEPENDS Apr 19 14:39:35 Also, the compiler and GCC runtime should be in DEPENDS automatically unless one sets INHIBIT_DEFAULT_DEPS (IIRC that's what the variable was called, didn't double-check) Apr 19 14:40:46 stephano: hrhr Apr 19 14:41:35 LetoThe2nd: :) Apr 19 14:43:43 jww: sounds like the projects cmakelists is basically broken Apr 19 14:43:54 kergoth: remember the nsswich problem I had? It got resolved once I pulled in head on the rocko branch, so either there was a regression in there at some time, or that my previous compilation had some kind of (masked) error Apr 19 14:44:07 stephano: LOL Apr 19 14:44:09 binarym: yes I have the same issue when using DEPENDS_${PN} , and when I add it in DEPENDS I get an error, I updated the pastebin with config and the new error ( at bottom ) http://dpaste.com/3Z7JFJQ Apr 19 14:45:08 rburton: should I use my own src_compile() so ? Apr 19 14:45:40 jww: no, you'll have to figure out why the build isn't using the right paths, as we can clearly demonstrate cmake builds work normally Apr 19 14:46:27 rburton: I understand, I'll dig it more. Apr 19 14:46:42 mckoan: the day does not start without coffee, no? :) Apr 19 14:46:48 rburton: it's not about adding libcxx to DEPENDS so ? Apr 19 14:47:44 jww: no because iostream is part of the c++ standard library so you can't not have that Apr 19 14:48:01 (unless you set INHIBIT_DEFAULT_DEPS as above in which case you won't get a compiler either) Apr 19 14:48:38 I was thinking so, but I saw the project use CFLAG -std=gnu11 wich seems provided by libcxx. Apr 19 14:48:44 nope Apr 19 14:48:51 no idea what libcxx is tbh Apr 19 14:49:26 I found this here : http://layers.openembedded.org/layerindex/recipe/39646/ Apr 19 14:49:30 rburton: predecessor of libcyy Apr 19 14:49:52 jww: part of clang, oe-core uses gcc by default,which comes with c++ Apr 19 14:50:05 * armpit 2nd cup of corree Apr 19 14:51:21 allright, let's looks at this cmakelists. Apr 19 14:54:09 jww: "fatal error: gnu/stubs-soft.h" indicates you have problem with CFLAGS Apr 19 14:55:12 nayfe: I saw I can fix it by adding -mfloat-abi=hard to the CFLAG in CMakeLists.txt Apr 19 14:55:37 you should check your DEFAULTTUNE Apr 19 14:56:22 nayfe: I'm new to yocto, I gotta check what is DEFAULTTUNE :) Apr 19 14:58:36 found my problem, if opkg is being run via ssh, then PATH variable is not complete and probably opkg can't run update-rc.d Apr 19 14:58:51 but not a single error message is printed Apr 19 14:58:57 jww: "bitbake -e | grep ^TARGET_CC_ARCH=" for instance? Apr 19 14:59:30 jww then CMake needs to be aware of those flags Apr 19 14:59:53 TARGET_CC_ARCH=" -march=armv7ve -marm -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7" Apr 19 15:00:25 I think rburton is right the CmakeLists.txt doesn't seems ok. Apr 19 15:00:47 they get passed in via cflags etc Apr 19 15:01:02 sounds like the cmakelists is just overwriting those values in the assumption it knows best Apr 19 15:02:24 stephano: indeed! Apr 19 15:02:29 I found a file ./src-build/compile_commands.json will this be used by cmake ? because it containts path that are wrongs. Apr 19 15:03:01 in fact everything is wrong in that file. Apr 19 15:08:36 Hi all. Generic question I'm hoping someone with experience can give me some insight. I've been developing an environment, patching kernel source and generally getting things working. However, my work flow has been to make these coding changes in the BUILD/tmp/work* directory, build & test, then generate patches which I incorporate into .bbappends. This was workable, but now I'm incorporating a second developer and this is unsustaina Apr 19 15:08:36 ble. Apr 19 15:09:34 Any suggestions or docs outlining 'proper' development would be appreciated. Apr 19 15:13:13 majuk: Which version of yocto project are you using? Apr 19 15:13:21 paulbarker: rocko Apr 19 15:13:37 majuk: just in case you missed it https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#kernel-modification-workflow Apr 19 15:13:41 You should be able to use "devtool modify" on the recipes in question then Apr 19 15:14:04 devtool! I played with that a few months ago and couldn't remember the name of it to google. Apr 19 15:14:19 nayfe: Thanks! Apr 19 15:15:44 I didn't understand the workflow of devtool when I tried to use it before, have to give it another shot. Apr 19 15:15:51 Searching in the mega-manual is usually helpful. I often get caught out and forget that it doesn't incorporate the bitbake manual though so remember to search that too! Apr 19 15:20:53 paulbarker: i guess mega manual can't contain it all ;) but it's so handy! Apr 19 15:24:53 lol, I wish I understood what half of the devtool setup guide was talking about. Apr 19 15:34:36 such workflow producing an infinite list of patched will become eventually unsustainable Apr 19 15:34:48 RP: just noticed a change to a function in sstate.bbclass results in a complete rebuild of everything from scratch. probably shouldn't include the sstate prefuncs/postfuncs in the real task checksums Apr 19 15:36:19 probably the best option would be to work directly in the git repo of your sources instead of manipulating the recipe Apr 19 15:36:38 kergoth: I'm torn on that. It never used to but someone complained changes to sstate code can change the contents :/ Apr 19 15:36:54 jww: compile_commands.json would usually be generated by CMake and should contain the executed commands. Apr 19 15:38:59 mckoan: Got a doc or example? Apr 19 15:39:00 hmm, guess this is a consequence of using prefuncs/postfuncs rather than tasks (admittedly it's cleaner this way), since it doesn't know it only hsa to re-run the sstate postprocessing and packaging, but has to rerun the build tasks too, even though nothing has changed in the builds Apr 19 15:39:03 kergoth: it certainly makes it easier to work on the code if it doesn't do that Apr 19 15:39:20 neverpanic: thanks Apr 19 15:39:42 kergoth: even as tasks the task checksum dependencies would mean things would rebuild Apr 19 15:40:27 rburton / nayfe : it was the MakeLists.txt that overrided CMAKE_CXX_FLAGS and others variables . now it's better . Apr 19 15:40:27 RP, is the default kernel in sumo 4.15 ? Apr 19 15:40:38 true, i guess this is just one of those cases where there's no perfect option Apr 19 15:40:49 I just need to install opencv 2 instead of 3. but it think it won't be easy. Apr 19 15:40:53 not ideal to rebuild the world when i add a bb.warn, but what can you do :) Apr 19 15:41:19 kergoth: locked sigs ;-) Apr 19 15:41:34 armpit: hmm, I saw 4.14 here Apr 19 15:42:08 4.15 is not EOL on K.O Apr 19 15:42:16 s/not/now Apr 19 15:42:17 kergoth: I love the idea of a "bitbake-sstate lock *; bitbake-sstate unlock bash" command Apr 19 15:42:31 you can't use opencv3? Apr 19 15:43:37 hmm, yes, that would make it easier, good point. i don't leverage signature locking often enough Apr 19 15:43:48 nayfe: infortunatly not I just discovered it was not compatible :( Apr 19 15:44:08 RP there is 4.12, 4.14 and 4.15 Apr 19 15:44:28 * armpit lot to maintain Apr 19 15:46:08 armpit: talk to zeddii Apr 19 15:47:58 jww: in https://github.com/lock042/Siril-0.9/blob/master/configure.ac it seems they handle opencv3 Apr 19 15:52:04 ummm it's very strange, it should not be the siril I'm trying to package. Apr 19 15:52:23 but they looks like similar. Apr 19 15:56:08 sound like the devs tooks this Siril as base, but they havent's told me pfft. Apr 19 16:21:04 Is it possible to make the boot partition being generated as a separate file in the output directory ? Apr 19 16:27:07 RP: how do you force the locked signatures to override the actual ones rather than just erroring out if they don't match? Apr 19 16:28:14 kergoth: There is a warn and fatal mode iirc Apr 19 16:28:24 kergoth: may need some tweaks Apr 19 16:28:37 kergoth: I think its up to the sig handler Apr 19 16:30:59 ah. thanks Apr 19 16:54:46 Hello, I am trying to add the npm-fetcher bbclass to my yocto 1.7 bitbake compilation, without success. Can someone give me a quick help, pls? Apr 19 16:55:59 I followed the instructions on the github page, but I keep getting a ould not inherit file error Apr 19 17:01:32 gabriel__: 1.7 might be a stretch Apr 19 17:03:53 Yeah, I know. I am using an Intel Edison for my project. The distro provided by intel is based on the 1.7, and since I'll be changing platform soon it is not worth to upgrade now. Apr 19 17:06:57 For now I just need to run a simple node serve with two or three extra modules, which I was planning to download right from the recipe using the npm-fetcher Apr 19 17:07:47 you might want to read through the npm changes since 1.7 and see if anything makes sense for your issue Apr 19 17:08:08 isnt edison also EOL along with 1.7 being EOL too :) Apr 19 17:08:17 Humm Apr 19 17:08:18 yep Apr 19 17:08:59 But we have a batch of some thousands Edisons that we need to sell out haha Apr 19 17:09:30 oh Apr 19 17:10:02 Anyway, in order to add a new bbclass to the yocto compilation, what I need to do is just add the path of the layer to the bblayers.conf file, am I right? Apr 19 17:10:47 I have added some custom layers with new recipes to the image, but for bbclasses this is the first time Apr 19 17:17:33 khem, hi there Apr 19 17:18:08 I sinale this as well ;) Apr 19 17:18:22 I am solving the issues with the axe Apr 19 17:18:55 possible runtime issues...pls review Apr 19 17:19:12 | powerpc-oe-linux-musl-ld: unrecognised emulation mode: soft-float Apr 19 17:20:57 seems I am abusing of ld Apr 19 17:34:52 osten: it is possible, but i'm not sure there is an image type for that, you can create one Apr 19 17:50:22 gabriel__: it should be the same Apr 19 17:54:30 aehs29, even though it loaded the layer, when I try to run the recipe I get "Could not inherit file classes/npm-fetch.bbclass". I don't know if there is a configuration file that Intel put somewhere in this environment that is messing up something Apr 19 17:59:46 gabriel__: you can add -D flags to bitbake so you can see whats parsing, it might give you a clue of whats happening Apr 19 18:04:02 Given a yocto setup which builds product images and governing this build is a CM-system on top. Let's say you have a CM flag saying if one wants development packages included (as opposed to release version). What is a robust mechanism for controlling bitbake with this? IMAGE_FEATURES, DISTRO_FEATURES? Set from the image/distro recipe or from local.conf? Apr 19 18:09:37 sveinse: you can generate two differents images, but it becomes trickier if you change kernel configuration Apr 19 18:11:02 nayfe: No, in out setup, this is bound to the overall CM config, not intra-image, if you understand me. There is a build/release flow outside of Yocto in this. Apr 19 18:12:11 I have a scheme for generating a local.conf from the CM setup, but I try to minimize its contents Apr 19 18:13:15 sveinse: you could potentially drop in a site.conf in the CM, leaving local.conf static Apr 19 18:16:12 aehs29, just tried that, but despite all the debug info there is nothing supicious there, and the error is given with the same line Apr 19 18:16:49 sveinse: not sure i understand your workflow, but some variables resides in machine configurations, some in distro configurations and some in image recipes Apr 19 18:18:04 smurray: I do. site.conf contains the site global setup, such as mirrors, sstate cache and so on. local.conf contains the specifics; such as distro selection, but also pinning for the speicific subrepos when the CM mandates a lockdown Apr 19 18:19:07 sveinse: you could perhaps add IMAGE_FEATURES tweaks in there as well if it's just add debug / dev stuff Apr 19 18:19:10 nayfe: Yes, they do. I'm just trying to figure out a logical location for setting product-wide configuration Apr 19 18:19:53 smurray: Yes, I'm considering adding IMAGE_FEATURES and then adding this feature explicitly from local.conf from the CM Apr 19 18:20:06 sveinse: I'd almost be tempted to make a separate image recipe that inherits the production one and adds the extra stuff Apr 19 18:20:18 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-features-image dev-pkgs feature Apr 19 18:20:59 nayfe: yeah, something like that Apr 19 18:22:39 Then it would be best to add this from local.conf with IMAGE_FEATURES_myimage_append = "my-feature", right? Apr 19 18:24:12 smurray: if you do that, then the image will go by two names, which is confusing Apr 19 18:24:17 When troubleshooting, can I just do DEPENDS=${RDEPENDS} to get a slightly bloated but more functional package (IE: Can I assign one to the other just to test, even if it means pulling in extra dependencies that aren't needed at runtime)? Apr 19 18:24:51 sveinse: yes, that is the drawback if you want them to be named the same Apr 19 18:24:51 aarcane: RDEPENDS is related to packages DEPENDS to recipes Apr 19 18:25:08 smurray: we do more processing after yocto has produced it's rootfs image, so there is more. But of course, you don't know that Apr 19 18:26:00 nayfe, I know, but I don't want to try to split everything out of a single DEPENDS and into DEPENDS and RDEPENDS. I just want to assign one to the other, since they're all in DEPENDS right now and I don't have the reference handy for which ones go where Apr 19 18:26:37 yes, I buggered up out of confusion. I'm looking for a quick patch so I can finish testing functionality and fix packaging later Apr 19 18:27:58 New news from stackoverflow: Bitbake trying to apply patch before unpacking source Apr 19 18:32:43 aarcane: sorry i don't understand, but you can assign variables if you think it will help you Apr 19 18:35:18 sveinse: maybe create a packagegroup and use IMAGE_INSTALL_append = " yourcustompg" in your local.conf ? Apr 19 18:36:47 nayfe: yep. which is equivalent of FEATURE_PACKAGES_feature = " yourcustompg" and IMAGE_FEATURE_xyz_append = " feature" Apr 19 18:37:09 if I'm not mistaken Apr 19 18:39:55 oiy, that's another minor criticism I have of yocto in general (especially with mender) is that everything is split up between your local.conf and your layer and they are decidedly *not* in the same git repo, so bumping versions or making changes in the layer means making a change to bump version in local.conf, and... well... it just gets tedious. Annoying changing all those things around. Why can't all packaging and image content and whatnot be Apr 19 18:39:55 decided solely by the layers and the image definitions, rather than splitting it up so that you have to search everywhere to know what's going into your images. It just gets... frustrating. Apr 19 18:42:56 aarcane: freescale BSP uses google repo to handle multiples git repos, don't think it's that hard to maintain Apr 19 18:43:50 aarcane: and local.conf shouldn't change, it's only minimum configuration Apr 19 18:44:29 nayfe, until somebody starts adding packages to it... or when mender image version is bumped. Apr 19 18:45:42 This is one of the motivation we have for building a CM-system on top of yocto. Ensuring a deterministic set of layers (which also 'repo' can do) and the configuration of them. Apr 19 18:47:05 When I started working with yocto I was slightly puzzled at it being very controlling on what it includes, versions, sub-repo, md5/shasum, and so on, but no turn-key system for managing the collection of layers and configuration Apr 19 18:48:10 sveinse, I was chatting with someone whose names escapes me yesterday... And mentioned that I have some minor gripes with Yocto, but that in general, I'm quite fond of it... THis is just one of those gripes. Sounds like you have one, too, there :P Apr 19 18:54:54 I'd also like to see an eclipse plugin for editing a layer and working with devtool to modify or enhance it. Apr 19 19:51:48 aarcane: there's an eclipse plugin, feel free to file enhancement requests or patches Apr 19 19:52:19 aarcane: also ideally local.conf should be pretty minimal Apr 19 19:52:49 it should be local tweaks (this is where my tmpdir is, please add this package for what i'm fixing now), everything else should be in recipes, images, or distro config Apr 19 19:53:06 if you're in a company environment, a site.conf helps centralise stuff like "this is where the shared dl_dir is" too Apr 19 19:53:48 a minimal but working local.conf would just set DISTRO Apr 19 19:54:03 and then the distro config sets machine and other bits of policy Apr 19 19:58:18 New news from stackoverflow: How does Shared State Cache in Yocto work? Apr 19 19:59:54 what the hell yocti, that's a question from years ago Apr 19 20:03:16 lol :) post was edited 9 days ago, but still why today :p Apr 19 20:52:09 ant_home: hey Apr 19 20:54:51 rburton_: I've experienced that putting things in distro.conf has a drawback that it often want to rebuild more or less everything Apr 19 21:03:56 well crap. my build for for go 1.9, breaks 1.10 builds. and vice versa. hmmm. Apr 19 21:15:36 sveinse: hmm that depends on what you put there Apr 19 21:15:50 zeddii_home: 1.10 is more or less useless as of now Apr 19 21:16:01 sveinse: no difference in putting something in distro.conf or local.conf Apr 19 21:18:32 but yet, it exists. so I can’t break one for the other. working on how to keep the packages building for both. Apr 19 21:19:09 ahah. there. I think it just built for both. will have to revist and check in the changes later. Apr 19 21:20:39 rburton: I have to update musl recipe once again do you want to squash it with existing patch ? Apr 19 21:20:51 I think new patch would be ok too Apr 19 21:21:03 zeddii_home: yes Apr 19 21:21:05 khem: yeah just sent somethign that applies to master and we can drop the old one Apr 19 21:21:12 rburton: ok Apr 19 21:21:20 let me do so Apr 19 21:21:37 rburton: how is the ssp changes holding now ? Apr 19 21:21:56 hm, haven't tried the new patch yet Apr 19 21:24:21 rburton: ok, sent the musl update Apr 19 21:24:39 rburton: let me know when you fire a build for it Apr 19 21:25:28 rburton: with SSP changes I am curious about mingw builds and SDK builds Apr 19 21:32:17 khem: fired now, follow it on autobuilder.yocto.io when the sumo build has finished Apr 19 21:45:09 seebs: there? Apr 19 21:45:24 sorta? Apr 19 21:45:50 I've been looking a bit at 12434. I still can't seem to hit it on my laptop, which is weird. Apr 19 21:45:58 so i can replicate the uid 1000 thing almost on demand with glibc-locale Apr 19 21:46:06 interesting! Apr 19 21:46:12 just pastebining the pseudo.log now Apr 19 21:46:25 so bitbake warns: Apr 19 21:46:25 WARNING: glibc-locale-2.27-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-en-il/usr/lib/locale/en_IL/LC_MEASUREMENT is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Apr 19 21:46:26 WARNING: glibc-locale-2.27-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-ug-cn/usr/lib/locale/ug_CN/LC_NUMERIC is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Apr 19 21:46:35 aww can't pastebin, too big Apr 19 21:46:37 i'll mail it Apr 19 21:47:09 Oh, I've seen the errors. I just can't make them happen *here*. Apr 19 21:47:31 when my current qt5 build is finished I'm planing to run for loop building qml-webos-framework which is also good reproducer for this and now it's public with webOS OSE so I can share it if needed Apr 19 21:47:35 Which is the interesting part, because that suggests *some* kind of causality. Maybe it needs more cores (this is just a laptop), or maybe it's a particular version, or... Apr 19 21:47:39 seebs: try with a build in a tmpfs, that's what i have Apr 19 21:47:45 at least pseudo.log from it will be significantly smaller then from glibc-locale Apr 19 21:47:47 ... wait, tmpfs? Apr 19 21:47:51 *thinks* Apr 19 21:47:58 it's reproducible without tmpfs as well Apr 19 21:47:59 I don't know if that actually works. Apr 19 21:48:02 tmpfs on /data/poky-tmp type tmpfs (rw,relatime,size=31457280k,uid=1000,gid=1000) Apr 19 21:48:07 And I wouldn't necessarily *expect* it to work. Apr 19 21:48:27 ah ok jama has seen it without tmpfs too Apr 19 21:48:42 i've had no problems with tmpfs and i'm sure i've seen this before i started using tmpfs too Apr 19 21:48:54 might help increase the chance of reproducing though? Apr 19 21:49:11 That would sound like a timing thing. Feel free to buy me a giant computer that has enough memory and cores. :P Apr 19 21:49:15 haha Apr 19 21:49:37 Anyway, I'll try rebuilding glibc-locale again, see if I get lucky. Apr 19 21:50:01 bitbake glibc-locale -C compile is causing a fail pretty reliably here Apr 19 21:50:07 ... looks like that'll take a while. I'll wander off, come look at it later. Apr 19 21:50:28 So, just to be clear: It doesn't *always* fail, but it *frequently* fails. Does sstate cache affect that at all? Apr 19 21:50:34 rburton it only fails -after- the first time right? Apr 19 21:51:36 from what I'm seeing, when it fails (and creates sstate-cache archive) then all following builds will fail do do_package_qa until the do_package task is re-executed and doesn't trigger the issue Apr 19 21:52:15 even when the "bad" sstate-cache archive is being reused on different host machine Apr 19 21:52:33 fray: nope, did a tmpfs remount before running bitbake Apr 19 21:52:49 but I haven't found any significant difference between good and bad archive Apr 19 21:53:29 rburton: have you tried to reproduce it with pseudo-test.bb on your machine? Apr 19 21:53:32 fray: so its pulling sstate for the deps but building glibc-locale clean Apr 19 21:53:44 iirc that didnt break Apr 19 21:56:17 last time (more then 2 years ago) I looked at this stuff, there was a series of actions that could occur where it would copy directly from the compile directory to the packaging directory, and it preserved the owner/group... Apr 19 21:56:44 I never did figure out how to resolve it, but the symptoms went away after a while.. I don't know if this is the same thing (and it just 'came back' [or never went away]) Apr 19 22:00:33 ok bed Apr 19 22:03:33 huh. Apr 19 22:03:59 rburton, that *shouldn't* be the current tree, I think. I say this because one of my recent changes was to disable the warnings for path mismatches on files with multiple links. Apr 19 22:04:41 this is much smaller reproducer https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-webos/luna-init/luna-init.bb or https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-webos/qml-webos-framework/qml-webos-framework.bb we already skip this QA check in components where it fails too often (a bit long list for glibc-locale Apr 19 22:04:46 https://github.com/webosose/meta-webosose/blob/master/meta-webos/recipes-core/glibc/glibc-locale_%25.bbappend ) Apr 19 22:04:52 that was in 691a2304, and the current top patch is fddbe854, which also fixes a problem with symlinks. Apr 19 22:05:25 JaMa, if I just grab that one recipe, should it allow me to build cleanly? Apr 19 22:05:47 no, it depend on many other things :/ Apr 19 22:05:53 drat Apr 19 22:06:09 I'll try to narrow it down a bit (like pseudo-test) Apr 19 22:06:14 FWIW, pseudo.log for a from-scratch build of glibc-locale with my current patches is 254 bytes. Apr 19 22:06:23 it's a lot cleaner. :) Apr 19 22:06:51 e.g. that luna-init.bb seems very simple (it just calls tar to unpack the fonts and then packages it) Apr 19 22:07:10 but I haven't reproduced this one on any HW accessible to me (even with 1000 iterations loops) Apr 19 22:07:21 but other people from LG reported seeing this one Apr 19 22:08:37 armin's bitbake world builds are using fddbe854 now as well, lets see how much smaller the do_qa_pseudo reports will be Apr 19 22:15:32 * fray tries the simple bitbake glibc-locale bitbake -C compile glibc-locale.. Apr 19 22:17:44 it's useful to add host-user-contamination to ERROR_QA if you depend on bitbake actually failing to catch this Apr 19 22:18:21 by default it's only an warning Apr 19 22:19:03 no warning for me (thef irst time).. now trying with -C) Apr 19 22:22:04 ok.. running the -C compile in a look to see if it ever fails.. Apr 19 22:24:59 * fray sees master is still using 19f18124f... and moves it to fddbe854 Apr 19 22:25:03 it's still less than 1 from 100 builds which trigger it Apr 19 22:26:39 are you guys using rm_work? Apr 19 22:29:53 I'm Apr 19 22:30:21 ok.. I never use that.. so I'll enable it and see if it helps trigger it Apr 19 22:30:34 I've added pseudo-test2 (based on luna-init.bb) to contrib http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/master running the for loop over night to see if I'll reproduce it with it Apr 19 22:33:23 khem, hi Apr 19 22:33:29 https://github.com/LinuxPDA/meta-openembedded/tree/master/meta-initramfs Apr 19 22:35:31 khem, still many warnings Apr 19 22:35:35 fray: you can use the loop from https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434#c3 Apr 19 22:35:36 Bug 12434: normal, Medium+, 2.5 M4, seebs, ACCEPTED , pseudo: Incorrect UID/GID in packaged files Apr 19 22:37:59 why not just 'while bitbake -C compile glibc-locale; do : ; done' as long as ERROR_QA is set, it should stop if it ever errors Apr 19 22:38:36 ant_home: looks ok Apr 19 22:40:15 with the latest pseudo, the logging is greatly redueced.. ingoring the startup messages, I see 5 messages now Apr 19 22:40:20 like: Apr 19 22:40:23 creat for '/home/mhatle/git/oss/poky/build-test-pseudo/tmp/work/i586-poky-linux/glibc-locale/2.27-r0/locale-tree/usr/lib/locale/hif_FJ/LC_MESSAGES/SYS_LC_MESSAGES' replaces existing 33370792998 ['/home/mhatle/git/oss/poky/build-test-pseudo/tmp/work/i586-poky-linux/glibc-locale/2.27-r0/locale-tree/usr/lib/locale/fr_FR@euro.ISO-8859-15/LC_NAME']. Apr 19 22:40:35 (pretty consistent I'm getting those 5) Apr 19 22:41:48 (of course after I say that, the next time, I got a bunch more....) Apr 19 22:41:57 same general style, but different ones.. Apr 19 22:42:20 this time instead a about 5, it's about 20 Apr 19 22:42:22 'odd' Apr 19 22:42:49 i.e.: Apr 19 22:42:49 creat for '/home/mhatle/git/oss/poky/build-test-pseudo/tmp/work/i586-poky-linux/glibc-locale/2.27-r0/package/usr/lib/gconv/st30ZWGt' replaces existing 1274250301 ['/home/mhatle/git/oss/poky/build-test-pseudo/tmp/work/i586-poky-linux/glibc-locale/2.27-r0/package/usr/lib/gconv/IBM1026.so']. Apr 19 22:43:09 (is rm_work failing to reset the pseudo DB?) Apr 19 23:13:48 the pseudo.log is indeed significantly smaller, for image build I still get couple lines in the log 5-20 per image, e.g. Apr 19 23:13:51 inode mismatch: '/home/mjansa/.python-history' ino 2135835 in db, 2117396 in request. Apr 19 23:13:54 inode mismatch: '/home/mjansa/.python-history' ino 2135835 in db, 2117396 in request. Apr 19 23:13:57 creat for '/home/mjansa/.python-history-08015.tmp' replaces existing 2135835 ['/home/mjansa/.python-history']. Apr 19 23:14:00 seems to be in every one of them Apr 19 23:14:41 inode mismatch: 'path/to/image/WORKDIR/recipe-sysroot-native/usr/lib/python3.5/__pycache__/_sysconfigdata.cpython-35.pyc' ino 96664524 in db, 96664523 in request. Apr 19 23:14:46 seems common as well Apr 19 23:18:43 and inode mismatch: '/home/jenkins/oe/world/shr-core/tmpfs/sysroots/package-output.lock' ino 244007 in db, 263352 in request. Apr 19 23:19:03 is very common in armin's world build http://jenkins.nas-admin.org/view/OE/job/oe_world_qemuarm/733/console Apr 19 23:20:58 the for loop from the bugzilla reproduced it in 3rd iteration Apr 19 23:21:02 glibc-locale-logerr.qa.003:ERROR: glibc-locale-2.27-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-nl-be/usr/lib/locale/nl_BE/LC_CTYPE is owned by uid 2001, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Apr 19 23:21:07 glibc-locale-logerr.qa.003:ERROR: glibc-locale-2.27-r0 do_package_qa: QA Issue: glibc-locale: /glibc-binary-localedata-nl-be/usr/lib/locale/nl_BE/LC_CTYPE is owned by uid 2001, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Apr 19 23:21:29 wc -l glibc-locale-workdir-003/2.27-r0/pseudo/pseudo.log Apr 19 23:21:34 let me pastebin it somewhere Apr 19 23:22:54 https://pastebin.com/zEAmWNth Apr 19 23:23:07 seebs: fray: ^ Apr 19 23:28:07 and no rm_work and no tmpfs was used in this build Apr 19 23:32:00 possibly interesting part is that it started new server with the same pseudo.log 3 times (according to "doing new pid setup and server start" messages) and only first 2 were shut down (at least before the for loop moved the WORKDIR) Apr 19 23:33:15 maybe it's not rm_work, but "-f -c" (or "-C") which doesn't correct reset the pseudo DB, but that wouldn't explain why it fails in regular builds as well (which start from empty TMPDIR) Apr 20 00:02:24 JaMa: the inode mismatch and "creat replaces" are really interesting. Apr 20 00:02:33 Thanks, that's way more specific now than the problems we were previously seeing. Apr 20 00:02:52 That is really weird, though. Why... Huh. Apr 20 00:03:10 Okay, thanks, I'll see if I can trigger it again. Apr 20 00:03:30 the pyc one looks like it might be a .pyc getting deleted/recreated outside of pseudo. Possibly the same for .python-history. Apr 20 00:03:56 Hmm. Actually, yeah, all of those look like things which may be getting created inside pseudo, deleted outside pseudo, and recreated inside again. Potentially. Hmmmm. Apr 20 00:04:30 Anyway, that's a much smaller log, now I just need to see if I can cause it to happen on purpose. Thanks! Apr 20 00:27:08 seebs: yeah, it's shorter but the "creat for .* replaces existing .*" message is still shown quite a few times for many different files, but the host-user-contamination is in the end triggered for only one of them nl_BE/LC_CTYPE and this one doesn't look special in the pastebin pseudo.log Apr 20 00:29:33 seebs: the only difference of nl_BE/LC_CTYPE might be fewer hard links pointing to its inode (if it's the same as with ar_AE.ISO-8859-6/LC_MEASUREMENT described in bugzilla) Apr 20 00:30:06 do you want me to tarball whole glibc-locale workdir with this somewhere? Apr 20 00:30:35 it's not terribly big 774M glibc-locale-workdir-003 Apr 20 00:35:57 157M glibc-locale-workdir-003.tar.bz2 Apr 20 00:41:57 https://drive.google.com/open?id=1_aeVGu7-vz_0aZEGX9wiZdlYDLvUlVjG if you need it Apr 20 00:57:30 seebs, is the system creating hard links to files that were created in the compile step and NOT in the pseudo step? Apr 20 00:57:50 At one point (maybe it still does) the glibc-locales did a bunch of things with hard links instead of copy or install Apr 20 01:21:21 It could well be doing that, and that *could* create problems, potentially. I think. I'll have to think about it; it's totally possible that there's a way to trigger errors involving hardlinks. Apr 20 01:21:39 pseudo's only actually intended to be robust in cases where files are actually created under pseudo, linking to existing files can indeed produce undesired results. Apr 20 01:24:27 anyway, something to look at Apr 20 01:34:20 there have changes in glibc-locales do to host glib2.27 changes. those changes have rippled through the stable branches Apr 20 01:34:57 there is also a new uninative that landed a day or two ago Apr 20 01:35:32 that all most like mudding the waters Apr 20 02:02:01 looking some more Apr 20 02:02:04 do_install () { Apr 20 02:02:05 mkdir -p ${D}${bindir} ${D}${datadir} ${D}${libdir} Apr 20 02:02:05 if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then Apr 20 02:02:05 cp -fpPR ${LOCALETREESRC}/${bindir}/* ${D}${bindir} Apr 20 02:02:05 fi Apr 20 02:02:21 do we REALLY want the -p? if thats going to preserve the owner, the original files were owned by the user and NOT root Apr 20 02:02:31 then at the very end is Apr 20 02:02:33 chown root:root -R ${D} Apr 20 02:02:33 cp -fpPR ${LOCALETREESRC}/SUPPORTED ${WORKDIR} Apr 20 02:42:39 we dont want -p **** ENDING LOGGING AT Fri Apr 20 03:00:01 2018