**** BEGIN LOGGING AT Sat Nov 05 03:00:01 2016 Nov 05 04:09:13 Herrie, #4bd2ff is a much better color than red for links. Nov 05 06:54:04 morning Nov 05 06:54:10 Andolamin: ping Nov 05 09:09:10 Morning! Nov 05 09:47:58 Tofe: morning! Nov 05 10:33:21 Herrie: I'm now trying to build our boot image using bb Nov 05 10:33:51 I'm directly using CM-13 kernel, with their defconfig + our LuneOS options Nov 05 10:42:32 Tofe: OK, curious about results :) Nov 05 10:43:05 me too! Nov 05 10:45:43 weird, I've got a complaint about using gcc5 Nov 05 10:45:54 like this one http://stackoverflow.com/questions/33550251/fatal-error-linux-compiler-gcc5-h-no-such-file-or-directory-during-bitbake Nov 05 10:46:28 I'm pretty sure I did compile CM13 with gcc5 too... Nov 05 10:48:01 Tofe: Quite sure CM is using GCC 4.9 toolchain Nov 05 10:48:08 That's what I was talking about before ;) Nov 05 10:48:20 I must have missed something in there... Nov 05 10:48:34 Hence we have this separate process to build the CM bits currently... Because it uses other toolchain compared to BB Nov 05 10:48:39 At least that's how I understood it.... Nov 05 10:48:47 morphis or JaMa might know better... Nov 05 10:49:44 That's fine, I'm just surprised I missed a step so big :p Nov 05 10:50:31 Tofe: Well for just building CM bits you should be fine Nov 05 10:50:42 But then when you try to integrate it into BB you run into errors Nov 05 10:50:59 Hence we have these meta-smartphone bits I think Nov 05 10:51:34 So then I'll have to rebase our yocto kernel onto CM13's one? Nov 05 10:51:47 Tofe: I'm really not sure.... Nov 05 10:51:59 both are 3.4.0, it shouldn't diverge that much, except for drivers Nov 05 10:52:25 Tofe: We do this for Tenderloin: https://github.com/shr-distribution/meta-smartphone/blob/krogoth/meta-hp/recipes-kernel/linux/linux-hp-tenderloin_git.bb Nov 05 10:52:38 Which takes the kernel parts from http://build.webos-ports.org/cm-wop-11.0/cm-wop-11.0-${BUILD_VERSION}-kernel-parts-tenderloin.tar.bz2 Nov 05 10:53:05 wow, that's hacky :p Nov 05 10:53:26 Which is generated by http://jenkins.nas-admin.org/job/cm-wop-11.0-build/93/consoleFull Nov 05 10:54:20 Which seems to use 4.7 toolchain: "make -C kernel/google/msm O=/home/jenkins/cm-wop-11.0/out/target/product/mako/obj/KERNEL_OBJ ARCH=arm CROSS_COMPILE="/home/jenkins/cm-wop-11.0/prebuilts/misc/linux-x86/ccache/ccache /home/jenkins/cm-wop-11.0/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7/bin/arm-eabi-" VARIANT_DEFCONFIG= SELINUX_DEFCONFIG= cyanogen_mako_defconfig" Nov 05 10:55:23 Not sure how we do this for Mako though Nov 05 10:55:47 For mako we're building kernel from source the usual way Nov 05 10:56:03 Ah ok Nov 05 10:56:06 I see now Nov 05 10:56:25 I would prefer doing this too, it's more easy to follow Nov 05 10:56:58 but it's good to know we have another way to get the results Nov 05 10:57:15 Tofe: Maybe the CM13 source you use for the kernel is missing stuff like: https://github.com/shr-distribution/linux/commit/bf75b75a0a2b0f399539822e5cfb91194eb57667 Nov 05 10:57:42 ah, well done, yes Nov 05 10:57:48 I'll try this right now Nov 05 10:58:08 I guess our 3.4 kernel comes from CM10.1 or CM11 Nov 05 10:58:24 And JaMa added the patches for the kernel to make it work with newer GCC Nov 05 10:58:32 Which might be missing from CM13? Nov 05 10:58:54 Since from what I can see Google/CM still uses max GCC 4.0 toolchain for their bits Nov 05 10:59:08 Not sure why because 5 and 6 offer some performance improvements Nov 05 11:01:56 I'll see if I need other patches Nov 05 11:03:16 Tofe: Seems that https://github.com/CyanogenMod/lge-kernel-mako/tree/cm-13.0/include/linux is indeed missing the required compiler-gcc5.h Nov 05 11:03:37 There's a fix upstream to get rid of this compiler-gccX.h altogether Nov 05 11:03:39 Let me see Nov 05 11:04:11 I've applied that one, now I'm one the next error Nov 05 11:05:18 https://github.com/torvalds/linux/commits/master/include/linux/compiler-gcc.h Nov 05 11:05:33 Seems you're after cb984d101b30eb7478d32df56a0023e4603cba7f Nov 05 11:05:45 Not sure it would break stuff if you add the commits afterwards Nov 05 11:07:30 Tofe: It's quite likely you'll need most of the patches JaMa put in our 3.4 branch Nov 05 11:07:39 He usually put them there because it broke builds :P Nov 05 11:08:00 JaMa doesn't really do anything in that branch unless it breaks something in a build Nov 05 11:08:10 So he searches for a fix and makes sure it builds again Nov 05 11:08:41 So I would apply all the commits 2014 to 2016 Nov 05 11:09:02 worth a try Nov 05 11:09:42 Tofe: I'd say so probably Nov 05 11:10:10 ok let me get this right Nov 05 11:36:02 https://github.com/Tofee/android_kernel_google_msm/commits/mako/3.4/cm-13.0 Nov 05 11:36:35 We'll see what comes out of that Nov 05 11:38:49 That should help quite a bit I'd say Nov 05 13:33:43 mmh the verify script for defconfig isn't very precise... our current defconfig for mako doesn't even pass :) Nov 05 13:36:27 ok, I've got a kernel now Nov 05 13:53:01 :) Nov 05 13:53:11 I hope you document what you're doing so we can replicate it :P Nov 05 15:58:05 Herrie: well, it's not so far away from what has been done for other kernels, or from what was written for CM Nov 05 15:58:16 but I've got all the steps, yes :) Nov 05 16:10:47 Tofe: Good, so we can replicate for 12.1 based builds & other targets ;) Nov 05 16:11:02 I think Andolamin has some OnePlus device laying around he'd like to toy with ;) Nov 05 16:12:37 well, currently bitbake isn't happy at all with the android-system-image I'm providing, so the methodology isn't perfect yet Nov 05 16:12:46 Herrie: OnePlus X, and pong Nov 05 16:13:30 Herrie: but I only had to fork 4 android repos, so that's quite nice Nov 05 16:14:40 Herrie: I've got a lot of uid warning for instance... do we also get that with our current android system image ? Nov 05 16:15:12 "android-system-image-mako: /android-system-image-mako/system/lib/libdrmfs.so is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination" Nov 05 16:16:20 Tofe: Yeah I've seen that before Nov 05 16:16:24 I think we can ignore that in general Nov 05 16:16:30 There's quite an easy fix for it I think Nov 05 16:16:40 Let me find it Nov 05 16:16:45 a recurvive chown ? :) Nov 05 16:17:27 Also there's this error: "do_package_qa: QA Issue: non -dev/-dbg/nativesdk- package contains symlink .so: android-system-image-mako path 'work/mako-webos-linux-gnueabi/android-system-image-mako/20150313-115-r0/packages-split/android-system-image-mako/system/lib/libGLESv3.so' [dev-so]" Nov 05 16:17:44 I think I just have to delete the .so from the .tbz Nov 05 16:27:35 ok I fixed it by replacing the symlink by a hardlink Nov 05 16:28:38 Andolamin: Any luck with the Pi ? Nov 05 16:29:32 Tofe: This is what we did in another recipe: https://github.com/webOS-ports/meta-webos-ports/commit/91e05165f88ed16c48603501523a1602c719cd34 Nov 05 16:30:15 Some, lots of promising patches went in recently - actually waiting for a build to finish right now Nov 05 16:30:17 Herrie: I tried --owner=0 when calling tar, but with no luck Nov 05 16:30:46 Now I'm on a problem with memnotify-module, which doesn't build anymore... Nov 05 16:32:14 Tofe: Hmmmz Nov 05 16:32:20 Do we need it in general? Nov 05 16:32:30 I think that was something morphis added at some point? Nov 05 16:33:10 well, ok, but it's not a reason for it a fail :p Nov 05 16:33:58 Tofe: True Nov 05 16:34:05 Strange because it DID work with Krogoth & Morty Nov 05 16:34:09 With GCC 6 even Nov 05 16:34:15 So not sure what error you're getting? Nov 05 16:34:45 It could be because of an incorrect defconfig Nov 05 16:37:31 Tofe: https://github.com/shr-distribution/linux/commit/90118260d5e0354ad96e0da376959deb0d6de636 ? Nov 05 16:38:09 That's something I'll try next Nov 05 16:40:22 Tofe: quite sure this might be it ;) Nov 05 16:40:27 Signed-off-by: Leonid Moiseichuk Nov 05 16:40:36 https://github.com/webOS-ports/memnotify-module/blob/master/memnotify.c#L5 Nov 05 16:40:37 ;) Nov 05 16:41:20 nope, it wasn't this: it was MODULES=n in defconfig, which should be MODULES=y Nov 05 16:41:46 ok, now let's see how far this build can go! Nov 05 16:42:22 oh it jumps to root_fs directly... that was surprising. I would have thought that systemd needed a rebuild. Nov 05 16:42:46 Then I guess it's testing time! Nov 05 16:42:59 :D Nov 05 16:43:43 It'd be surprised if it doesn't bootloop on a first try ;) Nov 05 16:44:28 me too Nov 05 16:44:44 but first, I'm installing cm13 Nov 05 16:51:00 ok, cm-13 looks alright Nov 05 16:53:21 taking bets... Nov 05 16:58:09 no bootloop, but no android container Nov 05 17:03:50 ah, my kernel is missing PID namespace somehow Nov 05 17:13:06 Tofe: Not sure I understand Nov 05 17:13:48 well, I didn't set CONFIG_PID_NS=y because the kernel didn't compile with that Nov 05 17:14:02 but it looks like I'll have to fix the compilation Nov 05 17:29:41 ok, lxc now starts, but the whole android stuff crashes :( Nov 05 17:32:08 I feel like use mer-hybris maybe wasn't such a good idea after all: the image I've built must be a bit hybrid Nov 05 17:54:17 * DougReeder checks in Nov 05 17:57:26 Tofe: The only real difference afaik is that we use lxc and Mer guys not? Nov 05 17:57:43 For basic Android bits there shouldn't be much difference? Nov 05 17:58:16 They use hybris-boot that we don't. Not sure how that influences thingss Nov 05 17:59:22 Is there any word on the webos-ports Preware feed? Nov 05 17:59:46 DougReeder: Sorry didn't get to check on that yet. Nov 05 18:00:16 * DougReeder nods. “No rush, but it doesn’t look very professional. :-( Nov 05 18:00:36 novaldex|away: pong me when you're around :p Nov 05 18:00:40 Herrie|Pre3: I also fear they changed a bit the libGLES things somehow Nov 05 18:00:55 but that's really a wild assumption, I didn't really look into it Nov 05 18:01:16 Did you push all your code to GH? Nov 05 18:01:58 First step would be to compare the .xml between our 10.1/11 and the 13 version to see if there's anything odd. Nov 05 18:03:08 I'm surprised you only needed 4 repos. We have quite some more for 10.1/11 I think. There must be a reason for that. Nov 05 18:05:33 DougReeder: We do have a Jenkins job that generates the feed I think. I can see if I can run that. Maybe that will generate stuff. Nov 05 18:06:16 * DougReeder nods. “Currently, it returns 404 Nov 05 18:08:03 Tofe: it's all on GH, yes Nov 05 18:08:14 ah wait, no, not the local manifest I used Nov 05 18:08:57 I'll go out for diner, but I can put in place a little gist with the mako.xml local manifest I was using Nov 05 18:09:55 https://gist.github.com/Tofee/946d3c90ffd516a5f1ce929dd246191f Nov 05 18:10:44 Actually, http://feeds.webos-ports.org/ and all the directories return 404, so it looks like the files for the website have vanished. Nov 05 18:22:03 DougReeder: novaldex did some big server updates & maintenance. Some loose ends like this need fixing still. Nov 05 18:22:46 * DougReeder nods Nov 05 18:23:28 Tofe: thnx will have a look. Enjoy dinner! Nov 05 18:28:00 DougReeder: http://jenkins.nas-admin.org/job/luneos-preware-feeds/lastBuild/console Nov 05 18:28:03 It's running Nov 05 18:28:15 * DougReeder looks Nov 05 18:28:36 Hmmz it says it synced stuff but it's not on the url Nov 05 18:31:26 * DougReeder nods Nov 05 18:48:03 DougReeder: Seems I don't have the feeds in htdocs folder :S Nov 05 18:48:25 I guess I'll need ka6sox or novaldex|away for this ;) Nov 05 18:48:40 It runs on Bonaire where our builds also run Nov 05 18:48:48 These end up fine at the right locations Nov 05 18:50:22 * DougReeder nods Nov 05 19:18:00 Tofe: There are a dozen or so commits at the bottom of https://github.com/webOS-ports/android_build/commits/wop-11.0New which I guess we'll need some.... Nov 05 19:20:55 The same would apply for https://github.com/webOS-ports/android_system_core/commits/wop-11.0New?after=zs1ezr04NPPYcOJO1ePyi8W6gwUrMzQ%3D Nov 05 19:21:55 And the same with https://github.com/webOS-ports/android_bionic Nov 05 19:22:05 Not sure to what extend the hybris guys have all this Nov 05 19:22:19 Some of the committer names look familiar ;) Nov 05 19:23:28 And a few more in https://github.com/webOS-ports/android_frameworks_native/commits/wop-11.0New it seems Nov 05 19:24:01 It's not a lot in general, just a handful (or 2) of commits it seems in each repo to make sure stuff behaves with hybris Nov 05 19:30:05 Tofe: I'm not a big fan of forking the whole repo to just apply a single patch. We should be able to do something nicer with bitbake eventually with some patches instead Nov 05 20:25:22 Herrie: I totally agree for the patches; putting in place a bitbake recipe for this would be great Nov 05 20:38:57 Tofe: Might be a bit tricky to get the order right in bitbake, but worth the effort for future I guess Nov 05 20:39:02 Seems bionic might need some work Nov 05 20:47:33 Tofe: These 3 seem to be "missing": https://github.com/webOS-ports/android_bionic/commit/3b81b31c783b1ccf57080afe1d5a91d5aac34ffc (seems no longer needed probably in cm13), https://github.com/webOS-ports/android_bionic/commit/eacec4bc20981034217103246cfd8222897bdd0a (seems ubuntu specific, not sure why morphis put it, but must have had a reason, not in mer-hybris currently) and Nov 05 20:47:33 https://github.com/webOS-ports/android_bionic/commit/7365f5dc53febac1ed3281869ff4e96220b6f470 (not in mer-hybris, not sure what this does and if it's still needed) Nov 05 22:13:29 I don't suppose there's any way to get LuneOS running on toro? (CDMA galaxy nexus) Nov 05 22:21:19 Herrie: second one might be good to have, and 3rd one is essential, I don't know why mer-hybris doesn't have it **** ENDING LOGGING AT Sun Nov 06 02:59:59 2016