**** BEGIN LOGGING AT Tue Jul 25 03:00:02 2017 Jul 25 14:21:23 Over here, would people scream if "vmdk" went away as a valid IMAGE_FSTYPE and was replaced with "wic.vmdk" ? And the same for vdi/qcow2 Jul 25 14:21:30 (and yes, I'll rfc it, if people don't scream here) Jul 25 14:48:49 Hi all. Stupid question: I am having a difficult finding how the version of the kernel is selected. Is there an easy way to find the logic of which package in a recipe is selected for building/installing? Jul 25 14:49:52 It appears as thought it picks the newest version number in linux/linux-xlnx_v20XX.XX.bb but I can't find the logic that specifies that is how it works. Jul 25 14:53:15 MrSaturn: MACHINE -> yourmachine.conf -> PREFERRED_PROVIDER_virtual/kernel -> yourkernel.bb Jul 25 14:55:53 mckoan, PREFERRED_PROVIDER_virtual/kernel ?= "linux-xlnx" - But there are two .bb files (linux-xlnx_2016.4.bb and linux-xlnx_2017.1.bb). I don't see anything that ties the kernel version to the machine. Jul 25 15:04:18 MrSaturn: if both have the correct COPMATIBLE_MACHINE, so they're both valid options, then it depends on 1. PREFERRED_VERSION_linux-xlnx, 2. layer priority if they're in different layers, 3. DEFAULT_PREFERENCE, 4. latest version lacking any other specified preference Jul 25 15:04:31 and the logic you're wondering about is in bitbake's codebase Jul 25 15:07:37 kergoth, Ok, thank you. Jul 25 15:13:27 kergoth: ;-) Jul 25 16:14:54 hey kergoth, where would I go to get some dumps to debug a problem like: ERROR: When reparsing /home2/trini/oe/oe-core/meta/recipes-core/images/core-image-minimal.bb.do_image_ext2, the basehash value changed from f05d28b17d5200a65080f97347782221 to fb0b96e849eb5c098823218dd516e6ca. The metadata is not deterministic and this needs to be fixed. Jul 25 16:15:21 I know how to trigger it (with chaining image support fixed, doing 2 or more CONVERSION_CMDs does it) Jul 25 16:15:46 ie ext4.gz is fine, ext4.gz.sha256sum will trigger, ext4.gz.u-boot.sha256sum will trigger even more Jul 25 16:17:23 Tartarus: it means somewhere your code is tinkering with DATE or TIME or DATETTIME vars and bringing them into variable tracking Jul 25 16:17:46 ugh, those are a pain in the ass to diagnose. iirc there are commented lines in bitbake to get it to dump basehash sigdata that could possibly be used to compare, but i'm not sure if that's still the case offhand. obviously the most common cause is date/time references, since they change between the up front parse and the task parse Jul 25 16:18:09 khem: I'll double check but I think those are being nuked already Jul 25 16:18:39 Tartarus: https://gist.github.com/kergoth/8b0c01b86d8ab4d9330527ba9c2bb8e2 Jul 25 16:18:50 kergoth: thanks Jul 25 16:18:52 not sure if it still applies, but that was of use last time i had to dig into one of those Jul 25 16:18:59 np Jul 25 16:19:39 doesn't apply cleanly but it's obvious what to uncomment Jul 25 16:19:57 just an offset Jul 25 16:28:22 Welp, this isn't so easy :) Jul 25 16:28:42 https://www.irccloud.com/pastebin/RH9stTOK/ Jul 25 16:29:15 order is backwards, since I was lazy and didn't see which sig was older Jul 25 16:38:04 OK, cool, got a fix, will post soon **** ENDING LOGGING AT Wed Jul 26 03:00:02 2017