**** BEGIN LOGGING AT Wed Oct 03 03:00:01 2018 Oct 03 05:24:34 Morning! Oct 03 05:31:41 morning Oct 03 05:34:54 how much are people attached to tenderloin/hammerhead targets? Oct 03 05:35:34 yesterday I've spent some time trying to fix their 3.4 kernels to build correctly with gcc-8 and not sure if it's worth it :) Oct 03 05:36:06 for 3.16 I needed cca 15 patches, for 3.4 it seems to be significantly more Oct 03 05:54:39 Personally, I have neither of those targets but I note with some nervousness that both mako and onyx still also have 3.4 kernels. Oct 03 06:52:29 Morning Oct 03 06:53:04 JaMa: oh, that much is needed ? Oct 03 07:03:10 JaMa: what kind of error do you get ? Oct 03 07:20:03 Morning! Oct 03 07:27:32 JaMa: I would be reluctant to drop the 3.4 targets at this point Oct 03 07:27:39 It might be unavoidable at some point in the future Oct 03 07:35:20 Herrie|Laptop: I agree; N5 is, for me, a reference target. As long as we don't have the equivalent for aarch64 (tissot, rosy, onyx...) I'd want to keep N5. Oct 03 07:36:35 Tofe: Seeing TP is our only tablet, I'm keep on keeping that as well Oct 03 07:36:49 Herrie|Laptop: I was writing that as well :) Oct 03 07:36:57 We might want to look to see if there's some mainline availabl Oct 03 07:37:01 +e Oct 03 07:37:11 I recall some work has been done for some targets to mainline the kernel Oct 03 07:37:24 That should "solve" a lot of issues but might introduce a lot of others as well Oct 03 07:38:50 it depends what is included in that mainline kernel, yes Oct 03 07:51:57 JaMa: but I'm willing to help fixing these issues, if needed Oct 03 10:29:02 Tofe: see http://jenkins.nas-admin.org/view/luneos-unstable/job/luneos-unstable_hammerhead/35/console Oct 03 10:33:10 Tofe: the simple fix is described here: http://lists.openembedded.org/pipermail/openembedded-devel/2018-May/118179.html Oct 03 10:33:25 Tofe: the tricky part is the other backport: http://lists.openembedded.org/pipermail/openembedded-devel/2018-May/118223.html Oct 03 10:34:27 the code is very different in 3.4 and I'm not asm expert to adapt it properly for the code in 3.4, so for 3.16 I was backporting enough changes to make this applicable with just minor tweaks Oct 03 10:35:38 and this all has kind of low priority until I unblock at least the rocko upgrade, once we're on sumo it will be more important to decide what to do with these targets Oct 03 10:45:35 ok thanks, I'll have a look Oct 03 10:45:56 Tofe: do you remember any other reason for separate ./meta-android/recipes-android/android-kernel-bootimg/android-kernel-bootimg.bb than the dependency loop with the things included in initramfs? Oct 03 10:46:34 I might need to turn this back into bbclass in order to be able to use some of the kernel artifact variables from oe-core Oct 03 10:47:28 now the artifacts are named like this: Oct 03 10:47:30 Image.gz-dtb Image.gz-dtb--1.0-r0-tissot.fastboot Image.gz-dtb--1.0-r0-tissot-jama.fastboot Image.gz-dtb--3.18.31+gitr0+b1dc38c663-r0.2-tissot.bin Oct 03 10:47:46 because the .bin from the kernel, sees PV as the real version of the kernel Oct 03 10:48:03 but android-kernel-bootimg has it's own verion 1.0-r0 Oct 03 10:48:44 I can let it use the version-less filename and create Image.gz-dtb.fastboot which is then used by luneos-package.inc Oct 03 10:49:40 but it might be nicer to create .fastboot just before do_deploy in kernel and then lvm shouldn't cause dependency loop (as it should depend only on do_package or do_populate_sysroot) Oct 03 10:54:29 creating the package with boot.img might be tricky (if I want to depend on initramfs only after do_package), but I can keep that in android-kernel-bootimg.bb which will just take the boot.img from deploy dir and package it for rootfs Oct 03 10:54:54 JaMa: the main reason was the dependency loop; it seemed also much cleaner to separate them Oct 03 10:57:56 JaMa: can't we do so that we match PV of android-kernel-bootimg and kernel's ? Oct 03 10:59:03 regarding .err, did you see https://lore.kernel.org/lkml/20180630111210.ec9de2c2923a0c58b1357965@linux-foundation.org/ ? Oct 03 11:23:59 Tofe: haven't seen this one, because I was looking into it few months prior to this e-mail Oct 03 16:56:32 can I delete some testing images? milla is full again Oct 03 17:15:29 sure Oct 03 17:28:39 all except the latest? Oct 03 17:41:44 JaMa: yes, considering the regressions we had before, that would be the way to go Oct 03 17:43:09 ok (still waiting for "du" to see where all the space actually went) Oct 03 17:50:56 84K feeds Oct 03 17:50:56 13G buildlogs Oct 03 17:50:56 40G sources Oct 03 17:50:56 92G oe-sources Oct 03 17:50:58 715G builds Oct 03 18:05:57 JaMa: All except latest testing should be fine I'd say Oct 03 18:13:30 good :) **** ENDING LOGGING AT Thu Oct 04 03:00:02 2018