**** BEGIN LOGGING AT Tue Oct 04 02:59:58 2016 Oct 04 08:27:56 hey. Trying to debug a recipe that DEPENDS on a xxxx-native recipe, which does not get built for some reason. Unless I manually bitbake the xxxx-native recipe before baking my recipe, it fails. The xxxx-native shows up in the DEPENDS-list if I do "bitbake myrecipe". What might be preventing a DEPENDS from building? Can I assume that all DEPENDS are built before any task of my recipe execute? Oct 04 08:32:13 DEPENDS will be built before your recipe configure tasks, iirc. so you recipe fetch/patch might run before the DEPENDS get built. Oct 04 08:32:46 ah, dang. im trying to use xxxx-native in a task that runs before do_unpack Oct 04 08:33:10 right, then that might fail. Oct 04 08:33:57 or actually, it's "after do_unpack before do_patch" Oct 04 08:34:21 check meta/recipes-core/expat/expat.inc Oct 04 08:34:34 meta/recipes-core/expat/expat.inc:do_unpack[depends] += "gzip-native:do_populate_sysroot" Oct 04 08:39:28 ndec: ah, great. that will work. Thanks Oct 04 14:36:44 if i have a "feature" that affects devicetree, additional KERNEL_FEATURES, adds packages to image, is the most suitable way of packaging it a MACHINE_FEATURE? Oct 04 15:47:32 hi is there a retrocompatibility between MIPS32 and MIPS-I Oct 04 15:50:45 troulouliou_div2: compiled for MIPS-1 should run on mips32. vice versa. possibly not. Oct 04 15:50:45 https://www.linux-mips.org/wiki/File:Mips-isas.svg Oct 04 15:51:16 ZubairLK, perfect thanks Oct 04 18:01:41 so in the context of mailing patches, what's the "normal" git process to rework and send v2? Oct 04 18:02:14 * nerdboy might be breaking some git stuff in the rework part... Oct 04 18:03:03 maybe i just need to set --in-reply-to on later ones to point to the first one? Oct 04 18:03:17 does anyone need to mess with that? Oct 04 18:19:37 nerdboy: —subject-prefix=PATCHv2, —in-reply-to being an optional convenience afaik Oct 04 18:19:51 nerdboy: you might find https://github.com/git-series/git-series interesting, i haven't tried it yet, but it seems promising for this Oct 04 18:19:58 need to test it out Oct 04 18:20:34 nerdboy: also i'd only do the in-reply-to the previous 0/N, not each individual patch, which would be more trouble than its worth, particularly since larger series are generally pull requests anyway, so they aren't applied one by one Oct 04 18:20:37 i also meant the patch changes before mailing Oct 04 18:20:37 * kergoth shrugs Oct 04 18:21:34 if i reset HEAD to before my changes and make new patches Oct 04 18:21:46 does that break any of this stuff? Oct 04 18:22:45 for stuff like this i rebase my changes on top of latest upstream (krogoth, master, whatever) Oct 04 18:23:00 cut patche(s) and send Oct 04 18:23:44 second time starts "fresh" after a reset, and i;m not sure if that confuses git Oct 04 19:07:38 not sure what you mean. git doesn't care if you rewrite history, that's up to you Oct 04 20:21:55 kergoth: i meant the reply-to and related msg threading stuff Oct 04 20:22:26 maybe i need the extra switches? Oct 04 21:11:22 nerdboy: git doesn't care what you set in-reply-to to, all that affects is how the emails show up on the list. it has zero knowledge of it when the patches get applied. could have some effect on patchwork, but if it's a pull request, not a random couple patches, patchwork is irrelevent, they'll just pull it from the branch Oct 04 21:16:02 this scenario is ml-only Oct 04 21:18:02 and that's what i'm asking... do i need to set in-reply-to explicitly on a v2 patch so the ml knows that? Oct 04 21:18:35 *meaning explicitly on the git send-email part Oct 04 21:20:52 nerdboy: if you want it to thread under the original version, that's entirely optional though Oct 04 21:21:30 nerdboy: most of the time I just send an entire new v2 series Oct 04 21:21:54 seems like u-boot wants that Oct 04 21:22:27 not entirely clear, but seems that way Oct 04 21:24:16 right, different communities may have different expectations; I guess I was referring to OE Oct 04 21:24:26 or rather, what I do with OE patches I send Oct 04 21:24:27 as long as i remember the right list/meta-foo part i don't remember any wonkiness with oe lists Oct 04 21:24:48 for some reason i do with u-boot list Oct 04 21:29:53 *do have some wonkiness that is... **** ENDING LOGGING AT Wed Oct 05 02:59:58 2016