**** BEGIN LOGGING AT Thu Feb 22 03:00:05 2018 Feb 22 06:51:32 JaMa: Seems we need to remove https://github.com/shr-distribution/meta-smartphone/blob/pyro/meta-android/recipes-core/android-system/android-system_1.0.bb#L51 and https://github.com/shr-distribution/meta-smartphone/blob/pyro/meta-android/recipes-core/android-system/android-system_1.0.bb#L52? **** BEGIN LOGGING AT Thu Feb 22 07:39:31 2018 Feb 22 12:37:09 JaMa: You want me to make a PR for that? Feb 22 12:40:48 moboot boots on the pre3 \o/ Feb 22 12:41:34 gsora: Whoohooo Feb 22 12:48:05 Herrie|Laptop: yes, please Feb 22 12:49:23 Herrie|Laptop: I have couple SRCREV bumps for luna-prefs powerd storaged luna-universalsearchmgr luna-sysservice luna-sysmgr-common sleep luna-sysmgr luna-appmanager to make them compatible with newer json-c Feb 22 12:49:32 will push them to pyro after finishing the build with master Feb 22 12:49:52 but can you please check luna-universalsearchmgr? there were few commits from you not included in the build yet Feb 22 12:50:02 adding and renaming systemd service file for it Feb 22 12:50:23 in case you want to update the recipe as well Feb 22 13:02:34 JaMa: https://github.com/shr-distribution/meta-smartphone/pull/57/files Feb 22 13:02:40 Let me check luna-universalsearchmgr Feb 22 13:03:34 Merged Feb 22 13:04:40 https://github.com/webOS-ports/meta-webos-ports/commit/13a17da7b08d1a775a11530675ddf60d4b0dd2ca Feb 22 13:12:35 JaMa: You'd need to add inherit webos_systemd Feb 22 13:12:37 To the recipe Feb 22 13:14:54 For some strange reason, button gpio values are inverted, strange Feb 22 13:27:13 Herrie|Laptop: yes, but do we want it? it's quite long time since you merged those changes and for some reasons you didn't enable it in the recipe :) Feb 22 13:27:30 1,5 years Feb 22 13:28:13 JaMa: I must have simply forgotten it, quite sure Feb 22 13:28:20 k Feb 22 13:39:48 JaMa: I updated https://github.com/webOS-ports/webos-systemd-services/commit/cc4f842f9b21905ffd5a433ee1569144cd8f44a8 Feb 22 13:41:31 good, should I finish it? Feb 22 13:41:52 I'm almost done with qtwebengine build [15345/16534] to test it Feb 22 13:42:23 And this one: https://github.com/webOS-ports/meta-webos-ports/commit/65afe1042b3ead83051609a22bea576cd2c438f3 Feb 22 13:42:28 So you should be good to go Feb 22 13:42:34 But you'd need to cherry pick that to your correct branchs Feb 22 13:43:04 ok :) Feb 22 13:53:57 bshah: You around? Feb 22 13:56:42 yep Feb 22 13:59:20 bshah: I couldn't find it by searching, so I thought to pick your brain... Where the android-headers from https://github.com/Halium/android-headers are pulled into the Halium minimal Android build? Feb 22 13:59:35 I would expect it here: https://github.com/Halium/android/blob/halium-5.1/default.xml Feb 22 13:59:38 But couldn't find it? Feb 22 13:59:42 Or.... ? Feb 22 13:59:49 It's other way around Feb 22 14:00:00 Halium minimum build produces teh android-headers Feb 22 14:00:16 bshah: Ah OK Feb 22 14:00:30 That explains Feb 22 14:00:53 see libhybris/utils/extract-headers.sh Feb 22 14:00:55 Just suspect the issues I'm having with my mido might be due to wrong headers that we pull in Feb 22 14:01:15 brb.. going for dinner Feb 22 14:02:09 bshah: OK enjoy! Feb 22 15:24:19 bshah: Back from dinner? Feb 22 15:24:21 Herrie|Laptop, Tofe, JaMa: ping? Feb 22 15:24:29 Herrie|Laptop: oh yeah, while back Feb 22 15:24:36 sorry forgot to write here Feb 22 15:24:42 bshah: No worries Feb 22 15:24:55 So where is this extract-headers script run in the Halium build? Feb 22 15:25:06 I hate that GitHub doesn't search code in forks :P Feb 22 15:25:11 it's in libhybris/utils/ Feb 22 15:25:20 bshah: Yeah Feb 22 15:25:30 bshah: Yeah Feb 22 15:25:40 But it's being run at some point during the build I assume? Feb 22 15:25:42 Or not? Feb 22 15:25:51 no, it's one time thing Feb 22 15:25:56 and manual Feb 22 15:27:38 bshah: Ah OK Feb 22 15:28:39 But I need to make sure I use the headers in android-headers for my pulseaudio-modules-droid, libhybris build etc as well right? So the ones from android-headers should theoretically match the ones I have in my local build tree for my device Feb 22 15:28:43 To avoid any issues Feb 22 15:29:34 yeah right.. well android-headers are extracted from the halium build-tree so they should be up-to-date already Feb 22 15:30:48 bshah: Well we tale the halium-7.1 branch now, while I think we should take the caf-compat/24 ? Feb 22 15:30:56 s/tale/take Feb 22 15:31:07 There's not a lot of difference between them but still Feb 22 15:31:24 Any reason why we don't have a 25 folder? 7.0 = API 24, 7.1.x = API 25 Feb 22 15:31:26 you mean this? https://github.com/halium/android-headers/tree/caf-compat Feb 22 15:31:31 Yeah Feb 22 15:31:41 no, don't do that Feb 22 15:31:58 it needs patch in libhardware as well Feb 22 15:34:27 bshah: OK Feb 22 15:35:01 bshah: I see you're doing https://github.com/halium-packaging/android-headers/blob/halium-7.1/debian/genconf.sh which I guess is something we should adopt in our build too Feb 22 15:35:51 Because currently we're passing these build flags to each of the components that need them manually to trigger it in the headers. I guess it would be better if we patch it based on target device. Feb 22 15:36:32 I.e. we're currently passing QCOM_BSP, QTI_BSP etc to pulseaudio-modules-droid, libhybris, qt5-qpa, qtscenegraph, nyx-modules etc Feb 22 15:36:35 Which is not ideal of course Feb 22 15:37:48 If we would adopt a similar approach like you do with te halium-packaging we wouldn't need to do that ;) Feb 22 16:15:37 novaldex: pong Feb 22 16:18:47 hey JaMa, i'm looking for a quick outage for Jenkins to take care of a few things Feb 22 16:19:03 really i'm hoping for mere minutes (server/service restarts) Feb 22 17:32:22 Herrie: you know, it's actually pretty easy for us to do the equivalent of Halium's genconf.sh Feb 22 17:33:05 Just insert a similar thing in do_install_append in android-headers recipe bbappend for each target device Feb 22 17:33:33 We didn't do that so far mainly because there was only one black sheep (i.e. TP ;) ) Feb 22 17:34:19 I can try to sketch something Feb 22 17:36:50 ... and actually it's already ready :p Feb 22 17:37:17 (or nearly ready) Feb 22 17:41:18 novaldex: did you get the e-mail I've sent to Tom? or give me your preferred e-mail and I'll fw it to you Feb 22 17:41:39 novaldex: the builds should finish in an hour or 2 Feb 22 17:41:48 if you want it sooner, then I'll abort current build Feb 22 17:41:53 JaMa: yes, about Milla? he forwarded it on to me Feb 22 17:42:07 i've taken care of a couple of things, but would like to deal with the reboot Feb 22 17:42:21 milla and more importantly kaylee Feb 22 17:42:23 thanks for the heads up re:builds, i've been watching it Feb 22 17:42:37 yes, i've got some things to do to Kaylee too Feb 22 17:42:50 mostly disk related, was there something else? Feb 22 17:43:23 13GB of /var/log/jenkins/jenkins.log for whatever reason :) Feb 22 17:43:59 wow.. probably no log rotation, okay i'll add it to my list Feb 22 17:44:10 there is log rotation Feb 22 17:44:14 fwding the e-mail Feb 22 17:44:19 ta Feb 22 17:45:24 you can reboot milla even when builds are running Feb 22 17:46:19 well most of the time, it wouldn't be good when the builds are just starting or when one of rsync jobs is running but in general it's quite safe Feb 22 17:46:27 thanks for the email, I removed the oe-sources-old dir already, although it only freed ~500M Feb 22 17:46:54 even 500MB is good when we had only 14MB left Feb 22 17:47:18 when I looked however, it was only about ~18% used.. which I found quite surprising Feb 22 17:47:44 can Kaylee be rebooted during builds, or should that wait till they're all done? Feb 22 17:47:45 because I've deleted almost everything to unblock the builds Feb 22 17:48:23 kaylee reboot would kill the builds I think, it shouldn't cause disaster, but aborting the builds before the reboot would be much preferred Feb 22 17:48:28 makes sense! :) Feb 22 17:48:57 so that the job is aborted and hopefully properly terminated on the slave, otherwise I'm often seeing left-over processes there Feb 22 17:49:06 i'll wait till it's all idle, i'm only looking for a short period, but might be in the morning before I get a proper chance Feb 22 17:49:13 so you cannot start the job after the reboot, because of conflict with the left-over one Feb 22 17:49:25 yep, best to wait till idle then Feb 22 17:49:36 I can abort it now if you're ready to reboot Feb 22 17:49:44 I wanted to trigger new round anyway tonight Feb 22 17:49:59 so better to do it immediatelly after reboot :) Feb 22 17:50:21 i'm just about to head out for half an hour or so.. how long will the next job run take? if it's about 14hours, that's a good thing Feb 22 17:51:06 an hour or 2 Feb 22 17:51:13 "hopefully" :0 Feb 22 17:51:19 :D Feb 22 17:51:31 let's leave it running for now, i'll try & check in again in a couple Feb 22 17:51:34 let me abort it now and please trigger luneos-testing_build-all when you're done with reboot Feb 22 17:52:41 it's yours whenever you have time Feb 22 17:52:52 thanks, i'm going to try & quickly take care of it now Feb 22 17:52:59 cutting it close, but hey! Feb 22 17:54:14 okay, jenkins should be coming back up (it was only a service restart I needed) Feb 22 17:55:42 build triggered Feb 22 17:55:56 back shortly Feb 22 17:56:01 thanks Feb 22 18:01:02 JaMa: Got a bitbake recipe question Feb 22 18:02:53 We need to apply some patch in android-headers which is not generic, so it would need to be applied for some devices but not for all Feb 22 18:03:59 Herrie|Pre3: I'm in the middle of it :) Feb 22 18:07:14 ... nearly finished Feb 22 18:08:12 ok, done, I think. Feb 22 18:08:37 Now I need to do quite some cleanup for tenderloin Feb 22 18:10:33 Tofe: Ah ok Feb 22 18:11:45 You understand what I want to do right? Replicate halium to patch the headers to define QCOM_BSP, QTI_BSP and maybe QCOM_HARDWARE and DIRECTTRACK Feb 22 18:12:05 So we don't need to pass these for all components Feb 22 18:12:33 yep, that's exactly what I did Feb 22 18:12:51 Tofe: OK that makes sense because it will be doing it one time per target Feb 22 18:13:12 https://github.com/shr-distribution/meta-smartphone/commit/f563f6cc6b3fc0a241248e409204f56494762554 Feb 22 18:14:38 I'm now doing some a cleanup commit for tenderloin; I could do that for xiaomi too, but I can't test it... Feb 22 18:15:06 the issue (if I recall correctly) is that we have a dependency on android-headers in many components and it effectively makes everything to be MACHINE_ARCH, right? Feb 22 18:15:41 JaMa: only those who have a direct dependency Feb 22 18:16:15 libhybris is at the same level as android-headers, and is already machine_arch Feb 22 18:16:26 JaMa: Quite some things, libhybris, pulse-audio-modules-droid, qt5scenegraph-adaptation, qt5-qpa, nyx-modules-hybris, sensorfw and maybe a few more Feb 22 18:16:32 and everything which depends on them Feb 22 18:17:19 SIGGEN_EXCLUDERECIPES_ABISAFE += "libhybris" Feb 22 18:17:33 but we don't have that for android-headers IIMHO Feb 22 18:17:58 and if they contain MACHINE specific config then it might be bad idea to add it to SIGGEN_EXCLUDERECIPES_ABISAFE Feb 22 18:17:58 oh, so that's why... One mystery solved ! Feb 22 18:18:15 Tofe: Isn't there an easier way? I would prefer to set a flag in the machine.conf and then the patch is applied based that flag Feb 22 18:18:51 Herrie|Pre3: we could do that too Feb 22 18:18:59 Herrie|Pre3: that has the same implication for OE build Feb 22 18:19:19 Herrie|Pre3: I just wanted to copy halium-packaging as a start Feb 22 18:20:25 But you're right, we could have something like ANDROID_HEADERS_DEFINES="QCOM_BSP,QTI_BSP" and it would generate the ad-hoc defines Feb 22 18:21:24 but I'm not saying that it's wrong to make them MACHINE_ARCH, if qt5-qpa-hwcomposer-plugin, pulse-audio-modules-droid, qt5scenegraph-adaptation, nyx-modules-hybris, sensorfw and whatnot are producing different binaries when built against these android-headers differences, then they need to be marked as MACHINE_ARCH Feb 22 18:21:44 even when it costs more build time Feb 22 18:22:13 but in ideal world it would be identical binary which just alters the behavior for each MACHINE based on configuration read in runtime Feb 22 18:22:29 like FSO was doing :) Feb 22 18:23:38 JaMa: we could reduce the number of different scenarios: we basically have Nexus headers (no additional defines) and TP/Xiaomi headers (with the QCOM_* and QTI_* defines) Feb 22 18:24:15 So it's not really machine specific, but more config specific Feb 22 18:24:58 true, but then we would need to add another PACKAGE_ARCH between them Feb 22 18:25:14 like TUNE_PKGARCH, SOC_PKGARCH (QCOM, QTI), MACHINE_ARCH Feb 22 18:25:35 some BSPs are already doing magic like that (e.g. meta-freescale) Feb 22 18:25:50 Ah. Hum. Feb 22 18:27:10 But let me check first if it actually changes the ABI of the packages that depend on android-headers Feb 22 18:28:02 now we have 5 TUNE_PKGARCHs in the builds Feb 22 18:28:05 aarch64 armv7ahf-neon cortexa7hf-neon core2-64 i586 Feb 22 18:28:17 We shouldn't have indirect header includes, so it might be alright Feb 22 18:28:30 IIRC cortexa7hf-neon-vfpv4 is shared by hammerhead, mako, tenderloin Feb 22 18:28:49 JaMa: something like that yes Feb 22 18:28:57 so we sould need to split tenderloin to it's own PACKAGE_ARCH Feb 22 18:29:29 which adds around 6 hours on our builder Feb 22 18:29:50 more annoying for you if you build locally e.g. for mako and tenderloing Feb 22 18:30:03 where the 2nd one was now almost for free Feb 22 18:30:10 now it will be bigger rebuild Feb 22 18:30:23 JaMa: it's quite costly yes - I'd prefer using SIGGEN_EXCLUDERECIPES_ABISAFE if it's actually safe Feb 22 18:30:30 if it's applied only for android-headers and above, it won't be so bad Feb 22 18:31:19 SIGGEN_EXCLUDERECIPES_ABISAFE won't be safe with android-config_tenderloin.h Feb 22 18:31:59 JaMa: even if noone uses android-headers indirectly ? Feb 22 18:32:29 I mean that's the whole point of these abstraction layers after all Feb 22 18:32:59 (well, not exactly, but it should work here) Feb 22 18:33:14 it's not safe even for libhybris :) Feb 22 18:33:38 sec, need to wash baby, then will explain a bit more Feb 22 18:33:43 ok :) Feb 22 18:40:14 the problem is that android-headers (with android-config_tenderloin.h) isn't stable abstraction API (shared by all MACHINEs) because it constains also the MACHINE specific configuration, e.g. this QCOM_BSP variable, so if qt5-qpa-hwcomposer-plugin uses this QCOM_BSP variable and produces different binary based on the value, then it's not really abstract Feb 22 18:41:11 we have this problem elsewhere as well, e.g. GL headers are in theory stable API and different binary blobs will adhere to the same API defined in the header files Feb 22 18:42:16 but even when libhybris and mesa provide the same header files (they probably aren't even identical now) then OE cannot trust that the API from 2 different recipes is actually the same Feb 22 18:43:14 some BSPs try to work around that by separating just the headers (so mesa-gl can provide just the headers) and your BSP provided blob will provide e.g. libmali.os which should be compatible Feb 22 18:44:52 but in the end it isn't because do_package task in the recipes which were built against mesa-gl headers will still find libmali.so as the runtime provide for the ABI and it will libmali.so will be in NEEDED section of the binary and do_package will try to add whatever provides libmali.so to package RDEPENDS Feb 22 18:45:16 we get away with e.g. libhybris as SIGGEN_EXCLUDERECIPES_ABISAFE Feb 22 18:45:41 because all our supported cortexa7hf-neon-vfpv4 MACHINEs are using libhybris and we don't care about other MACHINEs Feb 22 18:46:27 but if we add some qemuarmv7 with the same cortexa7hf-neon-vfpv4 DEFAULTTUNE and mesa as libgl provider we would break the binary feeds Feb 22 18:47:18 JaMa: but I'm not implying qt5-qpa-hwcomposer-plugin or libhybris wouldn't be MACHINE_ARCH; they are, of course. What I'm implying is that libhyris (or qt5-qpa-hwcomposer-plugin for instance) does a good enough abstraction that all the code that relies on them never actually uses the android headers Feb 22 18:47:32 and opkg upgrade on qemuarmv7 would install e.g. some library from qt5-qpa-hwcomposer-plugin which would be linked agains libmali.so and libmali.so won't be on qemuarmv7 rootfs Feb 22 18:48:35 ok Feb 22 18:48:40 but then there is one other issue Feb 22 18:48:46 ah :/ Feb 22 18:49:13 once we say that libhyris is perfect abstraction and the differences in android-headers aren't never exposed to users of libhybris Feb 22 18:50:07 then we should exclude only libhybris->android-headers signature, not whole libhybris Feb 22 18:50:41 because libhybris in SIGGEN_EXCLUDERECIPES_ABISAFE also means that what ever is changed in libhybris never changes the API/ABI to users of libhybris Feb 22 18:51:03 oh ok, that's not correct :) Feb 22 18:51:13 if you rename libhybris library to something else, nothing will get rebuilt against the new library Feb 22 18:51:19 and again the binary feed gets broken Feb 22 18:51:40 I must say I'm brand new to this signature area Feb 22 18:51:53 But I understand what you're saying Feb 22 18:52:18 Would there be an easy way to isolate that signature ? Feb 22 18:52:26 or, well, a way ? Feb 22 19:01:39 SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS maybe ? Feb 22 19:05:34 mmmh not exactly it seems. putting "libhybris->android-headers" there would mean libhybris doesn't need to be rebuilt when android-headers changes, which is incorrect Feb 22 19:09:30 SIGGEN_EXCLUDERECIPES_ABISAFE says the same Feb 22 19:10:17 but you're right, it's not correct Feb 22 19:10:46 and there isn't a variable (and I think there cannot be) which would say: Feb 22 19:11:23 if libhybris was changed, but only because of slightly different android-headers (with different config file) then you don't need to rebuild users of libhybris Feb 22 19:11:46 exactly Feb 22 19:12:02 there are some attempts to run something like ABI checker on the actual build output Feb 22 19:12:28 and then collecting the sstate signatures in some equivalence groups Feb 22 19:12:50 I wonder if we can achieve that with some adapted dependency and package split Feb 22 19:13:26 so that you don't need to rebuild the users if the new binary is considered by ABI checker to be the same as the previous one (or in our case if mako libhybris is the same ABI as hammerhead libhybris) Feb 22 19:13:59 but those attempts didn't get very far Feb 22 19:14:43 it's described here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 Feb 22 19:15:22 and BMW was working on it recently https://lists.yoctoproject.org/pipermail/yocto/2017-June/036920.html Feb 22 19:16:22 some people and companies just give up and build everything as MACHINE_ARCH Feb 22 19:16:56 as build servers tend to be cheaper than time of engineers able to resolve this in safe way Feb 22 19:17:12 I understand, but well :) Feb 22 19:17:57 I don't really see the difference between their CDEPENDS and SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS Feb 22 19:18:15 ah, it's per-recipe Feb 22 19:18:42 my not recommended work around for long time was to use OEBasic instead of OEBasicHash signature handler and then being very careful to know when I need to manually rebuild some stuff Feb 22 19:18:59 and then when there is plenty of time (e.g. over the weekend) doing clean build without sstate Feb 22 19:19:08 but that's really not for everybody Feb 22 19:19:30 Yes I guess so :) Feb 22 19:20:03 CDEPENDS would include only your parent Feb 22 19:20:45 but let's say qt5-qpa depends on both android-headers and qtbase... and qtbase changes... then it's not adapted either Feb 22 19:20:57 so you won't rebuild libhybris users when e.g. zlib caused libhybris rebuild, but the users of libhybris don't use zlib by themselves Feb 22 19:22:05 It's a bit surprising that the mechanism doesn't exist yet; for libraries it's quite often that you are rebuilt, but you don't change your ABI Feb 22 19:22:37 with OEBasic it was almost like that Feb 22 19:22:51 you had to do manual PR bumps in all users when the ABI was changed Feb 22 19:23:08 OEBasicHash is "better-safe-than-sorry" and rebuilds everything just in case Feb 22 19:23:22 and anything between these 2 is hard to implement :/ Feb 22 19:23:25 Can that be done per-recipe ? Feb 22 19:23:38 what? Feb 22 19:23:40 Using OEBasic Feb 22 19:23:46 no Feb 22 19:23:52 or at least I don't think so Feb 22 19:24:07 ah, ok; that's sad, it would have been a pretty good solution here Feb 22 19:24:11 you can write your own signature handler Feb 22 19:24:29 which can do some clever stuff tailored exactly for your use-case Feb 22 19:24:53 I can at least look at it, for educational purpose Feb 22 19:25:02 but as it's now, the signatures are all calcuated before the task queue is constructed Feb 22 19:25:15 so you cannot look at build outputs and then prune the dependency tree Feb 22 19:25:47 Tofe: you can look at http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/OEBasickHashLite Feb 22 19:26:08 But I could say in a recipe that "this dependency doesn't break my ABI", and take that into account for the signature computation Feb 22 19:26:31 not in the recipe, but in the signature handler Feb 22 19:26:42 the OEBasicHash already has couple exceptions as well Feb 22 19:27:06 ah ok; they should just make it more flexible then ;) Feb 22 19:28:42 yes, in that bug I've described some ideas, but I haven't even started working on it, because even the idea was rejected that it would be too difficult for people to use the added flexibility correctly Feb 22 19:29:05 to be honest very few people really understand the implications of SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS and SIGGEN_EXCLUDERECIPES_ABISAFE Feb 22 19:29:30 It's very specialized Feb 22 19:29:56 Maybe I should have written much longer commit message :) http://git.openembedded.org/openembedded-core-contrib/commit/meta/lib/oe/sstatesig.py?h=jansa/OEBasickHashLite&id=d73c139fd73ee268d29837db6ccc69c412022d6e Feb 22 19:31:15 and there weren't many changes in OEBasicHash since 2012 so this status quo probably works for most people http://git.openembedded.org/openembedded-core/log/meta/lib/oe/sstatesig.py Feb 22 19:32:19 personally I gave up a while ago Feb 22 19:32:49 at work the reviews I trigger the build for are built for all MACHINEs in parallel Feb 22 19:32:53 I'll have a look at it, but as a lot of people already worked on it I guess the main ideas have already been tried Feb 22 19:33:02 so even when they share the TUNE_PKGARCH the build time would be almost the same Feb 22 19:33:51 at LG we have MACHINE_ARCH for everything Feb 22 19:34:31 and with LuneOS we also don't support 50 different MACHINEs Feb 22 19:35:27 currently we build 8 MACHINEs and still have 5 TUNE_PKGARCHs Feb 22 19:35:58 having 8 MACHINE_ARCH wouldn't make so big difference anymore Feb 22 19:37:12 and as bonus we would be using the best optimalization for each MACHINE, instead of selecting common denominator for at least a small group of them Feb 22 19:38:10 well I didn't want to discourage you so much, but I think your time might be more valuable spent somewhere else :) Feb 22 19:38:25 fancy qt 5.11? I just finished update in meta-qt5 for 5.11 Alpha :) Feb 22 19:39:00 :p Feb 22 19:45:28 gtg, hf :) Feb 22 20:47:42 Ooh lots of discussion while the two little ones and dinner kept me occupied.... Feb 22 20:49:14 Couldn't we simply have 4 variants of android-headers? I.e. 5.1 For Nexus, 5.1 for QCOM, 7.1 for Nexus and 7.1 for QCOM? And specify in machine.conf which one we want? Feb 22 20:49:40 Not that clean maybe but could work? But I guess I might be oversimplifying :-P Feb 22 21:40:53 TIL webos "disables" the volume down GPIO button if the sound slider has been set to "off", and this setting persists outside the OS too! **** ENDING LOGGING AT Fri Feb 23 03:00:01 2018