**** BEGIN LOGGING AT Wed May 15 02:59:57 2019 May 15 04:49:03 Morning! May 15 04:49:18 Tofe: THere is something weird happening, because the FirstUse comes back on every boot as well with me it seems May 15 04:49:32 Both on Hammerhead and Vbox May 15 05:00:25 morning May 15 05:23:37 Herrie: mmmh looks like something went very wrong yes May 15 05:25:32 you can check if /var/luna/preferences/ran-first-use is there May 15 05:26:33 also, for adb, you can check if /var/usb-debugging-enabled is there May 15 05:27:14 (knowing that /var is bind-mounted from /data/luneos-data on halium devices, so maybe it's overriden for them) May 15 05:27:44 maybe the changes we did these last few days for ls2 broke the creation of ran-first-use creation May 15 06:48:07 oh, and Morning (now that I have my coffee in front of me) May 15 06:51:35 Tofe:I'll have a look in a bit :) May 15 06:53:38 Tofe: Got some feedback on PR and made a few adjustments... Just no clue how to do: https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin/pull/80#discussion_r284015115 May 15 06:54:01 Herrie: temporarily you can always create /data/luneos-data/var/usb-debugging-enabled by hand from recovery May 15 06:54:51 Herrie: ah, I'll you with that May 15 06:55:45 Herrie: I'll need to put my pinephone homemade image on build.webos-ports.org so that some other pinephone guys can try it out; how could we proceed? (the image isn't built yet) May 15 06:57:13 "Herrie: ah, I'll you with that" <-- +help May 15 06:58:04 Tofe: Well I suggested to JaMa that we could merge the changes for pinephone to webos-ports-setup and jenkins-jobs and just build it for unstable & testing and not for release for now May 15 06:58:30 But JaMa had some reservations while he was in the middle of LGE's Yocto upgrade. Maybe he has some more thoughts on it now ;) May 15 06:58:48 Not building the release image should be fine imho May 15 06:59:11 But at least people can replicate the build and contribute when we have the required info in above 2 repos May 15 06:59:18 Tofe: Thnx May 15 07:00:02 Tofe: btw, re: backlog, we use kwin is compositor and qtwayland as client May 15 07:02:18 bshah: ok thanks, that's also what I guessed May 15 07:03:11 JaMa: ^ May 15 07:04:23 Herrie: JaMa's point, I think, is that adding a new layer and machine might also introduce regression in the other machines May 15 07:08:16 correct May 15 07:09:49 JaMa: OK, but only way to know is to try? May 15 07:10:14 I mean I can delete my tmp-glibc and sstate-cache locally, add the layer and build everything May 15 07:10:24 To see if I see anything weird May 15 07:11:20 (for instance, I have a u-boot.bbappend that he'll probably criticize at some point :) ) May 15 07:11:51 Herrie: I'm fine with not having a jenkins job for now though May 15 07:12:28 also I fixed a mistake in meta-pine64-luneos just yesterday, some remaining dependency to meta-pine64 that I forgot May 15 07:13:31 Tofe: But not pushed yet? May 15 07:13:36 I don't see it ;) May 15 07:15:35 Just pushed it now :) May 15 07:27:24 Herrie: just building probably won't show the issue, at least do sstate-diff-machines.sh May 15 07:28:30 * JaMa still not done with Yocto upgrade in LG.. now working on internal OSE upgrade May 15 07:33:45 JaMa: Well internal OSE means that OSE is getting an upgrade ;) May 15 07:33:49 Which is possitive May 15 07:33:58 Might still be a while before it gets external of course ;) May 15 07:39:50 JaMa: How many targets I'd need to build? May 15 07:39:55 To run that script? May 15 07:43:52 Herrie: if you could build tenderloin, which also uses u-boot (though it doesn't use the u-boot recipe itself iirc) May 15 08:16:09 Herrie: looks like I also have some issue with initramfs-uboot-image; luneos-dev-image doesn't wait for initramfs-uboot-image:deploy before doing the wic image May 15 08:18:05 Herrie: ideally all current MACHINEs to dump current signatures, then add the layer, run the script again and compare the dumped signatures May 15 08:18:12 there shouldn't be any changes in them May 15 08:30:58 JaMa: OK May 15 08:31:23 Let my builder do something useful :P May 15 08:32:08 :) May 15 08:37:21 well, my pinephone image is built, I'll fix the initramfs-uboot-image issue tonight May 15 09:17:27 Herrie: I don't know how to solve pinephone build properly yes, but doing "bb initramfs-uboot-image && bb luneos-dev-image" should succeed May 15 09:32:07 Tofe: Well I'm building all the other machines first May 15 09:32:14 Will take a while... Though most are done May 15 09:32:22 qemux86-64 and Rpi devices pending May 15 09:32:28 Others reused a lot of sstate :) May 15 09:37:33 It would take me a couple of days to compile all this :p May 15 09:39:56 Herrie: unfortunately pinephone won't share that much with the others; and there's llvm, qtbase and qtwebengine that take quite long May 15 09:40:19 Yup I know, but my builder flies when it works :P May 15 11:05:34 JaMa: what params should I throw in the sstate-diff-machines.sh ? May 15 11:06:41 Just the --tmpdir or more? May 15 11:16:46 JaMa: ^ I added tmpdir and all machines to the params and now have tmp-glibc/sstate-diff/1557918614 with a folder for each machine in there. Is that sufficient or... ? May 15 11:49:22 --targets=world? May 15 11:49:31 that might be the default May 15 11:50:26 default_targets="core-image-base" May 15 11:50:30 so add --targets=world May 15 11:58:54 OK do I need to add --analyze as well? May 15 11:58:56 Or not? May 15 11:59:58 no May 15 12:00:02 world only does qemuarm, qemux86 and qemux86-64 May 15 12:00:29 ? May 15 12:01:29 JaMa: https://bpaste.net/show/05e1f47bcdfa May 15 12:01:41 Or I should do targets and machines? May 15 12:01:46 Just did targets now May 15 12:02:19 hmm we should fix those issues as well, so use all currently built machines in --machines and luneos-dev-image in --targets May 15 12:13:37 JaMa: thanks to the "halium" upcoming pkgtune, we should be able to fix it, right? May 15 12:14:14 ah, no, it's something else maybe May 15 12:17:45 upcomming? it's already merged, but the MACHINEOVERRIDE was still missing May 15 12:18:12 Herrie: you can retry --targets=world with 2 top commits from meta-smartphone/jansa/warrior and 1 top commit from meta-webos-ports/jansa/warrior May 15 12:18:59 which implements 2019-05-10.log:18:33 <+JaMa> something like MACHINEOVERRIDES =. "halium:" May 15 12:19:13 and uses it to resolve those errors from parsing the world May 15 12:24:47 JaMa: yes, was talking about MACHINEOVERRIDE, but didn't remember the name May 15 12:38:24 Herrie: it you insert my proposal code for QPA around line 69 in cpp file, it should probably compile and work; then you won't need all your #ifdef May 15 12:41:11 JaMa: OK picked those commits. Should I rebuild or just re-run the script suffices? May 15 12:50:31 --targets=world still gives me those 3 targets only May 15 13:01:19 Tofe: Thanks that code builds now May 15 13:07:10 --targets is what to build, you still need to provide --machines parameter May 15 13:07:41 you don't need to rebuild anything, script just dumps the sstate signatures to tmp-glibc/sstate-diff/ May 15 13:08:00 then compare the list* files before and after adding the layer May 15 13:08:31 they should be the same, if they aren't use bitbake-diffsigs to find out why and if it's really expected modification caused by pinephone May 15 13:09:05 in general all changes in BSP layer should be applied with corresponding machine override, that way they shouldn't cause any impact to other MACHINEs May 15 13:13:33 JaMa: OK :) It now outputs all folders it seems, still get some errors though. https://bpaste.net/show/2d43448c79cb May 15 13:13:44 So now I can proceed with building after adding the new layer May 15 13:14:02 And then compare the list* files afterwards? May 15 13:14:15 Or I don't even need to build May 15 13:14:17 ? May 15 13:17:42 you don't need to build May 15 13:18:08 but without fixing those errors it won't dump the signatures May 15 13:21:29 JaMa: So if I use --targets=luneos-dev-image I should be OK to get a dump of signatures right? May 15 13:22:31 2 more commits added to jansa/warrior which might fix that May 15 13:26:16 JaMa: Testing May 15 13:30:22 * JaMa bbl May 15 13:34:05 JaMa: New output: https://bpaste.net/show/d8c03e154e8a May 15 13:34:15 Though seems we blacklist tk, gtk+ already May 15 13:47:41 Tofe: Seems Mer guys question our sensors in qpa ;) May 15 13:47:53 In terms of architecture, pretty sure there's a good reason for it :P May 15 14:27:49 Herrie: yes, they handle rotation in a different place iirc May 15 16:48:16 JaMa: I assume you mean the list and list.M file for each machine? I have some differences it seems May 15 16:48:27 Not sure if that's due to your changes or due to the layer May 15 16:48:55 For example: cortexa8t2hf-neon-halium-webos-linux-gnueabi/alsa-state/0.2.0-r5.do_build.sigdata.46e9e64e2a0cee8cb88561e8a50e5e66da83b88fe7a3dc3f4cb8eb644a6e0863 vs cortexa8t2hf-neon-halium-webos-linux-gnueabi/alsa-state/0.2.0-r5.do_build.sigdata.55310ff8a5dd16989f0212c691cd2c6237022de8b7c0486c126f5d193086156c May 15 16:50:23 This is for lunos-dev-image as targets param May 15 17:05:09 Herrie: with all the SRCREV bumps, we have now some crash in mojoservice... May 15 17:06:59 https://paste2.org/CK7zIw98 May 15 17:24:08 Tofe: I only bumped 1 nodejs-modules really May 15 17:24:25 Dinner now, need to have a look in a bit May 15 17:25:11 Herrie: do you have the changes from jansa/warrior blacklisting gtkwave? it shouldn't be there (with tk nor gtk+) May 15 17:26:02 Herrie: compare those sigdata files with bitbake-diffsigs, but if it's only do_build then it's ok May 15 17:26:39 JaMa: When is it not OK? May 15 17:26:54 There are quite a few, but not sure which ones are critical and which ones not May 15 17:27:11 JaMa: I updated the files manually, but relicated your changes in meta-webos-ports layer May 15 17:27:50 Anything else I could try to make sure that the gtk+/tk/gtkwave is gone May 15 17:29:28 Tofe: I mean this one: https://github.com/webOS-ports/meta-webos-ports/commit/d1ea8d778a4dc9a8195ff747531795284c2ea783 May 15 17:29:36 Herrie: all do_configure, do_populate_sysroot need to be investigated May 15 17:29:55 Herrie: yes, it could be the culprit, it fits May 15 17:30:04 gtkwave is gone with my meta-webos-ports changes May 15 17:30:20 I've just added another commit to get rid of virglrender dependency from target qemu May 15 17:30:44 It could be we have to update somewhere for LSRegisterPubPriv since it was removed in https://github.com/webOS-ports/nodejs-module-webos-sysbus/commit/a6cc51cea81fb6d57ca0e7a0990648fe5dd939ef May 15 17:30:55 Let me grep around May 15 17:32:41 That's my first guess at least May 15 17:34:22 JaMa: https://bpaste.net/show/f0459517181e May 15 17:34:35 I don't like that commit, indeed; we still have many services depending on old Pub/Priv schema May 15 17:35:33 Well Tofe it should only be an issue for JS service actually May 15 17:35:45 JS NodeJS services May 15 17:35:49 Other services not I'd say May 15 17:35:49 it is May 15 17:36:25 I think pub/priv is sorted by luna-service2 normally? May 15 17:36:54 nodejs services call luna-service2 via sysbus module May 15 17:37:07 Ah OK May 15 17:37:14 Well this one is easy enough to revert in general May 15 17:37:28 yes, let's revert that one May 15 17:37:42 is the srcrev bump associated to the rest of the recipe change? May 15 17:38:50 Yes May 15 17:38:57 ok May 15 17:39:04 I'll revert the whole commit then May 15 17:39:14 We might want to keep https://github.com/webOS-ports/nodejs-module-webos-sysbus/commit/9102a6d2df9ceb243d5c5b721e10532e75c53c27 though May 15 17:39:57 I guess we should revert dca66c7a358e7cf2a18e195d3c4b792cc2f0d68f and a6cc51cea81fb6d57ca0e7a0990648fe5dd939ef May 15 17:40:04 And keep 9102a6d2df9ceb243d5c5b721e10532e75c53c27 May 15 17:41:36 I guess we'll reintroduce it later when we figured out ACG May 15 17:41:45 And migrated everything we have on legacy roles May 15 17:42:08 In general the new security model is a lot better and locks things down properly May 15 17:42:20 Which is a good thing, but it's not clearly documented at this point May 15 17:44:14 JaMa: Don't we still get gtk+ because it's in https://github.com/webOS-ports/meta-webos-ports/blob/cb333613445318dbae220288d81cc7d05a0b08fe/meta-luneos/recipes-devtools/qemu/qemu_%25.bbappend#L1 ? May 15 17:44:28 That might overwrite the blacklist? May 15 17:45:06 Herrie: reverting the commit doesn't work anyway May 15 17:45:22 "sysbus/com.webos.nodejs.json.prv.in: No such file" May 15 17:46:10 ah ok I understand May 15 17:48:37 Herrie: yes we might, it doesn't overwirte the blacklist, but it would probably show it as an issue after all other issues are fixed May 15 17:48:41 Tofe: We need to revert 2 commits in repo itself and then bring back the files in the recipe like they were before SRCREV bump May 15 17:49:12 JaMa: I can test by removing it like you did with virglrenderer? May 15 17:49:26 Herrie: to catch more than one of those errors in one bitbake call I usually do bitbake -n world May 15 17:49:59 but fixin --targets=world is less important than the --targets=luneos-dev-image May 15 17:50:16 JaMa: luneos-dev-image finishes in general May 15 17:50:22 https://github.com/webOS-ports/nodejs-module-webos-sysbus/pull/3 May 15 17:50:38 Herrie: I mean fixing the different signatures it detected May 15 17:53:08 JaMa: How I use bitbake-diffsigs? Mever used that before May 15 17:57:28 bitbake-diffsigs <2 sigdata files> May 15 17:57:58 or bitbake-diffsigs <1 sigdata file> if you want to see human readable content of some sigdata file May 15 17:58:28 read sstate-diff-machines.sh, there is some description at the beginning May 15 17:59:14 OK thnx May 15 18:33:49 JaMa: I'm getting all kinds of python syntax errors. Which files are the sigdata files actually? May 15 18:40:27 e.g. cortexa8t2hf-neon-halium-webos-linux-gnueabi/alsa-state/0.2.0-r5.do_build.sigdata.46e9e64e2a0cee8cb88561e8a50e5e66da83b88fe7a3dc3f4cb8eb644a6e0863 May 15 18:42:35 I must be something wrong, because I'm getting quite big files (7500+ lines) when running the state-diff-machines.sh May 15 18:42:55 Not really sure how I then should proceed to compare those 7500+ lines and pick the ones that are critical May 15 18:43:41 diff 1557927968/hammerhead/list.M 1557928568/hammerhead/list.M | wc -l gives me 610 lines May 15 18:44:19 what if you skip do_build and do_rmwork? May 15 18:45:36 if it still shows a lot of tasks with different signatures then you need to traverse the dependency tree to find the root cause of the differences May 15 18:46:16 e.g. if there is linux-libc-headers difference, than it's clear that pretty much everything will be different as well (so you need to fix linux-libc-headers first and then rerun the script) May 15 18:46:48 A lot less.... May 15 18:47:12 Do we care about do_package_qa.sigdata and do_package_write_ipk.sigdata ? May 15 18:47:24 yes May 15 18:48:08 especially the later, pinephone shouldn't be causing all hammerhead .ipk files to be rebuilt May 15 18:48:26 For hammerhead I get: https://bpaste.net/show/19e1103109a2 May 15 18:48:49 Not many, busybox, db8, pmlogdaemon it seems May 15 18:48:55 Rest seems device specific so logical? May 15 18:49:39 device specific shouldn't be changed as you're comparing hammerhead with hammerhead May 15 18:50:29 It could be I had some of your change sin between May 15 18:50:32 Let me retry May 15 18:52:22 see https://github.com/webOS-ports/meta-pine64-luneos/blob/master/recipes-core/busybox/busybox_%25.bbappend May 15 18:52:30 doesn't use overrides May 15 18:52:37 that's why busybox.do_fetch is different May 15 18:53:35 probably causes all other changes as well May 15 18:54:33 eheh... ooops :) May 15 18:54:43 but even with an override this won't be very good, because then busybox and everything which depends on it will became effectivelly MACHINE_ARCH May 15 18:55:09 so if you really want to enable telnetd for all MACHINEs (as the bbappend currently does), then move it to meta-luneos May 15 18:55:31 Good news then: I plan to add it for all machines, to have a more generic way of debugging initrd May 15 18:55:33 or you need to isolate pinephone in separate TUNE_PKGARCH again May 15 18:56:06 but so far it was local testing, I didn't want to change the other initrds May 15 18:56:22 (though I did, it seems) May 15 18:57:29 JaMa: I guess my u-boot.bbappend is fairly incorrect too, in this regard May 15 18:58:12 Tofe: yes May 15 18:58:46 though having u-boot as MACHINE does seem illogical, so I'll make it so May 15 18:59:19 +_ARCH May 15 19:00:45 +_MACHINE, right? May 15 19:06:04 this is the reason why "just adding another layer to bblayers.conf" isn't as safe as it sounds May 15 19:07:27 :) May 15 19:10:54 Well JaMa: For a new machine the problem isn't that big so far :P May 15 19:10:59 Easy enough to fix :) May 15 19:33:48 Herrie: this is the reason why gtkwave blacklist didn't work: May 15 19:33:49 OE hammerhead@luneos ~/build/luneos-warrior/webos-ports/meta-webos-ports $ git grep luneos-recipe-blacklist-world.inc May 15 19:33:53 OE hammerhead@luneos ~/build/luneos-warrior/webos-ports/meta-webos-ports $ git grep luneos-recipe-blacklist.inc May 15 19:33:56 meta-luneos/conf/distro/include/luneos.inc:require conf/distro/include/luneos-recipe-blacklist.inc May 15 22:37:10 I've merged the jenkins-scripts change to test signatures for whole world instead of luneos-dev-image, will push the needed fixes to meta-webos-ports, meta-smartphone soon as well May 15 23:11:38 pushed **** ENDING LOGGING AT Thu May 16 03:00:30 2019