**** BEGIN LOGGING AT Wed Oct 31 02:59:58 2018
Oct 31 09:02:13 <Herrie|Laptop> Mornign!
Oct 31 09:05:53 <Tofe> Morning!
Oct 31 09:09:54 <Tofe> Herrie|Laptop: I'm trying of an easy way to add an additional local manifest for overriding halium-devices on our jenkins build
Oct 31 09:10:03 <Tofe> +thinking of
Oct 31 09:14:00 <Tofe> Maybe just optionally download a gist ?
Oct 31 09:20:44 <Herrie|Laptop> Tofe: You mean for when they don't merge stuff timely?
Oct 31 09:20:51 <Herrie|Laptop> I think we can just push JBB a bit
Oct 31 09:20:57 <Herrie|Laptop> He's usually pretty quick
Oct 31 09:22:45 <Tofe> Yes; but we might also want to experiment, sometimes, so it's worth thinking about it
Oct 31 09:25:06 <Herrie|Laptop> OK I guess there are various ways of doing it
Oct 31 09:25:24 <Tofe> I'm trying out the gist one
Oct 31 09:57:21 <Herrie|Laptop> Seems there were some significant OSE upgrades :) https://github.com/webosose/
Oct 31 09:57:27 <Herrie|Laptop> Chromium68 I see now :)
Oct 31 09:57:32 <Herrie|Laptop> That's at least somewhat more modern
Oct 31 09:57:40 <Tofe> great
Oct 31 09:57:53 <Tofe> I was about to begin reworking on the OSE rebase
Oct 31 09:58:32 <Herrie|Laptop> That seems to bring it to end of July release according to https://www.chromium.org/developers/calendar
Oct 31 09:58:35 <Herrie|Laptop> Which is pretty good
Oct 31 09:59:21 <Herrie|Laptop> Going from 53 to 68 is a big leap :)
Oct 31 10:00:37 <Tofe> yes, that must have been quite some work
Oct 31 10:02:51 <Herrie|Laptop> Ah the repo is there, but it's empty still
Oct 31 10:03:00 <Herrie|Laptop> But I guess code will appear there sometime soonish then ;)
Oct 31 10:04:14 <Tofe> Yes, they are in the middle of a global push, it seems
Oct 31 10:06:07 <Tofe> Herrie|Laptop: oooh do you see whay I see ? https://github.com/webosose/qml-webos-bridge/commit/71a481132a9235e6c79b71b74dd7be1daebc6bcf#diff-3558f2d51a0d4859e7d6252b116fea31R150
Oct 31 10:07:31 <Tofe> "Qt 5.9"... Did they manage to make it happen?
Oct 31 10:09:14 <Herrie|Laptop> Hmmz interesting
Oct 31 10:09:16 <Herrie|Laptop> Would be nice
Oct 31 10:09:28 <Herrie|Laptop> It's not 5.11, but 5.9 is already a lot better v.s. 5.6 for performance
Oct 31 10:09:37 <Herrie|Laptop> Especially on Aarch64
Oct 31 10:09:55 <Herrie|Laptop> EricBlade: ^ Any thoughts?
Oct 31 10:09:59 <Herrie|Laptop> Or not able to disclose?
Oct 31 10:14:07 <Tofe> Them using 5.9 would be really convenient for the convergence, even if we jump to 5.11
Oct 31 10:14:33 <Herrie|Laptop> I guess it might be worth to try theim WAM as well
Oct 31 10:14:44 <Herrie|Laptop> s/theim/their
Oct 31 10:15:49 <Tofe> yes, well that'll mean using their Chromium variant in that case; but I think that's what's going to happen in the end
Oct 31 10:19:33 <Herrie|Laptop> Tofe: Well that means no more headaches for our patches :P
Oct 31 10:19:46 <Herrie|Laptop> Which would be nice
Oct 31 10:19:59 <Herrie|Laptop> Question is how well our stuff runs on theirs
Oct 31 10:20:10 <Herrie|Laptop> But that's trial & error
Oct 31 10:21:51 <Tofe> yes...
Oct 31 10:27:03 <Herrie|Laptop> It should be pretty OK, since most things didn't change fundamentally in terms of apps etc
Oct 31 10:27:15 <Herrie|Laptop> Just more more stuff added to appinfo.json mainly :P
Oct 31 10:35:10 <Tofe> It should be mostly ok. There are some questions about how much luna-next will support their chromium out of the box, but we can adapt easily here
Oct 31 10:39:43 <Tofe> Hopefully we'll *not* integrate that: https://github.com/webosose/webos-initscripts/commit/1b69a45bbb5ebd19a2e4f03755da0c999f58b537
Oct 31 10:46:20 <Herrie|Laptop> What's wrong with not using journald?
Oct 31 10:46:45 <Herrie|Laptop> The webos logging in general is a lot more extensive v.s. journald I think ;)
Oct 31 10:47:00 <Tofe> we're missing all the stuff from other services, which are not webos-related
Oct 31 10:48:14 <Tofe> I wouldn't dare trying a new port without journald :p
Oct 31 10:51:52 <Herrie|Laptop> OK ;)
Oct 31 10:52:14 <Herrie|Laptop> Well maybe we can PR them a proper solution ;)
Oct 31 12:18:58 * elvispre becomes aware that "device tree" and "android_device" are not the same thing.
Oct 31 12:32:48 <Tofe> elvispre: is it not ?
Oct 31 12:35:36 <elvispre> Tofe: Device tree is a description of a device's hardware for use by the kernel. https://en.wikipedia.org/wiki/Device_tree
Oct 31 12:35:54 <Tofe> elvispre: ah, yes, it can also mean this :)
Oct 31 12:36:28 <elvispre> So not *necessarily* the same thing.
Oct 31 12:39:01 <elvispre> I have been looking at these android "device trees" for some time and trying to interpret them according to some of those kernel device tree specifications.
Oct 31 12:39:25 <elvispre> Needless to say, it has been quite puzzling :-)
Oct 31 12:43:59 <Tofe> I guess so :) the only relationship between the two is that it's device-specific. But in one case it's a source tree, and the other it's a hardware tree
Oct 31 12:52:00 <Tofe> gosh, in OSE there is even a fork of pulseaudio... they really have too much manpower... there really wasn't a way to have a simple PA module like we do?
Oct 31 13:16:40 <Herrie|Laptop> Tofe: Well this is pulseaudio server which is different from regular pulseaudio we use if I'm correct
Oct 31 13:17:21 <Herrie|Laptop> But I might be wrong as well :P
Oct 31 13:21:12 <Tofe> Herrie|Laptop: might be, but it feeks like they fork easily :)
Oct 31 17:57:29 <Tofe> Herrie: halium-luneos-7.1-20181031-27-tissot.tar.bz2 is now ready !
Oct 31 17:58:04 <Tofe> I'll bump the recipe, and check that it's working
**** BEGIN LOGGING AT Wed Oct 31 18:13:30 2018
Oct 31 18:32:58 <Tofe> ok, pushed into existing PR https://github.com/shr-distribution/meta-smartphone/pull/89
Oct 31 19:18:55 <elvispre> Anyone knowledgeable about Android .mk files?
Oct 31 19:19:18 <elvispre> "include" appears to mean include this file
Oct 31 19:19:45 <elvispre> and "-include" appears to mean try to include this file but don't worry about it if it does not exist.
Oct 31 19:19:53 <elvispre> Is that right?
Oct 31 19:35:55 <Tofe> elvispre: I don't know that much; but I've seen that kind of behavior for systemd units too
Oct 31 19:38:13 <Tofe> elvispre: seems you're correct https://stackoverflow.com/questions/34394355/what-does-include-mean-in-an-android-mk-file
Oct 31 19:38:52 <elvispre> Tofe: Thank you. Your google-fu seems to be better than mine :)
Oct 31 19:40:44 <Tofe> looking for "-include" in google can be deceiving, given google's syntax :p
Oct 31 19:41:57 <elvispre> indeed! It looks as though that is actually just standard make syntax which probably means that I used to know this already.
Oct 31 19:46:30 <Tofe> for me, it only means I know about 5% of make's syntax... :)
Oct 31 19:46:41 <elvispre> :)
Oct 31 19:47:34 <elvispre> I am trying to get the system clock to pick up network time on onyx in the same way as for tissot.
Oct 31 19:48:12 <elvispre> This has led me to be looking into selinux is some detail.
Oct 31 19:48:41 <Tofe> for tissot it worked?
Oct 31 19:49:04 <elvispre> The selinux elements of the BoardConfig.mk do a fair bit of -including.
Oct 31 19:49:29 <Tofe> also, but you probably started by this, it's a pity our ntp daemon doesn't do its job
Oct 31 19:49:56 <elvispre> For tissot it just worked. And this was lucky because it is not working for onyx or mako so if I had tried those first I would have given it up immediately.
Oct 31 19:50:40 <elvispre> ntp does work if you sort out its configuration.
Oct 31 19:51:07 <Tofe> it's not just pointing some servers and having the correct TZ ?
Oct 31 19:51:35 <elvispre> But you do need an IP network and you do need to set the clock to the right century first too.
Oct 31 19:52:01 <elvispre> It actually fails if it is starting from 1970 because the leap is too big.
Oct 31 19:53:21 <Tofe> oh... that's a quite a big failure...
Oct 31 19:53:26 <elvispre> I am getting an IP network only for Wi-Fi not for phone at the moment.
Oct 31 19:54:05 <elvispre> It is not terribly convenient, certainly :)
Oct 31 19:54:35 <Tofe> it may be that ofono proposes some time-related services too
Oct 31 19:56:48 <elvispre> Fortunately, for tissot things are set up well enough that just setting persist.delta_time.enable=true does the trick. (So yes, probably.)
Oct 31 20:05:13 <elvispre> I am getting closer. logcat shows that "QC-time-services" is trying to read [time] offsets from /data/time/ats_1 (and 2 and 3...) but failing.
Oct 31 20:12:05 <elvispre> Tofe: I suspect not configuring NTP properly is probably normal, by the way. If picking up time from the phone network is the conventional way, then these time sources might end up fighting each other.
Oct 31 20:19:04 <Tofe> probably yes
Oct 31 23:29:17 <elvispre> If I copy /persist/time/ats_1 from tissot to /data/time/ats_1 on onyx, onyx boots and picks that up as its time offset from the RTC.
Oct 31 23:29:46 <elvispre> Neither system is writing this file however.
Oct 31 23:30:09 <elvispre> tissot seems to picking time up from the phone network.
Oct 31 23:31:33 <elvispre> onyx fails to do that, but at least I have found a way for it to pick up a halfway sensible system clock time.
Oct 31 23:33:23 <elvispre> I guess the tissot ats_n files (there are six of them) were written by the stock android a few weeks ago.
**** ENDING LOGGING AT Thu Nov 01 03:00:00 2018