**** BEGIN LOGGING AT Sun Oct 08 03:00:00 2017 Oct 08 08:30:30 Morning! Oct 08 08:48:48 Morning! Oct 08 08:52:21 Tofe: So on the release, you want me to publish it? "ok, well, that's not a great stable here, we'll have to make some adjustements" Oct 08 08:57:21 So I assumed you wanted to hold off a little? Oct 08 09:41:19 Herrie: it was mainly for Mako Oct 08 09:41:26 because of the chmod +x issue Oct 08 09:41:54 for the rest, there are issues yes, but if we stay on pyro for one more release it'll be fixed Oct 08 09:50:36 also, I'd like the previous buggy release to have a lifecycle as short as possible :p Oct 08 09:53:42 Tofe: Ok let me push it out then this afternoon Oct 08 09:54:57 Should we switch to Halium kernel & android headers afterwards right away? Oct 08 10:01:09 yep Oct 08 10:01:52 I've got some simplification for the android-system-image recipe too Oct 08 10:11:05 :d Oct 08 10:16:36 looks like librem will reach its goal in time Oct 08 10:17:31 that's very good; then they'll only have to have a lot of luck to succeed in the timeframe they've allowed themselves :) Oct 08 10:51:34 mystery deepens for sensors: I've flashed a pre-halium image, on which sensors worked; then I reflashed my current testing image and it just worked... Oct 08 10:51:54 let's try a reboot, it might just be the sensors were initialized Oct 08 10:54:09 Tofe: pong.. Oct 08 10:54:37 (my excuse for late pong : https://matrix.org/_matrix/media/v1/download/tchncs.de/DIseTOrhOELgBWPWOdHNBPJp ) Oct 08 10:55:11 bshah: don't worry :) Oct 08 10:55:44 bshah: I'm still investigating my orientation sensor thing, and I wondered if it worked well on other halium-based distros Oct 08 10:56:09 for me it looks like sensorfwd is started too soon, but I'm not really sure Oct 08 10:56:51 Tofe: can you give me your sensorfwd service unit/ Oct 08 10:57:58 https://paste2.org/bPw3yZax Oct 08 10:58:27 so it's not after android system, but that used to work, strangely enough Oct 08 10:59:02 I've tweak our android-system.service to have that fixed, but it didn't change the result Oct 08 10:59:39 do you have full log of sensorfwd? (with sensorfwd starting after android) Oct 08 10:59:46 and also udev if possible Oct 08 11:00:09 bshah: wait a bit, I'll first re-fix the start order Oct 08 11:02:59 bshah: sensorfwd https://paste2.org/OxnyUXHX Oct 08 11:04:51 bshah: for udev, what do you need ? I have the whole journal eventually https://paste2.org/CCGNC2dV Oct 08 11:05:57 Tofe: and in this state if you restart udev it does start just fine? Oct 08 11:06:33 (ah, got it: https://paste2.org/mhvywpDP ) Oct 08 11:07:11 bshah: no, if I just restart sensorfwd + compositor then it's fine Oct 08 11:08:09 ah, sorry, sensorfwd is what I meant in first message when I wrote udev.. so my theory... Oct 08 11:08:29 it would seem that order of things starting is somewhat "broken" Oct 08 11:08:37 it seems to be Oct 08 11:08:40 I agree Oct 08 11:08:52 udev -> android -> sensorfwd Oct 08 11:08:56 but it should be Oct 08 11:09:05 android -> udev -> sensorfwd Oct 08 11:09:16 oh, udev comes in so late ? Oct 08 11:09:27 (it's theory) Oct 08 11:09:50 mmh Oct 08 11:10:18 it doesn't help that sensorfwd even refuses to "start" on my local rootfs.. some weird error Oct 08 11:11:11 but wait, if only restart sensorfwd fixes sensorfwd, then udev is fine being started before android, it's just that android didn't *really* finish the init Oct 08 11:11:53 ah ah Oct 08 11:12:07 I remember.. I *think* Oct 08 11:13:00 for example, I have /system/bin/mm-qcamera-daemon which seems to be crashing quite a few times, then it's fine, and I think it plays a role in sensors init Oct 08 11:13:09 setprop dev.bootcomplete 1; setprop sys.boot_completed 1 Oct 08 11:13:39 can you do this "before" starting sensorfwd? and after container started? Oct 08 11:14:11 yup, we have a wait_for_android.sh, it'll fit in here Oct 08 11:15:03 argh... my sensorfwd linking is fucked up.. :@ Oct 08 11:15:10 bshah: after the container is completely started, right? Oct 08 11:15:16 Tofe: yep Oct 08 11:15:22 ok, one sec Oct 08 11:15:26 can you give me source of wait_for_android.sh ? Oct 08 11:17:53 https://paste2.org/NwE5cvLn Oct 08 11:18:24 and dev/.android_boot_done is created in late_init by our patched init.rc Oct 08 11:18:43 ok Oct 08 11:21:04 ah, also, we disable /system/bin/sensorservice, and I don't know the rational for that Oct 08 11:21:31 but re-enabling it didn't fix the issue, and it worked before with that thing disabled Oct 08 11:21:36 sensorservice is needed for some devices and for some not... Oct 08 11:21:44 for example on bullhead it is needed Oct 08 11:21:51 nope, setprop didn't fix it Oct 08 11:22:03 hm okay... meh Oct 08 11:22:26 yup Oct 08 11:24:58 here's a logcat | grep camera: https://paste2.org/YfPsP286 Oct 08 11:25:22 the camera process crashes until the sensors are successfully opened, which seems to happen quite late Oct 08 11:25:51 and I have, in the end, pidof(mm-qcamera-daemon) > pidof(sensorfwd) Oct 08 11:26:00 Tofe: http://build.webos-ports.org/releases/decaf/images/ Oct 08 11:26:02 And it's out ;) Oct 08 11:26:06 \o/ Oct 08 11:30:53 And release announcement: https://pivotce.com/2017/10/08/luneos-october-stable-release-decaf/ Oct 08 11:35:20 very good :) Oct 08 11:36:12 Herrie: note that now we use Halium, it means all the 5.1-based ROMs are fine, so in theory users can also flash stock nexus 5.1 images. We only need the firmwares. Oct 08 11:36:54 Sorry: Ah should be september realyl but well ;) https://pivotce.com/2017/10/08/luneos-september-stable-release-decaf/ Oct 08 11:37:01 Tofe: Is it so? Oct 08 11:37:09 Ah that's great :) Oct 08 11:37:19 Herrie: yup, we don't mount /system from the Android host anymore Oct 08 11:38:06 Tofe: OK Oct 08 11:38:12 Might be good to update that everywhere then Oct 08 11:38:18 Might be good to first test LOL Oct 08 11:38:39 hehe Oct 08 12:00:11 Tofe: I wonder if it would make sense to "modify" sensorfwd service cmdline to strace the sensorfwd to see where it craps out? Oct 08 12:01:48 bshah: I don't know, but it's on the android side that it fails Oct 08 12:02:14 and there's no recovery it seems; once it's marked as "unavailable", it's over Oct 08 12:02:15 well, but if we know where exactly it fails we can fix android side Oct 08 12:16:24 Herrie: I've sent the french article for LinuxFr for moderation, should be out in a couple of days max Oct 08 12:32:49 bshah: where it fails, I found it a little while earlier, let me re-find it Oct 08 12:35:47 bshah: this fails https://git.merproject.org/mer-core/sensorfw/blob/master/core/hybrisadaptor.cpp#L207 Oct 08 14:40:56 Tofe: Nice Oct 08 14:41:03 Busy here cleaning up my desk, necessary :P Oct 08 14:41:12 Well lots of papers to scan & stuff from Mrs Oct 08 14:41:14 LOL Oct 08 14:41:26 Seems we might have caused PivotCE to get hacked LOL Oct 08 14:41:35 Release got out and PivotCE went down :P Oct 08 15:20:34 Tofe: OK Doppio release is open to accept PR's :P Oct 08 15:21:38 Should I check for anything getting fixed in the current release? Oct 08 15:39:39 DougReeder: Well we didn't really fix much based on your reports Oct 08 15:39:56 Most things weren't really release blockers, but would be good if you could add them to bug tracker Oct 08 15:39:59 So we can look into them Oct 08 15:40:24 DougReeder: In case you want Netflix etc: http://forums.webosnation.com/luneos/331837-pivotce-luneos-september-stable-release-decaf.html#post3451758 Oct 08 16:20:38 Herrie: did you try it on TP btw? Oct 08 16:30:12 nizovn: Not yet, but works on N4/N5 Oct 08 16:30:15 So should work on TP too Oct 08 16:30:39 If Shaka player works (i.e. WideVine in black) then Netflix should work too Oct 08 16:30:49 And other stuff like YouTube Red, AMazon Prime etc Oct 08 16:31:01 Uses same ARMv7 binary ;) Oct 08 16:32:38 Herrie: i tried chromeos_9460.60.0_peach-pi_recovery_stable-channel_pi-mp-v2.bin with qupzilla, and it didn't work.. Oct 08 16:32:55 seems almost all binaries are hard-float.. Oct 08 16:33:22 nizovn: You need something with the same Chrome/ium version Oct 08 16:33:30 I noticed that with too new it didn't work for me Oct 08 16:33:38 Let me try on TP in a bit Oct 08 17:01:36 nizovn: I tried some of the latest ChromeOS images and those binaries didn't work. The ones from 56 release worked for me Oct 08 17:02:05 nizovn: Here's the list of devices and their CPU: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices Oct 08 17:02:48 The Exynos 5250 and RK3288 likely work best Oct 08 17:08:02 Herrie: thanks, i'll try to find it Oct 08 17:11:35 Nizovn: I linked one that should work in the post above ;) Oct 08 17:11:40 On WebOSNation Oct 08 17:12:20 ah, ok, good :) Oct 08 17:48:16 nizovn: http://tinypic.com/r/345bxhw/9 Oct 08 17:48:23 THis is on TP with release and above files ;) Oct 08 18:14:19 It's not very quick but it works :P Oct 08 19:02:04 Ah, sorry to hear PivotCE is down, looks like the guys will have to wait a little bit to get the news Oct 08 21:19:55 I was able to read the release notes on PivotCE before it went offline .. Oct 08 21:23:43 Anyhow - PivotCE appears to be back now .. :) Oct 09 02:28:47 In the Camera app on my N4, hitting the sutter button triggers the device to reboot. Is that expected? Oct 09 02:29:40 That is the buttoh with the iris - is that supposed to be the shutter btton? **** ENDING LOGGING AT Mon Oct 09 03:00:00 2017