**** BEGIN LOGGING AT Mon Mar 18 03:00:21 2019 Mar 18 07:44:30 Morning! Mar 18 07:44:49 elvispre: do you have some logs ? maybe a last_kmsg from recovery ? Mar 18 07:50:40 Morning! Mar 18 07:50:51 elvispre: Like Tofe said, log would help :) Mar 18 07:54:24 Herrie|Laptop: could we find some place to hold the firmwares from https://github.com/Tofee/meta-smartphone-1/blob/tofe/sumo/mainline-hammerhead/meta-lg/recipes-kernel/firmware/firmware-lg-hammerhead.bb#L14 ? Mar 18 07:54:34 Could be we need to apply another small patch somewhere ;) Mar 18 07:55:03 It's basically an extract from a Halium build Mar 18 07:55:07 Tofe: Sure I can put it on the server with the Halium images somewhere Mar 18 07:55:25 Let me have a look when I'm at a desk ;) Now in a filled to the brim train... Mar 18 07:55:49 I don't want to expose bshah's server all over the place :) Mar 18 07:56:00 Guys decided to strike for 66 minutes this morning to "keep their pension age". Afterwards trains started to run but 1/3 or 1/4 of their usual size Mar 18 07:56:07 So it's like sardines in a can :P Mar 18 07:56:20 Just I got in early with my Brompton so comfortably sitting LOL ;) Mar 18 07:56:21 feels like home Mar 18 07:57:11 our next strike is tomorrow (bus transport in Paris), if I understood correctly Mar 18 08:01:32 First train had no chance to get it, so taking a different one to other part of Amsterdam that was standing and waiting, so could get in 10-15 mins before departure ;) Mar 18 08:53:20 Tofe: What would be a good path? http://build.webos-ports.org/mainline-firmwares ? Mar 18 09:45:20 Herrie: yes, perfect Mar 18 09:48:36 morning Mar 18 09:52:37 Tofe: I'll create warrior branches and try to downgrade gcc in it (importing the version we have in sumo), that should keep our old kernel devices building and possibly fix some of the other issues we had with thud Mar 18 09:52:49 so master will be just qt 5.12 Mar 18 09:53:41 JaMa: note that I didn't yet have time to investigate most seriously this Qt 5.12 issue in thud, it's not yet sure that gcc would be to blame Mar 18 09:54:35 s/most/more/ Mar 18 10:09:09 Tofe: made it mainline-kernel-firmwares: http://build.webos-ports.org/mainline-kernel-firmwares/ Mar 18 10:11:02 Herrie|Laptop: thanks ! Mar 18 10:11:16 I'll update the URL tonight in the recipe Mar 18 10:15:56 Tofe: yes, the gcc downgrade is just to keep other devices with old kernel buildable, if it helps issues on e.g. tissot (not Qt 5.12 yet in thud) then it's a bonus Mar 18 10:18:19 err my memory seems failing Mar 18 10:18:30 I've already downgraded gcc to 7 in thud Mar 18 10:19:01 it's 8 only in current master (which will became warrior soon), because the recipes for 7 were removed there Mar 18 10:19:15 should finish my coffee first Mar 18 10:20:39 JaMa: :) always coffee first Mar 18 10:22:21 only good news is that I got spare phone for daily, so I can use my hammerhead to test your mainline stuff :) Mar 18 10:22:42 * JaMa reading the backlog from 13th Mar 18 10:23:57 JaMa: so far, if you use my tofe/sumo/mainline branch on both meta-smartphone and meta-webos-ports, you should have something booting with graphics Mar 18 10:25:11 It exposes a rndis usb interface at 172.16.42.2 Mar 18 10:26:03 I'm trying to also get adb and mtp functions usb modules running, but without any success so far... Mar 18 10:26:24 good to know, but it will take me few days to test the pile of images for tissot and qemux86 which I've built from various points I no longer remember before I get to hammerhead :) Mar 18 10:26:36 :) hehe Mar 18 10:27:17 and now I have everything at least twice, because I'm trying to build on hybrid (ssd+hdd) sata controller for better speed :) Mar 18 10:27:55 at least the new ssd seems to behave better on this separate PCIE controller Mar 18 10:28:14 but moving 3TB of data is still damn slow :) Mar 18 10:29:16 That's... quite some data yes Mar 18 10:34:12 saidinesh5: your pastebins from 14th are no longer available, if you need my help with meta-intel-luneos let me know Mar 18 10:35:01 JaMa: oh .. will send you new pastes once i am done with work. Basically building luneos-dev-package fails because of missing bzimage or something like that Mar 18 10:35:04 * saidinesh5 checks the acklog Mar 18 10:35:13 saidinesh5: you should probably build just luneos-dev-image instead of luneos-dev-package Mar 18 10:35:42 Ahh Mar 18 10:35:49 luneos-dev-package is just extra packaging on top of luneos-dev-image for android devices Mar 18 10:36:06 ERROR: luneos-dev-package-1.0.2+gitAUTOINC+12c8eb4d79-r0 do_deploy: Required kernel image is not available as zImage fastboot image! /src/LuneOS/webos-ports-env/webos-ports/tmp-glibc/deploy/images/intel64-tablet/bzImage-intel64-tablet.fastboot doesn't exist. ERROR: luneos-dev-package-1.0.2+gitAUTOINC+12c8eb4d79-r0 do_deploy: Required kernel image is not available as zImage fastboot image! /src/LuneOS/webos-ports-env/webos-ports/ Mar 18 10:36:07 tmp-glibc/deploy/images/intel64-tablet/bzImage-intel64-tablet.fastboot doesn't exist. Mar 18 10:36:13 this was the last error Mar 18 10:36:18 JaMa: for his layers ordering, did I point in the right direction ? Mar 18 10:36:34 saidinesh5: you don't need fastboot kernel at all, do you? Mar 18 10:36:36 (though it should be the cause of his current issues) Mar 18 10:36:39 i don't Mar 18 10:36:39 +not Mar 18 10:36:49 and yes the layers ordering thing Mar 18 10:36:51 saidinesh5: so this shouldn't be an issue with -image Mar 18 10:36:55 and the bitbake-layers errors out Mar 18 10:37:08 there are 2 things, order of BBLAYERS variable and the PRIORITY Mar 18 10:37:22 aaah I forgot the former Mar 18 10:37:26 yep. and i set the priority to 10, while meta-intel has 5 i think Mar 18 10:37:45 will check the order of bblayers though Mar 18 10:37:48 for BBLAYERS follow what rpi does, that is: Mar 18 10:37:49 ${TOPDIR}/meta-rpi-luneos \ Mar 18 10:37:49 ${TOPDIR}/meta-raspberrypi \ Mar 18 10:38:28 the PRIORITY isn't very important as long as you don't plan to provide some recipe which exists in some other layer, but in different version Mar 18 10:38:33 JaMa: having two places to define priority is a bit messy, imho Mar 18 10:38:42 Tofe: yes it is indeed Mar 18 10:38:47 Tofe: and that's not all :) Mar 18 10:39:14 this part of layer.conf: Mar 18 10:39:16 BBPATH .= ":${LAYERDIR}" Mar 18 10:39:25 Ahhh Mar 18 10:39:39 also sort of defines the priority, because some layers used to append to BBPATH instead of prepend Mar 18 10:40:01 oh, damn... Mar 18 10:40:06 and BBPATH defines the order how bbclass files are being searched Mar 18 10:40:33 okay gimme 10 minutes.. will boot tha tsystem up Mar 18 10:40:50 nslu2-log: I hope you recorded that alright ! Mar 18 10:41:40 and for that disk space in deploy, make sure to define IMAGE_FSTYPES to the minimum you need for your target (e.g. in local.conf for now) Mar 18 10:41:52 most space is wasted on image types you'll never use Mar 18 10:42:18 but some of them might be still needed as itermediate e.g. to create the final .iso Mar 18 10:42:43 JaMa: speaking of which, we should probably stop making ext4 and tgz images for most of our devices images Mar 18 10:42:44 wic WKS kickstart were answered by Tofe I guess Mar 18 10:43:34 Tofe: isn't rootfs.tgz what's get packaged in luneos-dev-package? Mar 18 10:44:04 ah... right. Well, then just ext4 Mar 18 10:44:13 JaMa: layer.conf: https://bpaste.net/show/b17d2b14640a Mar 18 10:44:26 https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-core/images/luneos-package.inc Mar 18 10:44:46 machine/intel64-tablet.conf: https://bpaste.net/show/6fa06296812a Mar 18 10:45:17 saidinesh5: see L24 and L25, this is where it combines already deployed rootfs.tar.gz and kernel.fastboot into .zip Mar 18 10:45:33 you shouldn't need any of that Mar 18 10:45:42 Ahh Mar 18 10:45:54 So just a tar.gz image should do? Mar 18 10:46:13 luneos-dev-image should do Mar 18 10:46:13 basically all i need is a efi bootable iso image Mar 18 10:46:25 the format is specified by IMAGE_FSTYPES Mar 18 10:46:40 currently my IMAGE_FSTYPES is: IMAGE_FSTYPES += "tar.gz" Mar 18 10:46:52 so i think meta-intel is adding some other things Mar 18 10:47:00 you might need wic for that, e.g. vmdk format is now created by wic instead of standalone fstype Mar 18 10:47:26 Ahh Mar 18 10:47:37 but if you need just rootfs in tar.gz (no .iso) then IMAGE_FSTYPES_forcevariable_your-machine_name = "tar.gz" will build just that Mar 18 10:48:39 bootable iso is IIRC also .wic and in some variable you can select if you want efi or syslinux (like we do in qemux86 vmdk) Mar 18 10:48:46 Ahh Mar 18 10:48:52 added these lines: Mar 18 10:48:54 IMAGE_FSTYPES += "wic" Mar 18 10:48:54 WKS_FILE ?= "${@bb.utils.contains_any("EFI_PROVIDER", "systemd-boot rmc-boot", "systemd-bootdisk-microcode.wks", "grub-bootdisk-microcode.wks", d)}" Mar 18 10:48:54 WKS_FILE_DEPENDS_append = " intel-microcode" Mar 18 10:49:05 (they were in intel-corei7-64.conf Mar 18 10:49:31 you should be able to require whole intel-corei7-64.conf instead of the .inc file if you want to build on top of it Mar 18 10:50:04 Oh.. i wasn't sure about that. that means less boilerplate for me! Mar 18 10:50:11 how do i remove the hddimage ? Mar 18 10:50:23 IMAGE_FSTYPES\ Mar 18 10:50:24 that one just wastes space and when i do an fdisk -l it requires a 1TB hdd Mar 18 10:50:58 use bitbake -e to see what IMAGE_FSTYPES value you're actually using now and then select only the really wanted one in local.conf Mar 18 10:51:15 require conf/machine/intel-corei7-64.conf ? Mar 18 10:51:30 y Mar 18 10:52:30 this error: https://bpaste.net/show/e0daf4184fe4 Mar 18 10:55:19 saidinesh5: do you have IMAGE_FSTYPES modified in any of your extra layers? meta-intel meta-intel-luneos? Mar 18 10:55:30 the ' don't match very well Mar 18 10:55:36 * saidinesh5 checks Mar 18 10:57:13 changed my intel64-tablet.conf to this now: https://bpaste.net/show/087a8204718c Mar 18 10:57:24 and started a MACHINE=intel64-tablet bb luneos-dev-image for now Mar 18 10:57:33 waiting for that to finish Mar 18 10:58:06 Tofe: ext4 is added in MACHINE configs: Mar 18 10:58:07 meta-xiaomi/conf/machine/rosy.conf:IMAGE_FSTYPES += "tar.gz ext4" Mar 18 10:58:07 meta-xiaomi/conf/machine/tissot.conf:IMAGE_FSTYPES += "tar.gz ext4" Mar 18 10:58:17 but yes, we can probably drop it Mar 18 10:58:39 So what is the difference between luneos-dev-package and luneos-dev-image ? Mar 18 10:58:50 the former includes the latter right? Mar 18 10:58:51 https://github.com/webOS-ports/meta-webos-ports/blob/master/meta-luneos/recipes-core/images/luneos-package.inc Mar 18 10:59:02 11:45:19 <+JaMa> saidinesh5: see L24 and L25, this is where it combines already deployed rootfs.tar.gz and kernel.fastboot into .zip Mar 18 10:59:32 Ahh Mar 18 10:59:41 So that's useless for these intel devices then Mar 18 10:59:44 also line 47 gives you a hint Mar 18 10:59:48 yes Mar 18 11:00:30 Ahh Mar 18 11:12:52 6531 out of 7431 tasks... Mar 18 11:12:57 * saidinesh5 patiently waits Mar 18 11:47:37 JaMa: luneos-dev-image finished Mar 18 11:47:53 what is in tmp-glibc/deploy/images? Mar 18 11:48:17 https://bpaste.net/show/cdf13baba95f Mar 18 11:48:47 i still get an error when i do a bitbake -e though Mar 18 11:48:50 same error as above Mar 18 11:49:24 And my machine intel64-tablet.conf doesn't add/remove any image types: https://bpaste.net/show/087a8204718c Mar 18 12:03:52 saidinesh5: did you restrict IMAGE_FSTYPES already? Mar 18 12:04:03 i haven't touched that variable yet Mar 18 12:04:08 intel64-tablet.conf doesn't but meta-intel probably does Mar 18 12:04:42 to resolve the error with -e you can drop the IMAGE_FSTYPES lines from meta-rpi-luneos and meta-webos-ports Mar 18 12:04:59 Ahh that one adds these http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/conf/machine/intel-corei7-64.conf?h=sumo#n42: Mar 18 12:05:01 oh Mar 18 12:05:08 btw. i accidentally deleted the bzImage Mar 18 12:05:20 so which package creates the bzImage needed to build the rootfs? Mar 18 12:06:31 Tofe: looking at your hammerhead changes, can you please review https://github.com/shr-distribution/meta-smartphone/commit/376d6bb0e567517291974bd4e197e727aa54f02f ? Mar 18 12:07:04 Tofe: it might be another reason for issues with thud images Mar 18 12:12:31 JaMa: basically, it's moving the fastboot image creation from do_compile to do_deploy, right? Mar 18 12:13:24 let me see the rest -- which looks much simpler than before -- Mar 18 12:18:51 yes, now I'm cherry-picking your hammerhead changes on top of that, which is why I've noticed Mar 18 12:18:57 JaMa: removing pkg_postinst_ontarget_${KERNEL_PACKAGE_NAME}-image_append () will be a mistake if one day we update the kernel package on-device Mar 18 12:19:23 IIRC we discussed this before and you moved it from bbclass mostly to resolve the circular dependency, which I've resolved differently so it can be moved back Mar 18 12:21:46 we discussed it before yes, I wanted to be able to include udev in the initramdisk, mainly Mar 18 12:22:31 speaking of which, I'll probably want to try busybox-mdev instead for our initrd; it does work well on mainline, and should work as well on halium initrd Mar 18 12:23:43 I've noticed it in the backlog yes Mar 18 12:24:12 I've pushed your mainline changes rebased on top of warrior in jansa/warrior branches (for my build test) e.g. https://github.com/shr-distribution/meta-smartphone/commit/a48e7f919d919403867ed900d775ebca4cc3af74 Mar 18 12:26:38 nice :) mainline hammerhead is still far from iso-functional, though, but it's a good exercice nevertheless Mar 18 12:27:04 and the EOL approaches, anyway Mar 18 12:29:41 JaMa: back to your commit about android kernel bbclass, I think pkg_postinst_ontarget_${KERNEL_PACKAGE_NAME}-image_append is the main reason why we kept boot.img inside the package itself Mar 18 12:30:23 Maybe there is another way to achieve the same action though Mar 18 12:33:04 If you want I can put these comments on the commit Mar 18 12:34:40 ah wait, I think I missed a point Mar 18 12:36:42 I didn't realize how much of kernel_android.bbclass and android-kernel-bootimg.bb was redundant Mar 18 12:37:52 ==> conclusion: all is fine for me ! Mar 18 12:37:53 the kernel_android.bbclass should create complete kernel image with initramfs (and dtb now) Mar 18 12:38:19 android-kernel-bootimg.bb still has the postinst and just includes the boot.img already created by kernel recipe Mar 18 12:38:48 yes, I don't know why I thought a image recipe didn't create any package... that's silly Mar 18 12:39:06 the motivation from my end was https://bugzilla.yoctoproject.org/show_bug.cgi?id=12937 Mar 18 12:39:41 where I wanted to control all kernel artifacts by kernel recipe and allowing other recipes use their artifacts if needed Mar 18 12:40:19 I haven't finished it for 2.7, but this change in meta-smartphone made it a bit easier to work both ways Mar 18 12:41:11 yes, and I can see it's much cleaner now Mar 18 12:43:14 JaMa: in my mainline changes, something I wasn't really with was the Mesa opengl stuff; it was a bit intrusive, and I'll try to separate these into bbappend in meta-smartphone Mar 18 12:43:21 +happy Mar 18 12:43:48 yes, mesa is messy Mar 18 12:44:03 Also, if there would be a way to separate the qemu stuff too, that would be great; but I don't know where to put it... Mar 18 12:44:25 only change I've changed in those changes sofar is _class-target override when enabling gbm, but that's only needed for warrior and master, that's why you wouldn't notice Mar 18 12:44:51 separate from meta-webos-ports/meta-lune*? Mar 18 12:45:24 somehow yes, as it's machine specific Mar 18 12:45:36 I don't have any proposal though Mar 18 12:45:38 we can do meta-luneos-emulator layer, but it might be more work than gain, as long as we use the overrides correctly it shouldn't harm in meta-lune* Mar 18 12:46:02 with meta-luneos-emulator layer always included in our builds it wouldn't change anything anyway Mar 18 12:46:21 we should revisit/reimplement all this soon(ish) Mar 18 12:47:05 you're right, the gain would be mainly aesthetic, and would require quite some work Mar 18 12:47:45 rpi ui is broken and we need mesa for vc4, then qemu is broken a bit and uses mesa, now we have hammerhead with mesa and other devices with mesa-gl Mar 18 12:47:53 Anyway, as long as I manage to properly separate the mainline hammerhead stuff, we'll have a clean example to reproduce later Mar 18 12:48:53 most of our next mainlining work will also use freedreno, so will be very similar stuff Mar 18 12:48:55 luckily each of these are currently using different TUNE_PKGARCH (well except current hammerhead), so we can get away with doing it arch specific instead of machine specific Mar 18 12:49:44 yes Mar 18 14:19:48 Tofe: do you remeber what http://jenkins.nas-admin.org/view/luneos-testing/job/luneos-testing_update-manifest/configure is for? it still has grouper and maguro in default SUPPORTED_MACHINES so it's failing for quite a while Mar 18 14:45:35 Tofe: I've dropped maguro and grouper (leaves only mako) and also since I've renamed old luneos-testing directory on fileserver (to luneos-testing-pyro) it started from scratch, so it doesn't list the images from 2016, but I believe that's fine as they aren't on the server anyway Mar 18 14:48:04 JaMa: If I remember correctly the manifest is used for OTA update (which is semi broken), but it would be good to keep the job Mar 18 14:49:09 We should fix the update bits at some point again Mar 18 14:49:17 do you know if the mechanism need to find the currently installed image in the manifest before it tries to update to latest? Mar 18 14:49:40 JaMa: That's a good question. Let me see what it does Mar 18 14:50:04 in other words if the references to old images are still useful in the manifest (and I should contatenate the old one to new testing directory) Mar 18 14:50:22 but as it's only for mako, I guess we don't care much Mar 18 14:53:04 JaMa: It basically checks if there Mar 18 14:53:11 's a new version available in the manifest Mar 18 15:00:00 good, than latest should be good anough Mar 18 19:09:12 ah... seems like I now have wifi on mainline Mar 18 19:09:45 and - maybe - a beginning of bluetooth Mar 18 19:49:37 FYI the cleanup job takes between 30 and 60 minutes and is called 3 times during luneos-testing_build-all as shown in: http://jenkins.nas-admin.org/view/luneos-testing/job/luneos-testing_workspace-cleanup/buildTimeTrend Mar 18 19:50:08 I'll change it to clean just them tmpfs and add separate job for cleaning the sstate called only once at the end of all builds Mar 18 19:52:00 that's a pretty long time! Mar 18 20:00:52 BEFORE: 45G sstate-cache/, AFTER: 42G sstate-cache/ Mar 18 20:02:00 this included qtbase upgrade which invalidated quite a bit of sstate and still only 3G saved for first 3 MACHINEs (the same PKGARCH) Mar 18 20:02:56 so doing it only once at the end might make ~ 20G temporary difference for build like this and worse case scenario (all sstate invalidated will cost us about 2/3 of 42G) Mar 18 20:03:08 worth saving 1-2 hours per build Mar 18 20:03:48 totally Mar 18 20:04:14 I've added also another rsync after last sstate-cleanup so that we can save a bit on the fileserver as well Mar 18 20:09:11 Something I should do soon is finish the debug of that weird thud Qt issue Mar 18 20:09:30 I just have to switch to a thud build, i.e. 4h30 of rebuild :p Mar 18 20:10:55 and then we should switch to warrior with the same gcc-7 I've added today :) Mar 18 20:32:21 hmm I'm doing hammerhead backup in recovery (with dd) and I'm doing backup of userdata to the userdata partition, that might be the reason why it never fits in there :) Mar 18 20:33:36 I was thinking that I'm just unlucky that 7GB of data doesn't gzip to fit in remaining 5GB of space on the partition Mar 18 20:39:44 well, it was worth the shot Mar 18 20:40:18 can't you netcat it or something ? Mar 18 20:42:14 ah, no, I just understood what you did :p Mar 18 21:15:06 well in this case I'll just tar.bz2 the userdata from recovery instead of using dd Mar 18 21:16:02 the low level dd backup is great in case I mess the hidden partitions again, but for userdata is a bit too much and causes more harm as shown today :) Mar 18 21:16:38 still strange to see how much data the android apps accumulated in some 4 years I was using this Mar 18 21:17:13 I've already deleted all common userdata (like photos, offline maps etc) and it still eats 9GB of userdata with some random bits and pieces Mar 18 21:17:43 so part of this excersize will be to do another backup after factory reset to see how empty it will be Mar 19 01:30:05 both hammerhead and tissot running latest testing build from today and both seem to work fine, nice, will trigger new unstable builds in few hours to see how much broken it's there **** ENDING LOGGING AT Tue Mar 19 02:59:57 2019