**** BEGIN LOGGING AT Sun Mar 24 02:59:57 2019 Mar 24 12:53:08 replacing udev with mdev fixes the 60s timeout we get on thus... but mdev doesn't work well with Halium, as it doesn't populate the "by-partlabel" folder that is used by Halium to find the partitions. Mar 24 13:03:15 ok, looks like microsoft changed their mind and skype works again in chromium (it doesn't for qtwebengine though) Mar 24 16:38:43 Tofe: good find about mdev and mtdev Mar 24 16:39:22 I'm trying to find out why qemu-arm segfaults when building gobject-introspection for hammerhead and strangly it's not something in qemu itself, but inside the hammerhead rootfs used in qemu Mar 24 16:40:42 http://dpaste.com/2SKSZHG Mar 24 16:41:05 if I change -L to some other rootfs (e.g. qemuarm gobject-introspection) it works Mar 24 16:43:07 JaMa: this is very indeed Mar 24 16:50:29 Tofe: for hammerhead-mainline, what about switching to hard fp? do we need any prebuilt binaries at all? Mar 24 16:52:15 JaMa: I think only the firmwares are prebuilt Mar 24 16:52:34 so switching to hardfp wouldn't be a problem no Mar 24 16:53:39 ok, then we can share TUNE_PKGARCH with rpi3, which brings own set of issues :) Mar 24 16:55:50 doesn't rpi3 use some blobs for egl ? Mar 24 16:57:39 yes, it does, that's why using the same TUNE_PKGARCH has own set of issues Mar 24 16:58:27 they use _rpi override, so armv7ahf-neon-webos used there won't be the same as armv7ahf-neon-webos for hammerhead :/ Mar 24 16:58:39 and sstate-cleanup will remove the older one every time it's executed.. Mar 24 16:58:49 and ignore me, we're already using hard fp Mar 24 16:59:08 cortexa7hf-neon-vfpv4-webos Mar 24 17:00:44 and I got it vice versa cortexa7hf-neon-vfpv4-webos is rpi, and armv7ahf-neon-webos are our cortexa8 MACHINEs Mar 24 17:02:15 :) ok, so all is good here Mar 24 17:08:37 yeah, but we can switch to cortexa8hf-neon-vfpv4-webos now when all supported MACHINEs are Cortex A8, not that it would buy much Mar 24 17:10:02 I wonder what happened with our use of thumb, I thought we had it enabled for very long time Mar 24 17:10:34 I thought that too Mar 24 17:10:57 hmm we don't and I haven't found it in git log, strange Mar 24 17:14:06 Tofe: what is your plan with busybox mdev? will we work around the missing dev links in hallium init or do you want to stay with udevd for now? Mar 24 17:14:33 because that might be the main thing blocking is from upgrading to thud, right? Mar 24 17:25:36 JaMa: I'm not sure yet; we could also change the way halium detects partitions, like using findfs (if that works with gpt of course) Mar 24 17:25:57 and using something light like mdev, or even devtmpfs, is tempting Mar 24 17:26:31 agreed, what is missing in devtmpfs? Mar 24 17:27:49 nothing, I think, same status as mdev afaik Mar 24 17:28:09 though mdev can provide scripts for some device nodes Mar 24 17:28:25 (like that awful automount provided by default...) Mar 24 17:28:33 gotta go Mar 24 17:29:03 we're patching systemd/udevd rules for by-partlabel, so I guess we can do the same for busybox/devtmpfs even when not in such easy way with rules update Mar 24 17:29:06 ./meta-luneos/recipes-core/systemd/systemd/0001-rules-consider-MMC-device-partitions-with-partition-.patch Mar 24 17:30:22 cannot we use the by-name partitions like they are e.g. in tissot recovery? Mar 24 17:30:53 /dev/block/bootdevice/by-name/ Mar 24 20:01:23 it could be yes, not sure what Android uses Mar 24 20:05:03 looking at the patch, it should be fairly easy to do a similar one for mdev Mar 24 20:05:54 I'm just not familiar how busybox-mdev is organized Mar 24 20:10:50 there were some fixes merged to sumo and thud today, I've restarted the builds and changed the DEFAULTTUNEs as it will take a while to rebuild **** ENDING LOGGING AT Mon Mar 25 03:00:06 2019