**** BEGIN LOGGING AT Thu Dec 16 02:59:56 2021 Dec 16 04:25:13 "JaMa: do you see anything..." <- The same error seems to repeat on other pkgs if building with -k Dec 16 05:56:05 And then there's stuff like https://git.yoctoproject.org/meta-rockchip/tree/conf/machine/include/rockchip-wic.inc etc Dec 16 07:03:42 Morning Dec 16 07:03:59 eriki73[m]: Can you paste a full log? Dec 16 07:05:46 Herrie: Well, I am now trying on my laptop which runs manjaro and it seems to work better. It seems that it got beyond the point where it failed on my desktop. Now, I am just hoping that 16 GB of ram is enough. Dec 16 07:10:39 16gb should be OK i guess Dec 16 07:10:51 It's weird it was failing on the download though Dec 16 07:11:06 Could be some temporary glitch @ Github somehow Dec 16 07:12:12 Herrie: Nah, it still fails on my desktop and they're on the same LAN... Dec 16 07:13:54 Ok. it failed again on Manjaro with similar log. Dec 16 07:14:25 Really weird Dec 16 07:14:38 Let me delete my package for this and see what it does Dec 16 07:16:15 OK I can replicate Dec 16 07:16:19 Let me try to fix it Dec 16 07:16:20 Also, I have previously used OE and it hasn't failed before. This happens only when doing webos. Dec 16 07:16:53 Herrie: Well, I am not alone, at least. Dec 16 07:20:05 Btw, with -k, the error happened on quite a lot of packages Dec 16 07:21:20 Well MS is changing some things on Github recently Dec 16 07:21:36 THose should have been addressed in the repos but could be some got left out somehow Dec 16 07:24:49 These nodejs packages use an include for the github urls, maybe that's somehow an issue Dec 16 07:24:58 Which other packages you have the issue? Dec 16 07:25:09 Ps your logging is very verbose compared to mine Dec 16 07:26:26 Herrie: They are exclusively nodejs modules. Dec 16 07:26:41 s/modules/pkgs/ Dec 16 07:27:47 And there are a lot of them. Dec 16 07:59:27 This works for me on the dynaload package: https://github.com/webOS-ports/meta-webos-ports/commit/8b9d6096c8a79a73412f806184fc2d1eb2034862 Dec 16 07:59:40 Let me just nuke my downloads and do a completely clean build Dec 16 08:00:25 See if I run into issues Dec 16 08:00:57 We hardly ever do that as you can imagine since we have downloads, sstate etc, so these fetcher errors hardly appear on our end in a regular build Dec 16 08:02:03 OK nuked downloads, sstate-cache, let's build something from scratch now Dec 16 08:02:57 Got 1GBit fiber here which will do about 400 Mb/s on WiFi, so quick enough for downloading stuff again Dec 16 08:28:08 So far so good, 6750/8750 tasks completed without errors Dec 16 08:48:12 Now at 8200/8676 so far so good Dec 16 09:36:58 JaMa: https://github.com/webOS-ports/meta-webos-ports/commit/8b9d6096c8a79a73412f806184fc2d1eb2034862 seems fetcher was again unhappy at my end (log: https://paste.ofcode.org/5uDvjg57RQ9dcnLxYN23Se). With this change it works with a completley clean build (deleted downloads, sstate-cache and tmp-glibc) Dec 16 12:07:13 Morning! Dec 16 12:08:45 Tofe: Morning! Dec 16 12:09:07 I'm reworking my bits in meta-pine64-luneos a bit based on the rk3399 in meta-rockchip bits Dec 16 12:09:32 Which seems a more logical approach v.s. trying to replicate what non-Yocto people are doing Dec 16 12:11:10 Almost there, just having a bit of issue with DTB in kernel now. Seems there's a separate DTB in u-Boot and another in kernel which is giving me some headaches with kernel compile now Dec 16 12:11:32 Herrie: about the fetcher, could it be Github removed an alias on their end, making the .git suffix mandatory Dec 16 12:12:33 Herrie: yes, the two DTB aren't necessarily identical; u-boot needs less stuff to make things work Dec 16 12:13:08 but the one that should be loaded by uboot is the kernel's, of course Dec 16 12:14:04 Tofe: Yeah seems that they use a unified one somehow between uBoot and kernel in meta-rockchip, so trying to get that sorted now Dec 16 12:14:53 btw, the .wks you pointed at seemed needlessly complex, should we really use that? Dec 16 12:15:12 well we can give it a try anyway Dec 16 12:15:34 Tofe: Well this seems the "official" Rockchip one Dec 16 12:16:25 Well the community maintained "official" one, which is up to date more or less. The really official one is not that active and uses a lot of patches Dec 16 12:18:47 And uses old 4.4 kernel etc. So I prefer the bits from community maintained meta-rockchip layer over that ;) Since it uses regular linux-yocto kernel etc Dec 16 12:19:42 but we still need drivers specific to ppp, right? Dec 16 12:20:10 (let's use that to abbreviate pinephone pro :) ) Dec 16 12:22:35 Tofe: Yeah we still need ppp specific stuff... I would use Megi's kernel over the linux-yocto one, since all patches are already in there Dec 16 12:22:59 right Dec 16 12:22:59 But there shouldn't be a whole lot of difference between yocto-linux-dev+patches and Megi's. Dec 16 12:23:18 just what isn't upstreamed yet Dec 16 12:24:36 Yes and there might be some small diferences, but it shouldn't be very significant Dec 16 12:24:55 I.e. yocto-linux-dev has some Rockchip specific patches that aren't in Megi's and vv Dec 16 12:33:00 OK seems I can just specify the different DTBs as KERNEL_DEVICETREE in the u-boot and kernel recipe instead of in the machine. This way it seems to build at least Dec 16 12:34:30 Tofe: bmaptool seems a bit fuzzy at times, using BalenaEtcher on Windows seems to be more reliable somehow, so will try that for our WIC Dec 16 12:34:52 It should work with WIC according to https://software-dl.ti.com/processor-sdk-linux/esd/docs/08_00_00_21/linux/Overview/Processor_SDK_Linux_create_SD_card.html#processor-sdk-linux-create-sd-card-using-balena Dec 16 12:39:42 ah, never had any issue with bmaptool on my end Dec 16 12:51:30 Tofe: Well it's probably user error Dec 16 12:51:39 But I had issues with my pmOS and Arch images somehow Dec 16 12:51:43 Could be partitioning Dec 16 12:51:53 Seems that BalenaEtcher sorts it OK on Windows somehow Dec 16 12:52:18 ok, well, good to know Dec 16 13:25:21 Tofe: Well some logs, doesn't boot but well.. https://bpa.st/KULQ Dec 16 13:26:46 At least some progress in terms of getting logging from u-Boot Dec 16 13:27:20 This is the first output I'm getting on console using the LuneOS build at least, so it's some progress Dec 16 13:37:27 Ok, progress, five errored pkgs anymore: https://paste.ubuntu.com/p/bNrSnq6cKq/ Dec 16 13:48:28 eriki73[m]: Well I think when we solve the kernel one, others will be fine too Dec 16 13:49:34 Herrie: Yeah, hopefully. I took a look at the link to tissot kernel. Dec 16 13:49:51 If you can paste the output of do_compile for the kernel somewhere we can help Dec 16 13:52:25 Herrie: Is there a log file somewhere? Dec 16 13:55:29 Found it Dec 16 13:56:14 https://paste.ubuntu.com/p/P9j5BFDgtN/ Dec 16 14:02:16 Setting CONFIG_CC_WERROR=n and trying again Dec 16 14:24:16 Herrie: your log looks like you're booting linux directly, and it's waiting for a rootfs, meaning there's no initrd or so Dec 16 15:32:24 Tofe: Ooh quite likely Dec 16 15:32:29 I didn't tweak a whole lot yet Dec 16 15:39:21 I need to have this one right I guesS? https://github.com/webOS-ports/meta-pine64-luneos/blob/herrie/hardknott-ppp/recipes-core/images/initramfs-uboot-image.bb Dec 16 15:39:57 I removed it from my pinephonepro.conf recently, so that might explain Dec 16 16:57:00 yes, that's what builds it Dec 16 16:59:15 Tofe: Well I tried to add it, not sure what I'm doing wrong... Log is the same. This is my current WIP. DTB is a bit messy, need to sort that still, but well Dec 16 16:59:17 https://github.com/webOS-ports/meta-pine64-luneos/commit/90778b78115ea0611e9e4eef9bf2865349f65517 Dec 16 17:10:02 Herrie: you don't include boot.scr in the image yet? Dec 16 17:11:39 also I see that the layout seems to distinguish the spl pre-boot, then u-boot, then boot partition Dec 16 17:12:04 which is fine, why not Dec 16 17:19:22 Tofe: I don't see boot.scr in the meta-rockchip examples Dec 16 17:20:10 So I didn't include it Dec 16 17:58:42 It's possible they just boot the kernel as-is in their use-cases Dec 16 18:07:16 Ok, kernel compiles now but qtwebengine doesn't: https://paste.ubuntu.com/p/QYwf7JBxfg/ Dec 16 18:37:41 Installing libstdc++-static-11.2.1-7.fc36.x86_64.rpm helped. Dec 16 19:03:02 Tofe: Anything I can check at my end? Dec 16 19:06:10 Tofe: Ah I might need something like this as well I guess? https://github.com/twoerner/meta-rockchip__twoerner/blob/master/wic/rock-pi-4.wks Dec 16 19:07:14 Herrie: I must say I'm not sure about the syntax of the wks file Dec 16 19:07:30 but yes, worth a try Dec 16 19:10:43 Ah wait I have that already it seems Dec 16 19:11:49 Or something similar at least Dec 16 19:11:55 LEt me see where this "RK_BOOT_DEVICE" comes from Dec 16 19:17:52 OK seems mmcblk0 = SD, mmcblk1 = eMMC as per https://git.yoctoproject.org/meta-rockchip/commit/conf/machine/include/rockchip-defaults.inc?id=1aea373d8876b2f7faae2704f7bc70465c59dc13 and some other example Dec 16 19:17:54 +s Dec 16 19:27:54 very possible yes Dec 16 19:28:50 I'll add it Dec 16 19:29:08 I did a -c clean for image, seems timestamp wasn't updated, so that could be why previous image showed same result Dec 16 19:30:57 New image is ready, will flash so should know in some minutes if it gives any better results or logs Dec 16 19:38:24 Hmmz very similar except that it now specifies the partition at least: https://bpa.st/HE4Q Dec 16 22:16:39 Tofe: FWIW partition layout for Rockchip: http://rockchip.wikidot.com/partitions Dec 16 22:35:43 Tofe: I checked my WIC, it has the following files inside: boot.img, 5 files names primary.img and root.img. The boot.img has the following contents: fitImage, initramfs-uboot-image-pinephonepro.uboot and a folder named extlinux with inside a file called extlinux.conf with the following content: https://bpa.st/AV6A Dec 16 22:40:04 When I compare that to pmOS: https://gitlab.com/postmarketOS/pmaports/-/blob/master/device/testing/device-pine64-pinephonepro/extlinux.conf#L8 Dec 16 22:41:21 Seems we need to have initrd entry added for it to work somehow. I.e.: https://github.com/openembedded/openembedded-core/blob/master/meta/classes/uboot-extlinux-config.bbclass#L16 Dec 16 23:21:59 eriki73[m]: Herrie: Tofe: the fetching issues you're seeing are most likely caused by https://sources.webos-ports.org/ being up again, but returning 521 Error for every request, so instead of expected tarball bitbake fetcher is getting html Dec 16 23:22:17 disable the SOURCE_MIRROR in local.conf until our fileserver is up and running Dec 16 23:23:59 at least https://paste.ubuntu.com/p/X7GfWMVzZj/ shows this http://sources.webos-ports.org/git2_github.com.webOS-ports.nodejs-module-webos-dynaload.tar.gz Length: 46507 (45K) [text/plain] **** ENDING LOGGING AT Fri Dec 17 02:59:57 2021