**** BEGIN LOGGING AT Thu Jun 09 02:59:58 2016
Jun 09 03:12:29 <DougReeder> Andolamin, html5test.com says ServiceWorkers work on current LuneOS.
Jun 09 03:26:17 <DougReeder> And https://lamplightdev.github.io/r3search/ works just fine.
Jun 09 06:41:17 <Herrie> JaMa: ping
Jun 09 07:03:36 <JaMa> pong
Jun 09 07:04:33 <Herrie> JaMa: morning ;)
Jun 09 07:04:46 <Herrie> JaMa: I'm trying to get IMAccountValidator to work, but running into an issue
Jun 09 07:04:57 <Herrie> I compared 3.0.5 log and our log and spot I difference
Jun 09 07:05:16 <Herrie> Only difference I see in the log is "(13:35:55) dbus: Failed to get connection: Using X11 for dbus-daemon autolaunch was disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead"
Jun 09 07:05:31 <Herrie> I can see we have an /etc/profile in 3.0.5 doctor which seems to define DBUS_SESSION_BUS_ADDRESS but we don't have it in LuneOS
Jun 09 07:06:07 <Herrie> Contents of this on 3.0.5 is: https://bpaste.net/show/18ebd1b04a9a
Jun 09 07:06:29 <Herrie> If I set and export the DBUS_SESSION bits I get "(00:29:05) dbus: Failed to get connection: Failed to connect to socket /tmp/session_bus_socket: No such file or directory" when trying to run IMAccountValidator
Jun 09 07:06:42 <Herrie> Any ideas? I'm probably something silly wrong
Jun 09 07:06:57 <Herrie> The imaccountvalidator we have came from the open sourced 3.0.5 bits directly
Jun 09 07:08:11 <JaMa> do you read that address from /var/run/dbus/env like that profile did in the end?
Jun 09 07:09:16 <Herrie> JaMa: You mean line 51? Isn't that commented out?
Jun 09 07:10:32 <JaMa> yes it is, but if we have /var/run/dbus/env created in runtime I would trust it more
Jun 09 07:11:20 <JaMa> you can also try to install something simple like mdbus2 to see if dbus works fine for you in cmdline
Jun 09 07:11:49 <Herrie> JaMa: No it seems we only have: /var/run/dbus/system_bus_socket there
Jun 09 07:15:10 <Herrie> JaMa: "Can't hook to DBus session bus: The given address is empty"
Jun 09 07:16:50 <Herrie> If I set DBUS_SESSION_BUS_ADDRESS="unix:path=/tmp/session_bus_socket" and EXPORT DBUS_SESSION_BUS_ADDRESS I get "Can't hook to DBus session bus: Could not connect: Connection refused"
Jun 09 07:24:07 <JaMa> why anything in ~/.dbus/session-bus/ ?
Jun 09 07:25:43 <JaMa> but I know very litle about dbus, I'll need to try it myself
Jun 09 07:25:59 <JaMa> will try to boot qemux86 image later today..
Jun 09 07:26:01 <JaMa> bbl
Jun 09 11:00:55 <Herrie> morphis: ping
Jun 09 13:56:52 <Herrie|Pre3> DougReederG3: You around?
Jun 09 13:56:55 <Herrie|Pre3> Garfonso: ping
Jun 09 13:59:11 <Garfonso> Herrie|Pre3: Pong
Jun 09 13:59:40 <Herrie|Pre3> Garfonso: Just want to run something by you quickly...
Jun 09 14:00:15 <Herrie|Pre3> I want to get the com.palm.task db kinds & permissions added to the build. Just not really sure where I should put them....
Jun 09 14:00:26 <Herrie|Pre3> core-apps, app-services, own repo?
Jun 09 14:02:13 <Garfonso> I'd say core-apps. It also has calendar and calendar.db kinds
Jun 09 14:02:45 <Herrie|Pre3> Garfonso: OK :) Just we don't have an app there but well :)
Jun 09 14:02:58 <Herrie|Pre3> I can just create the folder structure I guess :)
Jun 09 14:03:19 <Garfonso> I still vote for core-apps... or do we have a tasks app?
Jun 09 14:03:39 <Herrie|Pre3> Garfonso: Nothing yet. Legacy 2.x was Mojo
Jun 09 14:03:46 <Herrie|Pre3> So something would need to be written
Jun 09 14:03:56 <Garfonso> yeah, I know.
Jun 09 14:04:12 <Herrie|Pre3> But the Remember The Milk Synergy could work at least to populate stuff :P
Jun 09 14:04:15 <Garfonso> Alternative would be a completely new repo for a future tasks app. :)
Jun 09 14:04:22 <Herrie|Pre3> UI shouldn't be too hard
Jun 09 14:05:11 <Herrie|Pre3> I guess I can create the repo. We'll eventually go that line anyway I guess
Jun 09 14:05:39 <Garfonso> then that is the best approach.
Jun 09 14:06:30 <Herrie|Pre3> DougReeder: ^ Thoughts?
Jun 09 14:06:53 <Garfonso> btw: are the nightlies with the crossappui fix finished?
Jun 09 14:07:12 <GodGinrai> do you have separate repos for the other apps?
Jun 09 14:07:43 <Herrie|Pre3> Garfonso: Yes and it looks OK to me in the logging now :D
Jun 09 14:08:11 <Herrie|Pre3> GodGinrai: Own org.webosports.app.xyz yes. The legacy Enyo 1.0 ones are all in core-apps repo
Jun 09 14:08:11 <Garfonso> ok. Great. Will test it :)
Jun 09 14:08:24 <GodGinrai> I see
Jun 09 14:08:34 <GodGinrai> that's a tough one
Jun 09 14:08:45 <GodGinrai> it makes sense to put it in core-apps since it is a core app
Jun 09 14:09:06 <GodGinrai> but at the same time, since it wasn't part of the original source release, it makes sense for new apps to have separate repos
Jun 09 14:10:05 <Herrie|Pre3> For everything that we wrote we have a separate repo. Also for build system it's easier.
Jun 09 14:11:52 <Herrie|Pre3> Because we can more easily tailor things to a certain device as well when needed.
Jun 09 14:11:56 <GodGinrai> yea, I would think
Jun 09 14:12:32 <Herrie|Pre3> Our core-apps recipe is messy because we use some parts but not others... So we install all, then remove the apps we don't use during build :P
Jun 09 14:12:41 <GodGinrai> what if you gave it its own repo and included it as a submodule in core-apps?
Jun 09 14:14:21 <Herrie|Pre3> We try to avoid submodules ;)
Jun 09 14:15:41 <GodGinrai> I see
Jun 09 14:40:45 <Herrie|Pre3> OK repo is there just need to hook it up and fill it :)
Jun 09 15:54:04 <DougReederG3> Herrie, Garfonso, GodGinrai, I'd prefer to to see the tasks kinds in a new repo.
Jun 09 15:55:30 <Herrie|Pre3> DougReederG3: OK :)
Jun 09 15:55:46 <Herrie|Pre3> I'll test some bits tonight recipe wise and push it.
Jun 09 15:56:19 <DougReederG3> I'm looking toward http://webos-ports.org/wiki/Synergy_for_Tasks
Jun 09 16:00:08 <Herrie|Pre3> DougReederG3: We'll be backwards compatible with legacy for now.
Jun 09 16:00:17 <Herrie|Pre3> I.e. use their kinds & permissions.
Jun 09 16:00:30 <Herrie|Pre3> You aware of any Enyo apps using the com.palm.task kind?
Jun 09 16:02:57 <DougReederG3> I don't know of any
Jun 09 16:03:51 <DougReederG3> Yes, we should keep the old kinds around
Jun 09 16:05:27 <DougReederG3> We might end up just adding fields to the old kind.
Jun 09 16:06:01 <Herrie|Pre3> We had a special one for eas that extended the regular kind
Jun 09 16:06:12 <Herrie|Pre3> For tasks that is.
Jun 09 16:07:09 <DougReederG3> I doubt the code that used it is available and useful to us, but I can't say definitively
Jun 09 16:08:15 <Herrie|Pre3> DougReederG3: No EAS bits were never open sourced due to licensing I guess to MS
Jun 09 16:08:38 <Herrie|Pre3> Would be good to have. There are some open source alternatives but those would need some work to hook up.
Jun 09 16:08:40 <DougReederG3> That's what I suspected.
Jun 09 16:10:32 <Herrie|Pre3> I'll just put in the kind anyway. Good to have it.
Jun 09 16:11:00 <Herrie|Pre3> Scoutcamper brought old webos-internals git back up, going to migrate stuff to github so we have it available.
Jun 09 16:11:42 <DougReederG3> The EAS kind should be useful as reference, at leasr
Jun 09 16:14:00 <Herrie|Pre3> Yeah. The git is separate anyway but it has some of the stuff that might come in handy sometimes. Most is outdated but who knows. I'll take the kinds & permissions from 3.0.5
Jun 09 16:42:14 <Herrie> DougReederG3: Any feedback on the webos-telephonyd IPK?
Jun 09 16:48:30 <DougReederG3> It makes the blockId param optional
Jun 09 16:49:00 <DougReederG3> But calls are not initiated
Jun 09 17:19:43 <Herrie> DougReederG3: OK so API is compatible, just execution not
Jun 09 17:20:02 <Herrie> What is it supposed to do? I.e. what does it do on legacy? Just calls or also opens UI?
Jun 09 17:22:04 <GodGinrai> Herrie: was there a reason Mojo was never open-sourced, btw?
Jun 09 17:23:03 <Herrie> GodGinrai: No idea
Jun 09 17:23:07 <Herrie> I guess just no desire
Jun 09 17:23:15 <Herrie> Since HP was already all in on Enyo
Jun 09 17:23:15 <GodGinrai> :(
Jun 09 17:23:29 <Herrie> So they considered it deprecated and legacy maybe?
Jun 09 17:23:46 <Herrie> Garfonso: ping
Jun 09 17:23:50 <GodGinrai> Except that mojo apps still existed :\
Jun 09 17:24:10 <Herrie> GodGinrai: Yeah
Jun 09 17:24:18 <GodGinrai> I mean, I think Enyo's great
Jun 09 17:24:25 <GodGinrai> but that's no reason to not open up mojo
Jun 09 17:24:41 <Herrie> Theoretically you could sideload the Mojo framework from 3.0.5 Doctor, but bits would need to be hooked up in our LunaWebAppMAnager
Jun 09 17:25:52 <GodGinrai> well, that's worth considering, for backwards-compatibility with apps, I guess
Jun 09 17:26:17 <Herrie> Yeah but we cannot ship the framework...
Jun 09 17:26:21 <GodGinrai> Now here's the real question: What needs to be done to get menus in Enyo to be like mjo menus?
Jun 09 17:26:24 <GodGinrai> *mojo
Jun 09 18:18:24 <DougReederG3> Herrie, under webOS, that PalmBus call actually initiates a phone call.
Jun 09 18:18:41 <GodGinrai> all aboard the PalmBus!
Jun 09 18:18:59 <GodGinrai> destination: before Apotheker
Jun 09 18:19:07 <GodGinrai> :P
Jun 09 18:19:28 <DougReederG3> There's a separate call to launch the dialer an populate it with a number, for untrusted code.
Jun 09 18:33:06 <Garfonso> DougReederG3 Herrie: CardDav can do tasks, too. Many servers support it. The main work missing would be something to parse VJournal objects into the com.palm.tasks kind and vice-versa.
Jun 09 18:34:25 * DougReederG3 nods
Jun 09 18:35:21 <Herrie> Garfonso: OK that's nice to know!
Jun 09 18:35:47 <Herrie> I noticed that the naming convention for cdav is a bit off.... org.webosports.cdav.app which for others we use org.webosports.app.appname
Jun 09 18:35:55 <Herrie> You mind if I change this across the board?
Jun 09 18:36:06 <Herrie> Same for some other bits
Jun 09 18:36:14 <Herrie> Just to have it in line with legacy & rest?
Jun 09 18:36:51 <Garfonso> Herrie: this is because of legacy. Legacy requires 3rd party apps + services to be org.webosports.cdav.app/service
Jun 09 18:37:20 <Herrie> Garfonso: Hmmz OK strange
Jun 09 18:52:43 <nizovn> Herrie: maybe you can build this for more debug info? https://github.com/nizovn/webos-telephonyd/commit/cdc2354f807663cefd96e61440c01864e8fdfa49
**** ENDING LOGGING AT Fri Jun 10 02:59:59 2016