**** BEGIN LOGGING AT Fri Jan 14 02:59:56 2022 **** BEGIN LOGGING AT Fri Jan 14 04:40:03 2022 Jan 14 08:10:38 Morning! Jan 14 08:10:39 JaMa: Done Jan 14 08:12:32 Morning ! Jan 14 08:13:04 JaMa, Herrie: ok, let's go for the PPP merge then Jan 14 08:14:07 Herrie: except if you still have something to commit there ? Jan 14 08:58:27 Tofe: No I think we're good Jan 14 08:58:40 Need to bump the eg25 manager later still Jan 14 09:12:01 Merged Jan 14 10:58:16 I've fixed branch name and revision of meta-arm in webos-ports-setup Jan 14 11:11:43 JaMa: OK, weird thing is that I don't see honister branch in web interface for meta-arm Jan 14 11:12:04 Weird, now it shows Jan 14 11:12:07 I checked it before wasn't there Jan 14 11:12:40 Ah its the typo Jan 14 11:12:44 I need more coffee Jan 14 11:12:45 there isn't one in meta-rockchip, but there was typo in meta-arm Jan 14 11:12:55 Seems that for meta-rockchip there isn't honister yet somehow Jan 14 11:15:42 there is also: ERROR: Unable to parse /OE/build/luneos-kirkstone/webos-ports/meta-arm/conf/layer.conf: [Errno 2] file /OE/build/luneos-kirkstone/webos-ports/meta-arm/conf/layer.conf not found Jan 14 11:16:16 which layer from meta-arm repository you really need? meta-arm or meta-arm-bsp? Jan 14 11:16:52 meta-arm layer would pull meta-arm-toolchain as well Jan 14 11:17:33 meta-rockchip depends on meta-arm :/ Jan 14 11:24:07 JaMa: I'm not sure.. I needed meta-arm-bsp for trusted-firmware-a, but couldn't get that one to build, so using the one in meta-pine64-luneos instead Jan 14 11:25:35 I need meta-arm-toolchain for sure for one of the toolchains if I remember correctly Jan 14 11:30:05 I had this before, is that more correcT? https://github.com/webOS-ports/webos-ports-setup/commit/41a857c6b953089f9c59974ee8dfb9fa0bbb1f6d Jan 14 11:36:32 JaMa: Did I do it correctly by having the DEFAULTTUNE for PPP to be aarch64 instead of the one coming from meta-rockchip? https://github.com/webOS-ports/meta-pine64-luneos/blob/honister/conf/machine/pinephonepro.conf#L9 Jan 14 11:36:41 yes, that's correct, I've fixed it the same in https://github.com/webOS-ports/webos-ports-setup/commit/78a762c325fa4924a895fe23de06d46f4e36e014 Jan 14 11:36:43 Otherwise it would rebuild all heavy bits like QtWebEngine/Qtbase etc Jan 14 11:37:50 Because it would otherwise build with DEFAULTTUNE from rk3399.inc which is set to "cortexa72-cortexa53-crypto" as per https://git.yoctoproject.org/meta-rockchip/tree/conf/machine/include/rk3399.inc#L6 Jan 14 11:37:51 will compare signatures between pp and ppp Jan 14 11:38:48 I doubt there will be much advantage in having a very specific tune? Jan 14 11:39:10 Unless it fixes my issues with panfrost somehow, but I doubt taht Jan 14 11:42:19 I doubt it would fix panfrost (but I haven't seen what issue you're refering to), the benefit of specific tune might be a bit bigger than on other MACHINEs we build, but on slow(ish) builder we have it's still probably better to share (if the signatures are indeed the same) Jan 14 11:43:13 it would be interesting to benchmark the difference when you have some spare cycles, the comparision I did 10 years ago might not be valid anymore Jan 14 11:47:06 is there any reason for meta-pine64-luneos to have significantly different honister and master branch? Jan 14 11:47:16 JaMa: no good one Jan 14 11:48:48 JaMa: I seem to get apps that use DRM to crash panfrost on mesa 21.3.3. Things like kmscube, glmark2-es-drm and waydroid: Some logs: https://paste.ubuntu.com/p/ngMQsDwrMb/ and https://paste.ubuntu.com/p/fZCDP3hsPX/ Jan 14 11:48:52 so the README update should be merged to honister and ppp changes to master right, unfortunately it will be in different order (or I'll have to force-push master) Jan 14 11:49:18 well let me force-push honister instead as that's "newer" Jan 14 11:49:25 I can run waydroid with software renderer, but hardware renderer fails and gives me black screen Jan 14 11:49:38 With lots of panfrost issues in journalctl Jan 14 11:50:08 To github.com:webOS-ports/meta-pine64-luneos.git + 767d808...4040479 honister -> honister (forced update) Jan 14 11:51:52 WARNING: /OE/build/luneos-honister/webos-ports/openembedded-core/meta/recipes-bsp/u-boot/u-boot_2021.07.bb: Unable to get checksum for u-boot SRC_URI entry 0010-sunxi-DT-H6-update-device-tree-files.patch: file could not be found Jan 14 11:53:25 and similar, did you forgot to push bunch of .patch files to meta-pine64-luneos/recipes-bsp/u-boot/files ? Jan 14 11:54:38 JaMa: I didn't know we updated the README in master too Jan 14 11:55:05 pp and ppp won't share much as GALLIUMDRIVERS in mesa are different Jan 14 11:55:25 can't we include both drivers in both case ? Jan 14 11:56:05 yes, enabling lima for ppp or panfrost for pp will help with mesa (not sure what else will be different after that) Jan 14 11:56:20 openembedded-core/scripts/sstate-diff-machines.sh --tmpdir=tmp-glibc --machines="pinephone pinephonepro qemuarm" --targets=qtwebengine --analyze Jan 14 11:56:35 JaMa: Let me check what's up with that uBoot Jan 14 11:57:28 Tofe: https://github.com/webOS-ports/meta-pine64-luneos/pull/24 was only targeting master Jan 14 11:57:55 Hmmz seems I don't have those patches locally either, weird.... Jan 14 11:58:00 Oh, damn, I didn't see... sorry Jan 14 11:59:06 Where did I pull those from previously, let me find it Jan 14 11:59:55 I guess I got inspiration from https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-pinephone/-/blob/master/PKGBUILD Jan 14 12:00:07 I'll rebuild that locally, test and push missing bits Jan 14 12:01:06 Herrie: https://bpa.st/XRRA glmark2 Jan 14 12:09:00 Tofe: Ah not too bad. And kmscube? Does that run for you? Jan 14 12:16:30 you mean kmstest? Jan 14 12:16:40 Tofe: No you need to build kmscube ;) Jan 14 12:16:51 And deloy the IPK Jan 14 12:16:54 It's another test Jan 14 12:19:53 Herrie: yes, it works, 60fps Jan 14 12:21:46 the DRM driver limits the framerate it seems Jan 14 12:24:49 Tofe: OK nice and the glmark2-es-drm test? Jan 14 12:24:53 Does that one work? Jan 14 12:25:14 yes; of course, luna-next has to be stopped first Jan 14 12:57:22 Not really sure why I get rebuilds with QtBase and QtWebEngine for example when switching between PP and PPP. That shouldn't happen anymore with the same DEFAULTTUNE I would say but well Jan 14 12:57:31 Could be I changed something else that caused the rebuild Jan 14 12:58:32 Herrie: can be the mesa difference too Jan 14 12:59:21 Herrie: can you retry after unifying the PP and PPP GALLIUMDRIVERS value ? (i.e. include all needed drivers for both) Jan 14 13:00:44 yes, it's because of mesa Jan 14 13:01:18 see the PR, but it doesn't fix that yet, the handler doesn't deal well with duplicated options, I'm trying v2 Jan 14 13:04:36 ah, ok Jan 14 14:22:52 qt* isn't reused for pp* because of different qtbase config as well (after fixing mesa difference) Jan 14 14:22:57 luneos-honister/webos-ports $ bitbake-diffsigs tmp-glibc/sstate-diff/1642169838/p*/*/qtbase/*do_prep* Jan 14 14:23:00 NOTE: Starting bitbake server... Jan 14 14:23:02 runtaskdeps changed: Jan 14 14:23:05 ['dbus/dbus_1.12.20.bb:do_populate_sysroot drm/libdrm_2.4.109.bb:do_populate_sysroot fontconfig/fontconfig_2.13.1.bb:do_populate_sysroot freetype/freetype_2.11.0.bb:do_populate_sysroot gcc/gcc-cross_11.2.bb:do_populate_sysroot gcc/gcc-runtime_11.2.bb:do_populate_sysroot glib-2.0/glib-2.0_2.68. Jan 14 14:23:10 4.bb:do_populate_sysroot glibc/glibc_2.34.bb:do_populate_sysroot icu/icu_69.1.bb:do_populate_sysroot jpeg/libjpeg-turbo_2.1.1.bb:do_populate_sysroot libpcre/libpcre2_10.37.bb:do_populate_sysroot libpng/libpng_1.6.37.bb:do_populate_sysroot mesa/mesa_21.2.4.bb:do_populate_sysroot openssl/openssl Jan 14 14:23:15 _1.1.1l.bb:do_populate_sysroot pkgconfig/pkgconfig_git.bb:do_populate_sysroot:virtual:native pseudo/pseudo_git.bb:do_populate_sysroot:virtual:native qt5/qtbase-native_git.bb:do_populate_sysroot qt5/qtbase_git.bb:do_fetch sqlite/sqlite3_3.36.0.bb:do_populate_sysroot systemd/systemd_249.7.bb:do_ Jan 14 14:23:20 populate_sysroot', +tslib/tslib_1.22.bb:do_populate_sysroot wayland/libinput_1.18.1.bb:do_populate_sysroot, 'wayland/mtdev_1.1.6.bb:do_populate_sysroot xorg-lib/libxkbcommon_1.3.0.bb:do_populate_sysroot zlib/zlib_1.2.11.bb:do_populate_sysroot'] Jan 14 14:23:24 Number of task dependencies changed Jan 14 14:23:27 Dependency on task tslib/tslib_1.22.bb:do_populate_sysroot was added with hash ff8a7a820318b8bb62cb4d76d022efba0d70cfa72b829dfabc999498bd1ae420 Jan 14 14:23:30 Dependency on task wayland/libinput_1.18.1.bb:do_populate_sysroot was added with hash e1aa4deae0e52c7e20f46972889da8bd19037e52929e939f8fe3b1e80a2f8d2f Jan 14 14:24:06 because of meta-rockchip/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend Jan 14 14:24:09 PACKAGECONFIG:append:rk3399 = " libinput examples tslib xkbcommon" Jan 14 14:24:12 PACKAGECONFIG:remove:rk3399 = "tests" Jan 14 14:27:49 so it's because rk3399 machine conf has a different default PACKAGECONFIG Jan 14 14:28:10 yes, I've updated the PR Jan 14 14:28:33 I wonder why they are messing with qtbase in that layer Jan 14 14:29:49 because without this, the qtbase won't provide much, but it's sad that it's part of BSP (instead of just documention what DISTRO is supposed to do to get usable qtbase experience) Jan 14 14:30:20 like we do in meta-webos-ports/meta-luneui/recipes-qt/qt5/qtbase_git.bbappend Jan 14 14:31:19 e.g. meta-raspberrypi/dynamic-layers/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend does the same for rpi MACHINEs but at least we're not trying to reuse rpi sstate with anything else Jan 14 14:32:25 ah, yes I understand Jan 14 14:32:31 remaining issues are in luna-next and trusted-firmware-a Jan 14 14:33:44 webos-ports $ bitbake-diffsigs tmp-glibc/sstate-diff/1642170508/p*/*/trusted-firmware-a/*do_fetch* Jan 14 14:33:47 NOTE: Starting bitbake server... Jan 14 14:33:50 basehash changed from f025a9e278744e10e02d41a912092d06d112f9aed7b1b3860aa6beab6fa36fd7 to caa1a45aa9703bbd1531c7df26ff77c29a1567a93690d025e64e826c3e58197e Jan 14 14:33:53 Variable SRC_URI value changed: Jan 14 14:33:55 "git://git.trustedfirmware.org/TF-A/trusted-firmware-a.git;protocol=https;branch=${BRANCH} file://0001-dram-Fix-build-with-gcc-11.patch file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch {+ fil Jan 14 14:34:00 e://0001-rk3399-baudrate.patch +}" Jan 14 14:34:03 Dependency on checksum of file 0001-rk3399-baudrate.patch was added Jan 14 14:34:37 webos-ports $ bitbake-diffsigs tmp-glibc/sstate-diff/1642170508/p*/*/luna-next/*do_configure.sig* Jan 14 14:34:40 NOTE: Starting bitbake server... Jan 14 14:34:43 Hash for dependent task luna-next/luna-next.bb:do_generate_toolchain_file changed from 994c4c0108fe83b2d942a160a054db2f60792a71f2667d8f39fcd35d7e9ccfc5 to f4305b65d0bb8983f4fc1c18bd8dfa0d7ccb327d50a3e58ad36b983de2847b36 Jan 14 14:34:47 Unable to find matching sigdata for /OE/build/luneos-honister/webos-ports/meta-webos-ports/meta-luneui/recipes-luneui/luna-next/luna-next.bb:do_generate_toolchain_file with hashes 994c4c0108fe83b2d942a160a054db2f60792a71f2667d8f39fcd35d7e9ccfc5 or f4305b65d0bb8983f4fc1c18bd8dfa0d7ccb327d50a3e5 Jan 14 14:34:52 8ad36b983de2847b36 Jan 14 14:34:54 OE qemux86-64@luneos /OE/build/luneos-honister/webos-ports $ bitbake-diffsigs tmp-glibc/sstate-diff/1642170508/p*/*/luna-next/*do_gen* Jan 14 14:34:57 NOTE: Starting bitbake server... Jan 14 14:35:00 basehash changed from 354b6b84a02628cf5688cbf0147197f11f657775daa463081410ec376a5d7217 to c497738d558d48a40b2058142c6a466b9949608af102bc80cfdc51f7d17f7270 Jan 14 14:35:03 Variable CXXFLAGS value changed: Jan 14 14:35:05 "${TARGET_CXXFLAGS} -fvisibility-inlines-hidden -DMESA_EGL_NO_X11_HEADERS=1 -DQT_WAYLAND_COMPOSITOR_QUICK ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} [--DEGL_NO_X11=1 -]" Jan 14 14:37:48 I've updated the PR to use better formarring Jan 14 14:37:56 https://github.com/webOS-ports/meta-pine64-luneos/pull/26 Jan 14 14:38:19 cannot do any runtime testing as I don't have pp nor ppp Jan 14 14:43:00 anyone seen enyo recipes like org.webosports.app.{messaging,contacts} failing with "msg":"dependency enyo/ready could not be found" ? it's failing like this now in kirkstone (I'm testing if the same happens in honister now) Jan 14 14:55:20 JaMa: I've not seen that one yet, no Jan 14 15:03:36 anyone remembers the reasons for our connman-conf bbappend? after https://git.openembedded.org/openembedded-core/commit/?id=3c25b89720417a7b1963f0a32c870208a5803950 it Jan 14 15:03:42 isn't very useful Jan 14 15:15:52 looks like it was redudant with qemu parameters ? Jan 14 15:16:21 ah sorry I didn't fully understand what you meant Jan 14 15:18:00 https://github.com/webOS-ports/meta-webos-ports/commit/b7c832a31bf016aa9f6e8626068e77bc508a78cd Jan 14 15:18:11 maybe we just wanted to fix the connectivity priority ? Jan 14 15:18:30 also looks like node-gyp-native is broken again, maybe related to the changes which broke enyo as well Jan 14 15:19:01 JaMa: completely agree with your commit, let's cleanup a bit Jan 14 15:41:12 JaMa: TFA baudrate patch was merged upstream I think. We could probably bump SRCREV and drop patch? Jan 14 15:41:36 rpi builds are also broken now with ERROR: Nothing PROVIDES 'trusted-firmware-a' (but /OE/build/luneos-honister/webos-ports/openembedded-core/meta/recipes-bsp/u-boot/u-boot_2021.07.bb DEPENDS on or otherwise requires it) Jan 14 15:42:11 as meta-pine64-luneos is missing override for DEPENDS Jan 14 15:42:13 recipes-bsp/u-boot/u-boot_%.bbappend:DEPENDS:append = " trusted-firmware-a u-boot-tools-native python3-setuptools-native" Jan 14 15:43:26 JaMa: That could be, I didn't test RPI Jan 14 15:43:58 Only PP, PPP, qemu and some Halium based targets Jan 14 15:48:12 merged both PRs to resolve these Jan 14 18:36:02 the node-gyp-native and org.webosports.app.{messaging,contacts} build issues are kirkstone specific (bitbake now restricts which tasks can access network and these incorrectly access it from do_install and do_compile) workaround added to meta-webos-ports Jan 14 18:36:41 will trigger ppp build on kirkstone to see how badly it's broken there Jan 14 19:38:19 JaMa: I would expect it to be fairly OK Jan 14 19:38:40 Curious to see if the mesa changes might have fixed my DRM issues but doubt it Jan 14 19:38:47 Will try that when back home Jan 14 20:06:17 /OE/build/luneos-kirkstone/webos-ports/meta-pine64-luneos/recipes-connectivity/eg25-manager/eg25-manager.bb:do_configure Jan 14 20:06:20 /OE/build/luneos-kirkstone/webos-ports/openembedded-core/meta/recipes-bsp/u-boot/u-boot_2021.10.bb:do_compile Jan 14 20:06:38 these fail with ppp, eg25-manager fails with pp as well Jan 14 20:07:05 | Run-time dependency mm-glib found: NO (tried pkgconfig and cmake) Jan 14 20:07:05 | Run-time dependency glib-2.0 found: NO Jan 14 20:07:05 | Jan 14 20:07:05 | ../git/meson.build:58:0: ERROR: Pkg-config binary for machine MachineChoice.HOST not found. Giving up. Jan 14 20:07:15 will fix that (most likely just missing inherit) Jan 14 20:10:48 | make: Leaving directory '/OE/build/luneos-kirkstone/webos-ports/tmp-glibc/work/pinephone-webos-linux/u-boot/1_2021.10-r0/git' Jan 14 20:10:51 | uboot-mkimage: Can't stat /OE/build/luneos-kirkstone/webos-ports/tmp-glibc/work/pinephone-webos-linux/u-boot/1_2021.10-r0/boot.cmd: No such file or directory Jan 14 22:20:34 the u-boot issue for pp is also kirkstone specific and caused by https://git.openembedded.org/openembedded-core/commit/?id=0ea02ca5c1fc4e15f640b1c26c0a5ce34fc08c05 Jan 14 22:21:12 in combination with: Jan 14 22:21:14 conf/machine/pinephone.conf:UBOOT_ENV ?= "boot" Jan 14 22:21:15 conf/machine/pinephone.conf:UBOOT_ENV_SUFFIX ?= "scr" Jan 14 22:22:08 Tofe: do you remember why you set UBOOT_ENV* in 8096f90a6626f62db3c60481a6a7efeb1fd46c1a ? Jan 14 22:36:29 JaMa: mmh let me see Jan 14 22:38:15 Doesn't the u-Boot tools make a boot.scr from boot.txt? Jan 14 22:39:08 I may have just took the same default as in meta-pine64 from alistair, or something like that Jan 14 22:39:17 taken* Jan 14 22:40:02 I can't find it on his repo, though Jan 14 22:43:28 It clearly looks like an inconsistency. We can probably remove it. **** ENDING LOGGING AT Sat Jan 15 02:59:56 2022