**** BEGIN LOGGING AT Tue Sep 19 03:00:02 2017 Sep 19 06:14:47 khem: Removing the tmp also did not help Sep 19 06:15:48 I still do see following errors: https://pastebin.com/a4zwWtxe Sep 19 06:16:19 And running diffsigs shows: Sep 19 06:16:24 bitbake-diffsigs -t linux-yocto-custom do_bundle_initramfs Sep 19 06:16:24 ERROR: Only one matching sigdata file found for the specified task (linux-yocto-custom do_bundle_initramfs) Sep 19 06:16:56 In the "original" thread: http://lists.openembedded.org/pipermail/openembedded-core/2016-July/123886.html Sep 19 06:17:27 The author says that removing INITRAMFS_IMAGE helps Sep 19 06:18:56 but for me didn't work: Sep 19 06:18:56 SDK_LOCAL_CONF_BLACKLIST_append = " INITRAMFS_IMAGE" Sep 19 06:18:56 and Sep 19 06:18:56 SDK_INHERIT_BLACKLIST_append = " kernel" Sep 19 07:05:10 Hey! I'm a novice user of yocto, and I have an little troubles. May be somebody know how to install ffmpeg libs and tools (via package)? Does exists some "smart" repo? I can't find any information about it (only bb-layer to assembly a new system http://layers.openembedded.org/layerindex/recipe/47350/). Any ideas? Thanks. Sep 19 08:54:07 Is the oe-core/oe-devel list server funky and changing the From: to openembedded-core-bounces@lists.openembedded.org ? Why just my email? Or is our company email infra screwed.. http://lists.openembedded.org/pipermail/openembedded-devel/2017-September/114917.html Sep 19 09:55:25 What's the prefered way to add some nodes to the Device Tree of my custom linux kernel? ATM I patch the .dst file but this fails on kernel version updates, and I think there must be a better technique. Sep 19 10:36:25 zeroo use upstream kernel :-) Sep 19 10:37:05 I'm trying to exclude some packages from eSDK Sep 19 10:37:05 zzeroo ^ Sep 19 10:37:19 I'm able to build it (with some "hacks") Sep 19 10:37:48 and then I do receive following error when extracting *.sh file: Sep 19 10:37:50 Task lua.do_fetch attempted to execute unexpectedly Sep 19 10:38:42 How does the: SDK_INHERIT_BLACKLIST works? Sep 19 10:39:03 according to User Manual this shall prevent adding some packages to eSDK Sep 19 10:39:50 why even when specified, (like _append = " lua") those packages are "needed" when calling *.sh eSDK installer ? Sep 19 11:56:59 Is it possible to specify recipes to not be build Sep 19 11:57:17 I mean -> I do leave their code in the poky directory tree Sep 19 11:57:37 but specified packages are not build and depoloyed Sep 19 11:57:45 and also added to SDK/eSDK Sep 19 12:22:42 hello, I want to set the default.target symlink for systemd in my package during do_install... I package the symlink in my rpm and I know it is present in the package... however, in the rootfs the default.target symlink is not the one from my package Sep 19 12:23:05 it is created by some other recipe Sep 19 12:23:31 how do I ensure my current recipe has priority when setting this symlink? Sep 19 13:06:26 @eduardo: Would setting the package PRIORITY variable be effective in this case? I honestly don't understand that variables use but I do remember reading about it at some point. The details escape me ... Sep 19 13:19:33 Hi, I'm trying to build xen from meta-virtualization. this files cause it cannot find bits/long-double-32.h any clue how to follow up? I'm on pyro/bb1.34 Sep 19 13:23:18 had a look to recipe-sysroot and there is only a bits/long-double-64.h Sep 19 14:05:35 We've changed yocto from krogoth to pyro and I've noticed that my qt app, which is built to tune, has changed directory from 'cortexa9hf-neon-poky-linux-gnueabi' where most other packages are to 'cortexa9hf-neon-mx6qdl-poky-linux-gnueabi'. Am I missing some directive in my recipe? Sep 19 14:21:08 xthunderheartx: my eventual solution is to use ROOTFS_POSTPROCESS_COMMAND for image recipe... haven't really found how to set priority for particular rpm package Sep 19 14:22:52 also image.bbclass has a particular way of handling the default systemd target which is not in the main Yocto documentation as far as I can tell Sep 19 14:23:39 Yeah I think the PRIORITY var I'm thinking of only applies to dpkg/opkg so prolly isn't relevant in your case. May not be relevant at all :) Sep 19 14:23:44 there is a function in it called set_systemd_default_target that is appended to ROOTFS_POSTPROCESS_COMMAND Sep 19 14:23:54 that overrides package contents Sep 19 14:38:17 Any qt5 people here? What is the thinking in Yocto of the RCC and MOQ tools? When running from the SDK, OE_QMAKE_RCC is defined, while running from a recipe its not. I'd like to know how I should access the rcc tool in a recipe Sep 19 14:42:18 Yeah I see that ... fascinating. Sep 19 15:23:37 RP: I am actually seeing a different failure with core-image-minimal-initramfs failing because it's 155M with 55M worth of Python! (needs to be below 128M) Sep 19 15:50:57 https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/ Sep 19 15:51:07 I wonder our checksums are sound Sep 19 15:51:28 or may be an upgrade since June, could have exposed to bad tarballs Sep 19 15:58:42 Are recipes building under a chrooted environment in pyro? That /usr/bin/qt5/ actually refers to its sysroot? Sep 19 15:59:54 khem: it looks like it was uploads of packages with similar names to official ones, so the only compromised packages would be those whose developers depended on the wrong upstream packages, not direct modification of existing tarballs Sep 19 16:00:13 so i doubt its an issue for us unless we have a recipe for one of the wrong packages Sep 19 16:00:16 * kergoth shrugs Sep 19 16:02:54 er Sep 19 16:03:14 what if we upgrades a recipe in this time window Sep 19 16:03:27 then bitbake would have calculated the hijacked checksums Sep 19 16:04:03 is there a best practice how to deal with BAD_RECOMMENDATIONS when using deb as package class? Sep 19 16:06:13 khem: only if that recipe already included the wrong packages in the first place. this wasn't a transparent hijack, but an upload of new packages with names similar to existing ones. possible, certainly Sep 19 16:06:27 they didn't modify existing official packages, only uploaded new ones with similar names to mislead people Sep 19 16:07:45 khem: only if the maintainer used the wrong name Sep 19 16:08:02 sneaky, same was reported for node last year Sep 19 16:08:49 someone did a honeypot and uploaded a urllub or similar and got some shocking results, like .gov domains fetching it Sep 19 16:25:37 that still might be problem if we created recipes for them Sep 19 16:25:44 but otherwise it seems we should be fine Sep 19 16:25:46 RP pyro updates failed to build on genericx86 bsp and extras. have push fix for bsp. looking ino extras Sep 19 17:12:07 Any particular reason why qt apps end up under the dir 'cortexa9hf-neon-mx6qdl-poky-linux-gnueabi' in pyro, while in krogoth it is 'cortexa9hf-neon-poky-linux-gnueabi'. Most other packages ends up in the latter in both versions Sep 19 18:27:58 At which step is the DEPENDS="xyz-native" packages populated in the per recipe sysroot dir under Pyro? do_populate_sysroot ? Sep 19 18:36:27 sveinse: PACKAGE_ARCH controls that. ones that set it to MACHINE_ARCH instead of the default will end up with the machine name in the package architecture and whatnot. it's how we distinguish which recipes/packages are machine specific and which are common to the architecture and can be shared between machines. Sep 19 18:37:17 sveinse: per recipe sysroots are populated prior to running the early tasks, you should be able to read the classes that do the work if you're curious Sep 19 18:47:36 kergoth: Well the thing is that I don't set PACKAGE_ARCH in my recipe, but I do observe its output dir being changed if it is a qt5 app (include qmake5) Sep 19 18:47:57 That behaviour has changed from krogoth to pyro Sep 19 18:52:12 kergoth: as for the second issue, the problem was that I had a do_populate_sysroot[noexec]="1" and that inhibited the population of the -native packages from DEPENDS. Sep 19 18:58:19 In pyro this seems to have changed too: IMAGE_POSTPROCESS_COMMAND_append = " vsi_compress; " and in vsi_compress access to ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.wic is not (yet?) available. The wic file has not been moved to the deply dir. Sep 19 18:58:46 Should I rather access it in deploy-vsi-image-image-complete/vsi-image-*.wic ? Sep 19 19:01:02 Anyone else who has implemented post-wic processing of the images with pyro? Sep 19 20:17:31 How can I force a rerun of an entire recipe? Using -C demands I have knowledge of the names of the early tasks. -- I'm trying to rerun an image recipe for me to run it with -v to see all the steps Sep 19 20:22:23 is there a bank holiday in US today or something? Overwhelming response here today :D Sep 19 20:22:44 sveinse: bitbake -c cleanall RECIPE Sep 19 20:22:57 that will ditch everything for a given recipe and start you from square 1 Sep 19 20:23:16 majuk: won't that wipe the sstate cache as well? Sep 19 20:23:20 Yup Sep 19 20:30:23 ah, so I can run, -C clean RECIPE to avoid the do_cleansstate :D Sep 19 21:17:35 Just to ask -> is there a way to encapsulate IMAGE_CLASSES += "foo-image bar-image" in a separate recipe Sep 19 21:17:47 which would ten depends on another one? Sep 19 21:20:50 lukma: what do you mean? Sep 19 21:35:30 sveinse: I try to separate building factory images from production ones Sep 19 21:38:44 Up till now they were combined into one "large" core-image-XXX file Sep 19 21:42:41 sorry, I'm not familiar with IMAGE_CLASSES Sep 19 21:43:32 It seems like += operator in the .conf Sep 19 21:43:55 and _append = " foo-image" can do the trick Sep 19 21:44:18 since the latter is evaluated only when the factory recipe is evaluated Sep 19 23:07:27 When making a recipe that process some deploy artefacts, chosing which to do do_tasks[noexec] = "1" on is hard. Some have not-apparent effects. Like which target is responsible for populating the per receipe sysroot from its DEPENDS? Sep 19 23:07:52 It's not do_populate_sysroot as I'd expect, it seems Sep 20 00:06:39 https://bpaste.net/show/b23436712d9f Sep 20 00:07:30 This recipe fails unless the sstate cache is wiped before running it. Using -c clean make the recipe fails. Is this a bug in bitbake? I'm running Pyro Sep 20 00:09:33 The key point seems to be that bitbake does not reinstate the deps (utils-linux-native) into the per recipe sysroot after a mere clean, while it does after a sstate cleanup **** ENDING LOGGING AT Wed Sep 20 03:00:02 2017