**** BEGIN LOGGING AT Wed May 08 02:59:56 2019 May 08 06:02:34 morning! May 08 06:12:46 morning! May 08 06:14:32 JaMa: do you think my proposal for putting all halium targets in their own TUNE_PKGARCH is ok? May 08 06:15:07 my commit is long lost in the logs here May 08 06:22:11 found it: https://github.com/Tofee/meta-smartphone-1/commit/e47aa36249e3784cf60d8896502d50efd38c8e20 May 08 06:30:23 Tofe: sorry still didn't get to it :/ May 08 06:32:13 it looks reasonable, but setting TUNE_PKGARCH_64_${MACHINE} to the same value as TUNE_PKGARCH_32_${MACHINE} seems wrong May 08 07:09:24 I could have just set TUNE_PKGARCH_${MACHINE}? I'm not sure how this tuning exactly works May 08 07:18:01 Morning! May 08 07:20:36 JaMa: You OK with merging https://github.com/webOS-ports/webos-ports-setup/pull/11/files and https://github.com/webOS-ports/jenkins-jobs/pull/7 For now we can just exclude the target from release builds May 08 07:21:23 we shouldn't include the layer if it won't be in the release IMHO May 08 07:21:30 gtg May 08 07:22:24 JaMa: This way we could at least have testing/unstable builds for other people to tinker with as well. Even without having it as a formal release May 08 07:22:29 For that we'd need to have the layers May 08 07:31:54 Tofe: I've kicked off some new testing builds May 08 07:52:42 Tofe: Output from /var/log/messages on my local build with all included fixes so far: https://bpaste.net/show/116873bee57b May 08 07:53:18 This is after I changed the https://github.com/webOS-ports/activitymanager/blob/webOS-ports/webOS-OSE/files/systemd/activitymanager.service#L28 notice into debug May 08 07:53:40 Gives some more clues as to what's going wrong with the activities. I'll have a closer look in a bit May 08 17:17:57 JaMa: I opened https://github.com/shr-distribution/meta-smartphone/pull/105 for discussion May 08 17:18:58 only the last commit should be needed now May 08 17:19:33 I've merged libhybris bump (different commit I had ready for a while), the SRCREV is a bit newer with the pull request merged today May 08 17:21:14 what about TUNE_PKGARCH_64_append_${MACHINE} = "halium" ? May 08 19:14:14 JaMa: that's better yes, but I also want it for arm32 May 08 19:14:28 (because hammerhead mainline is coming, and for consistency) May 08 19:18:15 What about this now ? https://github.com/shr-distribution/meta-smartphone/blob/33e8e93ce8df1a23d6ef825ae6fdd279a7bf0c29/meta-android/conf/machine/include/meta-android-halium.inc May 08 19:19:32 looks better, but missing the dash (my example was missing one as well) May 08 19:19:41 and we need to replace PACKAGE_EXTRA_ARCHS_append = " ${DEFAULTTUNE}-halium" with something May 08 19:19:53 or maybe it isn't needed if it didn't fail for you already May 08 19:20:05 oops, yes, the dash May 08 19:21:08 for me PACKAGE_EXTRA_ARCHS_append worked; but do you mean it's actually useless because it doesn't do what I think it should do? May 08 19:22:20 Updated: https://github.com/shr-distribution/meta-smartphone/blob/4e27fe5e1fd8aeea37fff07b43c2f7c9a061cc36/meta-android/conf/machine/include/meta-android-halium.inc May 08 19:24:04 JaMa: but I agree ${DEFAULTTUNE}-halium looks fragile to me too May 08 19:41:12 the TUNE_PKGARCH usually isn't the same as DEFAUTTUNE, that's why I think it wouldn't work May 08 19:41:52 Finally got my ZNC setup as well :) May 08 19:49:28 JaMa: I'm all for writing it differently, but how ? I would like to stay a bit generic, at least for arm and aarch64 May 08 19:54:15 or maybe writing something like ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}_append="-halium" ? May 08 19:54:47 that's what I'm wondering about, even appending the TUNE_PKGARCH_64 variable won't be really correct and generic, because then you need to know which machine will using arm and which aarch64 May 08 19:55:51 JaMa: but if we setup for instance TUNE_PKGARCH_64_append_hammerhead, it's not that critical, is it May 08 19:55:51 it might be easier to append it to some suffix which is already used to construct TUNE_PKGARCH May 08 19:56:14 because then it would work for TUNE_PKGARCH at the same time as PACKAGE_EXTRA_ARCHS May 08 19:56:24 yes, that would be nice. May 08 19:56:47 Tofe: this part won't but appending this to PACKAGE_EXTRA_ARCHS_append for hammerhead would be wrong May 08 19:57:22 sure, but today I'm not, hopefully May 08 19:58:01 I'll look how we build the "aarch64" string, though I'm not very optimistic May 08 19:59:23 TUNE_ARCH_32_append = "-halium" May 08 19:59:33 TUNE_PKGARCH_64_append = "-halium" May 08 19:59:51 HALIUM_EXTRA_ARCH = "${TUNE_ARCH_32}" May 08 20:00:07 HALIUM_EXTRA_ARCH_aarch64 = ""${TUNE_ARCH_64}" May 08 20:00:20 PACKAGE_EXTRA_ARCHS_append = " ${HALIUM_EXTRA_ARCH}" May 08 20:00:24 that looks nice May 08 20:00:26 should be close, but still not correct May 08 20:00:35 because arm tunes IIRC don't use TUNE_ARCH_32 at all May 08 20:01:34 ah, why not just TUNE_PKGARCH_append = "-halium" + PACKAGE_EXTRA_ARCHS_append = " ${TUNE_PKGARCH}"? May 08 20:01:41 if the 2nd part is actually needed May 08 20:02:09 it will, becaues in arch-arm64.inc they hardcode it: PACKAGE_EXTRA_ARCHS_tune-aarch64 = "aarch64" May 08 20:02:10 the aarch64 case should pick between 32 and 64 already with: May 08 20:02:12 TUNE_PKGARCH = "${@bb.utils.contains('TUNE_FEATURES', 'aarch64', '${TUNE_PKGARCH_64}', '${TUNE_PKGARCH_32}' ,d)}" May 08 20:02:30 ok, so append it only for aarch64 May 08 20:02:38 PACKAGE_EXTRA_ARCHS_append_aarch64 May 08 20:02:56 arm32 will be fine you think? I didn't check at all May 08 20:03:17 hmm not May 08 20:03:53 arm also has a list of compatible archs (which aren't created based on TUNE_PKGARCH) May 08 20:04:54 so appending it for both won't hurt May 08 20:05:17 so to sum up: just the simple proposal, TUNE_PKGARCH_append = "-halium" + PACKAGE_EXTRA_ARCHS_append = " ${TUNE_PKGARCH}" May 08 20:06:10 It's simple, looks nice, I (kindof) understand it, so for me it's fine :) May 08 20:06:54 I'm testing it on tissot May 08 20:07:13 then on some 32bit arm May 08 20:07:49 (yepeee to bb -e ) May 08 20:07:58 if it works then fine with me as well May 08 20:08:30 sorry if I mislead you with that rpi3-64 example May 08 20:09:49 for tissot: PACKAGE_EXTRA_ARCHS="aarch64 aarch64-halium" TUNE_PKGARCH="aarch64-halium" *but* TUNE_PKGARCH_64="aarch64" so I'm not 100% sure it's fine May 08 20:11:02 do I care about TUNE_PKGARCH_64 if TUNE_PKGARCH is correct? May 08 20:12:11 oh well, let's just start a build and see where things go :) I think it's ok May 08 20:13:16 mmmh by the way, I get an error for libhybris recipe now, it can't find the glibc patch pointed by SRC_URI May 08 20:13:41 did we only remove it partially? May 08 20:16:52 yup, seems so. I'll commit that fix as well. May 08 20:17:44 JaMa: Any thoughts on this? May 08 07:22:24 JaMa: This way we could at least have testing/unstable builds for other people to tinker with as well. Even without having it as a formal release build. May 08 20:18:06 JaMa: This is for the jenkins-jobs and webos-ports-setup May 08 20:18:39 hammerhead: TUNE_PKGARCH="cortexa8t2hf-neon-halium" PACKAGE_EXTRA_ARCHS="...blabla... cortexa8t2hf-neon-halium" <-- seems fine! May 08 20:20:37 JaMa: candidate new PR: https://github.com/shr-distribution/meta-smartphone/pull/105 May 08 20:25:57 Herrie: I wonder what this kind of warning tells us: May 8 05:47:25 qemux86-64 daemon.warn dbus-daemon[209]: [system] Service file "/usr/share/dbus-1/system-services/luna-appmanager.service" should have been named "com.palm.appinstaller;com.palm.applicationManager;com.palm.eventreporter.LunaAppManager.service" and will not work with system bus activation May 08 20:27:03 There seem to be something wrong in our DBus service files May 08 20:27:24 Tofe: Yes this is some new dbus warning it seems May 08 20:27:30 We didn't have this before May 08 20:27:38 Might be newer DBUS in Warrior? May 08 20:27:48 or/and newer systemd May 08 20:28:30 Anyway it doesn't hurt to fix it May 08 20:28:55 I'm working through some of these errors/warnings one by one May 08 20:29:09 Never hurts to fix them usually May 08 20:29:16 Gives us a cleaner state to work with May 08 20:29:17 ok it seems it wants a match between the service file name and the "Name" entry inside the file May 08 20:29:31 I'll read the doc a bit May 08 20:31:09 Yeah seems so May 08 20:31:16 Which makes sense in general May 08 20:47:17 I only see "The service name must match that specified in the /etc/dbus-1/system.d or /usr/share/dbus-1/system.d conf file" May 08 20:49:33 mmh specifying multiple DBus names in here doesn't look right... May 08 21:07:27 Tofe: Well official documentation also has it: https://www.freedesktop.org/wiki/IntroductionToDBus/ May 08 21:07:33 Names=com.bigmoneybank.Deposits;com.bigmoneybank.Withdrawals May 08 21:08:07 right May 08 21:08:39 It may mean we activated the "BUS_SERVICE_DIR_FLAGS_STRICT_NAMING" build flag May 08 21:09:17 ah no I misread the code May 08 21:09:26 it's not fatal in our case May 08 21:10:22 Shouldn't be fatal, but still good to fix at some point May 08 21:10:37 I'll have a look into some of those tomorrow May 08 21:11:11 https://gitlab.freedesktop.org/dbus/dbus/issues/168 refers to it May 08 21:14:15 still, our service doesn't seem to be tied to any SystemdService, so it'll probably still fail May 08 21:15:39 That'll be for tomorrow yes :) May 08 21:16:12 Bedtime here :) May 08 21:16:41 same here! gn8 **** ENDING LOGGING AT Thu May 09 02:59:56 2019