**** BEGIN LOGGING AT Thu Jan 13 02:59:56 2022 Jan 13 08:54:25 Morning! Jan 13 09:39:57 Hi ! Jan 13 10:54:50 Tofe: For Hammerhead mainline: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2838 Jan 13 11:03:42 Herrie: doesn't look like a breakthrough :p Jan 13 11:03:51 but still, nice to see some little activity Jan 13 11:04:29 maybe we should also switch to mainline for nexus 5, even with a not-so-good status Jan 13 11:04:52 my mainline branch should still mainly work Jan 13 11:05:00 needs a rebase of course Jan 13 11:09:33 Nexus 5 is still as broken as before Jan 13 11:09:55 Note that we don't consider the Nexus 5 ready for anything more than "testing" status so it's less of a problem to ship mainline there Jan 13 11:15:40 Tofe: Well we tried with 4.13 before I think Jan 13 11:15:50 It's probably still very broken but well Jan 13 12:07:27 Herrie: I tried 5.6 last time https://github.com/Tofee/meta-smartphone-1/commit/3f49082a34dedf30e3c9a28e39fd57c85564e7ef Jan 13 12:20:13 Tofe: Ah OK, then not so much changes I guess Jan 13 12:20:43 Seems that repo might be dead though, so updates Jan 13 12:21:20 well, yes, but almost noone works on hammerhead anymore I guess Jan 13 12:21:53 and last I checked the whole audio support was yet to be written Jan 13 12:39:55 Tofe: Audio state seems similar now Jan 13 13:10:36 Tofe: I'm sending in some PR's for the PPP shortly together with some other things I had WIP at my end Jan 13 14:01:33 Herrie: your PR for PPP is ready for merge ? I just have to review a bit the content ? Jan 13 14:02:52 wow, 64 patches ! :p Jan 13 14:03:56 Tofe: I just dropped them Jan 13 14:04:07 I forgot I had those in there, now just force pushed without it Jan 13 14:04:11 ok good :) Jan 13 14:04:37 I was using those with the upstream kernel. Now switched to the pine64-org cross-distro one which has them applied already Jan 13 14:05:04 In general it shouldn't break anything anymore. I'm double checking PP build now Jan 13 14:07:10 I guess I could drop dtc from the PR as well Jan 13 14:07:14 Will test that locally Jan 13 14:08:00 Since it seems it's in Honister as well: https://github.com/openembedded/openembedded-core/tree/honister/meta/recipes-kernel/dtc Jan 13 14:09:36 ah, yes, better use the one already there, is that works Jan 13 14:09:41 if* Jan 13 14:10:01 Yeah checking that in a minute, no need to duplicate Jan 13 14:13:22 Seems to work, added commit to remove those Jan 13 14:17:25 For the .conf I could place it in either meta-pine64-luneos or meta-rockchip, either seems to work. I guess it wouldn't hurt to add it to meta-rockchip with a more generic version Jan 13 14:17:42 And a more specific/extended one like we have now in meta-pine64-luneos Jan 13 14:18:31 both solutions seem fine to me Jan 13 14:19:04 I initially had it in meta-rockchip layer, but then there were some specific bits for LuneOS in there, so that didn't make much sense Jan 13 14:19:23 I guess we cannot override or just add certain values, or can we? Jan 13 14:19:34 If the pinephonepro.conf exists in 2 layers, how would that work? Jan 13 14:19:41 Well I can just test it I guess Jan 13 14:20:53 it will pick the one in the layer that has high priority; but normally the most specialized one should include the generic one Jan 13 14:21:02 but then they wouldn't have the same name Jan 13 14:21:27 for this PR I'd say a single .conf in meta-pine64-luneos is fine Jan 13 14:21:33 we can refine that a bit later Jan 13 14:24:34 I guess I need to adjust the machine tune a bit as well Jan 13 14:24:41 Otherwise lots of rebuilds Jan 13 14:45:48 Tofe: When I bump eg25-manager it somehow put the udev rules in wrong dir, even when applying the patch to meson.build Jan 13 14:47:57 It somehow always ends up in /usr/lib/udev/rules.d instead of /lib/udev/rules.d Jan 13 14:49:00 Just set libdir while configuring meson? Jan 13 14:49:53 Well we're patching it but somehow it doesn't work... Jan 13 14:50:13 It could be it never worked before on PP either ;) Jan 13 14:50:45 Let me download Tofe's PP image and check where the file is actually ending up Jan 13 14:52:04 Installing udev rules to a different directory really shouldn't need patching lol Jan 13 14:52:19 Why don't you want it in `/usr` though? Jan 13 14:53:21 Because all our others are in /lib/udev for whatever reason ;) Jan 13 14:53:26 That might need revisiting Jan 13 14:53:41 it's probably yocto's default dir Jan 13 14:55:44 PureTryOut[m]: I agree, I wonder why I did a patch just for this... there must have been another reason, at least I hope so ! Jan 13 14:56:53 😉 Jan 13 14:57:03 Well seems Yocto does it properly according to man (https://linux.die.net/man/7/udev): "The udev rules are read from the files located in the default rules directory /lib/udev/rules.d/, the custom rules directory /etc/udev/rules.d/ and the temporary rules directory /dev/.udev/rules.d/. All rule files are sorted and processed in lexical order, regardless in which of these directories they Jan 13 14:57:04 live." Jan 13 14:57:06 You can just do a `mv ` in the build script ofc if need be Jan 13 14:57:28 udev reads just fine from `/usr/lib/udev/rules.d` ime 🤷 Jan 13 14:58:40 PureTryOut[m]: it actually needs a patch, if you look at how the meson file is done. It uses: `udevrulesdir = join_paths(prefix, 'lib/udev/rules.d')` and we still want /usr as a prefix.. Jan 13 14:59:01 Yeah ok but why not just do a `mv` after building? Jan 13 14:59:35 Idea just didn't pop up ? :) Jan 13 14:59:58 Multiple roads lead to Rome ;) Jan 13 15:00:00 Haha well here you go Jan 13 15:07:22 Herrie: I can also fix the udev issue and the .tar.gz one, which are common to PP and PPP, in a later PR Jan 13 15:10:20 Tofe: Well let me push those Jan 13 15:10:26 The eg25manager is a bit of a weird one Jan 13 15:10:50 When I build old SRCREV it's fine, when I build new SRCREV it's broken, though paths are the same and nothing obvious seems changed Jan 13 15:10:51 I agree Jan 13 15:11:12 maybe bb -c cleansstate might help ? Jan 13 15:12:26 I tried... Really weird somehow Jan 13 15:12:40 Let me remove those .tar.gz and fix the defaulttune Jan 13 15:13:45 Let me test the build with other defaulttune first Jan 13 15:15:08 sure, we have all the time we want :) Jan 13 15:15:47 Just need to see if I don't break other things Jan 13 15:21:04 See also broke something, let me just see if I can override the defaulttune in the .conf Jan 13 15:21:46 Because seems I need other things from meta-rockchip layer, I cannot simple include the regular bits like we do for the PP, but need to override the DEFAULTTUNE in the .conf Jan 13 16:03:00 Well image is rebuilding now, should be done after QtWebEngine and I'll flash and try Jan 13 16:30:36 Herrie: I wonder if my little recovery ui is working also on PPP Jan 13 16:47:52 Tofe: How to test that? Jan 13 16:50:24 Herrie: Vol Down during startup boot Jan 13 16:50:53 but I remarked it doesn't always work, like when battery is too low, or on cold boot Jan 13 16:51:01 not really sure how to debug that Jan 13 16:52:35 Tofe: Well it doesn't seem to work on PPP Jan 13 16:52:46 But didn't you need to have boot.scr script where you add something for it? Jan 13 16:52:58 I don't use the boot.txt/scr for PPP currently Jan 13 16:53:50 Ah wait, you have a uBoot patch for it: https://github.com/webOS-ports/meta-pine64-luneos/blob/master/recipes-bsp/u-boot/files/0001-pinephone-Add-volume_key-environment-variable.patch Jan 13 16:54:16 p-boot doesn't work for PPP, only PP according to Megi Jan 13 16:54:21 There's levinboot for PPP Jan 13 16:54:29 yes, it's a uboot script, plus some lines in boot.txt Jan 13 16:54:35 s/script/patch/ Jan 13 16:55:01 Yes well I don't have either of them for now Jan 13 16:55:11 :) this explains that Jan 13 16:55:20 I just pushed the cleanup commit for the DEFAULTTUNE and .tar.gz Jan 13 16:55:47 Only missing thing now is the other layers I guess Jan 13 16:55:52 Let me push that as well in a bit Jan 13 17:09:58 JaMa: https://github.com/webOS-ports/webos-ports-setup/pull/15 Jan 13 17:13:41 That should allow users to build stuff themselves Jan 13 17:17:50 Tofe: This is for the "new" power key: https://bpa.st/UG3A Jan 13 17:53:39 JaMa: https://github.com/webOS-ports/webos-ports-setup/pull/15 Jan 13 18:09:02 Herrie: sorry, wrong channel :) Jan 13 18:10:01 my ZNC didn't restore the channels in the same order as usual, so I got lost :p Jan 13 18:10:16 Tofe: CAn happen Jan 13 18:10:19 Yeah I have that one Jan 13 18:11:36 so I propose to use the "by-path" one for nyx Jan 13 18:11:41 the same should be stable Jan 13 18:11:46 the name* Jan 13 18:14:41 OK makes sense Jan 13 18:14:43 Let me try that Jan 13 18:14:50 I guess it doesn't hurt for other targets as well Jan 13 18:20:01 Tofe: Yup that works, let me update PR Jan 13 18:21:25 great Jan 13 18:21:55 I have exactly the same symlink on PP Jan 13 18:22:02 OK pushed it for PPP Jan 13 18:35:26 perfect Jan 13 18:35:51 I'll just wait for JaMa to see if he has remarks on the additional layers, then we'll merge all Jan 13 18:36:18 Tofe: OK Jan 13 18:55:09 Tofe: Should I push the same for PP ? Jan 13 18:56:46 Tofe: Done ;) Jan 13 20:47:38 Thanks! Jan 13 21:24:38 Tofe: Trying to debug my waydroid issues here a bit Jan 13 21:24:47 Not really sure what's up yet Jan 13 21:25:14 I'm running glmark2 (you can just build ipk and install), GPU performance seems pretty decent on PPP) Jan 13 21:26:36 Might be interesting to run on PP as well to see what you get for comparison Jan 13 21:27:35 It's already provided in one of the Yocto layers, so you can simply build the IPK with MACHINE=pinephone bb -f glmark2 Jan 13 21:31:40 https://bpa.st/RZVQ Jan 13 21:32:07 Gets pretty hot and drains battery while benching ;) Jan 13 22:20:14 I've built it, but I was going to bed, so I'll finish the test tomorrow morning :) Jan 13 22:21:05 Tofe: Yeah going to bed here soon too Jan 13 22:21:20 But something is off with the DRM bits in PPP, trying some new defconfig values ;) Jan 13 23:49:16 Herrie: can we pin arm and rockchip revisions? Jan 13 23:56:05 JaMa: Sure we could I guess Jan 13 23:56:22 I just did HEAD so I didn't need to pin them all the time, but it's fine to pin them in general Jan 13 23:57:02 Tofe; FWIW I got Waydroid to run with ro.hardware.gralloc=default and ro.hardware.egl=swiftshader but slow of course **** ENDING LOGGING AT Fri Jan 14 02:59:56 2022