**** BEGIN LOGGING AT Fri Feb 23 03:00:01 2018 Feb 23 08:02:21 Herrie: that would be feasible; I guess it would be quite the same impact as having TUNE_PKGARCH Feb 23 08:26:40 Morning! Feb 23 08:31:34 Tofe: I'm not sure... Just to make such a solution is less work I gues s:P Feb 23 08:33:10 Herrie|Laptop: I'm not 100% sure it would avoid making the whole dependency chain machine-specific, as the choice of preferred version would be in the machine conf Feb 23 08:36:41 I thought about it during my morning shower, and for me it looks like bitbake lacks the notion of "external/internal" states; to distinguish between the need to build a recipe and the need to propagate that build, a recipe needs two states, i.e. two hashes. One internal, one external. The internal one should be used to decide if the recipe needs to be rebuilt; the external one should be used by the recipes that depend on it, and woul Feb 23 08:38:18 So in the current situation, with only one state, it's just hopeless. And the change to do is huge. So JaMa is right: let's just forget about that one :) Feb 23 08:38:40 Tofe: Yeah LOL Feb 23 08:40:34 However there is still hope: only libhybris is used at build time by other recipes, isn't it Feb 23 08:41:04 for the other ones, it's just RDEPENDS, so only runtime dependencies Feb 23 08:42:07 I'll check that tonight. But it should be the case, otherwise we would already have everything as MACHINE_ARCH Feb 23 08:44:57 Tofe: well sensorfw is MACHINE_ARCH for example Feb 23 08:45:04 "# We're depending on libhybris so need to be MACHINE_ARCH" Feb 23 08:46:31 Tofe: https://github.com/webOS-ports/meta-webos-ports/pull/278/files :) Feb 23 08:46:36 Upstream merged the patches :) Feb 23 08:59:06 Herrie|Laptop: great ! it works well ? Feb 23 08:59:20 Tofe: What works well? Feb 23 09:03:12 sensorfw Feb 23 09:03:29 Tofe: I haven't tested it yet Feb 23 09:03:41 But it should be the same as previously since it was disabled :P Feb 23 09:04:01 ah, ok Feb 23 09:04:04 As nizovn pointed out :P Feb 23 09:04:13 So the LS2 bits don't work Feb 23 09:04:15 Rest might work Feb 23 09:04:37 merged Feb 23 09:04:39 I need to check on my Hammerhead to see if some of the "errors" I get in tests on Mido are "normal" Feb 23 09:06:19 It should sort some error in the log as well ;) Feb 23 09:06:41 I.e.: https://git.merproject.org/mer-core/sensorfw/commit/0a04f1d9feef3716f1f673062fe56ffadbaa5c57 Feb 23 09:06:56 I've seen that error in our logs Feb 23 09:13:08 Ah yes, that one has been there for a looong time **** ENDING LOGGING AT Fri Feb 23 10:01:45 2018 **** BEGIN LOGGING AT Fri Feb 23 10:01:45 2018 **** ENDING LOGGING AT Fri Feb 23 10:01:49 2018 **** BEGIN LOGGING AT Fri Feb 23 10:04:12 2018 Feb 23 17:47:32 Herrie: I've just checked, and the recipes that directly depends on either android-headers are all used as RDEPENDS, which makes sense for plugins. Therefore we shouldn't have a cascade of MACHINE_ARCH, if I understand correctly. Feb 23 17:48:00 I'll try it on tenderloin, and we'll see if everything falls in "tenderloin" arch :) Feb 23 17:51:17 For libhybris that wouldn't work, because it provides virtual/libgles2, and many recipes DEPENDS on this one directly. Feb 23 18:01:14 Herrie: seems fine, hopefully. Now I'll try to ease the use of these additional flags, like you suggested. Feb 23 18:08:39 Ok, I think I have something working here :) Feb 23 18:10:59 Herrie, JaMa: https://github.com/Tofee/meta-smartphone-1/commit/0c601080398d0cbddbd5c4674a5bf40af3302507 Feb 23 20:05:32 Tofe: That looks like a pretty clean solution Feb 23 20:05:37 Code wise I mean Feb 23 20:34:35 Seems to work OK for mido as well Feb 23 21:11:23 Tofe: Remember my android-tools wouldn't patch properly for mido, could it be we need to make the android-tools-conf MACHINE_ARCH? Feb 23 21:11:26 Just thought about this now Feb 23 21:50:24 Herrie|2: not sure I remember the exact issue Feb 23 22:15:33 Tofe: It doesn't seem to apply the patch for functionfs https://github.com/webOS-ports/meta-webos-ports/blob/d8068a7a4722f6203ef16d85c235f86a5a76fa9c/meta-luneos/recipes-android/android-tools/android-tools-conf_1.0.bbappend Feb 23 22:15:41 I guess that's one to play with for tomorrow Feb 23 22:19:32 _ _ _ _ _ _ _______ _______ _______ _______ Feb 23 22:19:34 ( ) ( ) ( ) ( ) ( \ ( \ ( ___ )( )( ___ )( ____ \ Feb 23 22:19:39 _| |_| |_ _| |_| |_ | ( | ( | ( ) || () () || ( ) || ( \/ Feb 23 22:19:44 (_ _ _)(_ _ _)| | | | | (___) || || || || (___) || (_____ Feb 23 22:19:49 _| (_) |_ _| (_) |_ | | | | | ___ || |(_)| || ___ |(_____ ) Feb 23 22:19:58 (_ _ _)(_ _ _)| | | | | ( ) || | | || ( ) | ) | Feb 23 22:20:06 | | | | | | | | | (____/\| (____/\| ) ( || ) ( || ) ( |/\____) | Feb 23 22:20:10 (_) (_) (_) (_) (_______/(_______/|/ \||/ \||/ \|\_______) Feb 23 22:20:12 ##LLAMAS Feb 23 22:20:14 EricBlade elvispre scoutcamper siel Herrie|2 MrTango nslu2-log rrch[m] noradtux gsora saidinesh5 nemunaire dkirker dwc- kido alexnoyle_iOS Andolamin bigbluehat Tofe Garfonso zetaPRIME thejsa HaDAk int0x27h bshah halfhalo cryptk dyoung LarrySteeze Jack87 novaldex|away zz_ka6sox ParkerR lukegb Feb 23 22:21:41 oh yeah, freenode spam :( **** ENDING LOGGING AT Sat Feb 24 03:00:00 2018