**** BEGIN LOGGING AT Tue Feb 24 02:59:58 2015
Feb 24 03:17:20 <DougReeder> Just built testing, and there are some oddities in the “Select your Timezone” list
Feb 24 03:20:11 <DougReeder> There’s New York & Detroit for “Eastern Time” and seven cities for Indianna, all labeled “Eastern Standard Time (Australia) GMT -5:00 [same as NY and Detroit]
Feb 24 03:21:37 <DougReeder> And I’m pretty sure no part of Canada is on “Myanmar Standard Time”… thought obviously GMT -7:00 is correct for many placed there.
Feb 24 03:24:47 <DougReeder> I’m not seeing http://issues.webos-ports.org/issues/867 under this build, so I will close it.
Feb 24 03:29:49 <DougReeder> meta-luneos … but where is Exeter?
Feb 24 04:33:46 <DougReeder> And bumping the SRCREV for Contacts and Settings has broken 867 again. :-(
Feb 24 05:47:58 <Herrie|2> DougReeder: Strange with the Timezones let me check
Feb 24 05:48:10 <Herrie|2> Could be there are odd ones in the list...
Feb 24 05:48:32 <Herrie|2> It's generated by a Python script from Open webOS based on the IANA TZ info
Feb 24 05:53:51 <Herrie|2> could be there's something odd in my code, though it doesn't do much specials, just pulls it with a luna-call and displays it. Nothing much happens for the rest
Feb 24 05:53:58 <Herrie|2> N4 needs chargign it seems...
Feb 24 06:25:20 <Herrie|2> DougReeder: N4 is charged up
Feb 24 06:25:37 <Herrie|2> Seems it gets those values directly from luna-send -n 1 -a org.webosports.app.firstuse luna://com.palm.systemservice/getPreferenceValues '{"key":"timeZone"}'
Feb 24 06:29:57 <Herrie|2> DougReeder: Ah it might go wrong here somehow: https://github.com/openwebos/luna-init/blob/master/src/abbrevs.py#L148
Feb 24 06:30:24 <Herrie|2> https://github.com/openwebos/luna-init/blob/master/src/abbrevs.py#L94
Feb 24 06:30:59 <Herrie|2> It seems that there are multiple timezones with the same abbreviation and it probably picks the wrong one for the description. Not sure how to fix that with current code, will have a look ;)
Feb 24 08:03:05 <Tofe> morphis: pong²
Feb 24 08:19:57 <Herrie|Veer> morning
Feb 24 08:20:12 <Herrie|Veer> morphis: ping
Feb 24 09:52:46 <Garfonso> morning
Feb 24 09:53:39 <Herrie|Veer> Garfonso: Might have some ideas on the timezone stuff. Seems we have some issue in US and other areas as well
Feb 24 09:54:17 <Herrie|Veer> Just need to get a hold of morphis now... Because I cannot figure out 100% how current tz info is populates
Feb 24 09:54:19 <Herrie|Veer> d
Feb 24 10:02:17 <morphis> Herrie|Veer: pong
Feb 24 10:04:29 <Herrie|Veer> morphis: I'm confused on how the actual timezone info gets into the system currently
Feb 24 10:05:33 <morphis> Herrie|Veer: basically everyone reads /etc/localtime
Feb 24 10:05:42 <morphis> which links to the current timezone file
Feb 24 10:05:57 <morphis> in our case luna-sysservice links the correct file
Feb 24 10:06:17 <morphis> Herrie|Veer: do a opkg list tzdata to see which timezone data files are on the device
Feb 24 10:06:27 <morphis> each file has all information for the timezone
Feb 24 10:14:51 <Herrie|Veer> morphis OK
Feb 24 10:21:41 <Herrie|Veer> OK but how does the data from our luna-send get populates? We use the owo python script somehow?
Feb 24 10:21:48 <Herrie|Veer> Because we have some issues
Feb 24 10:22:04 <Herrie|Veer> With wrong descriptions
Feb 24 10:25:10 <Herrie|Veer> Which come from the luna-init/src/abbrevs.py
Feb 24 10:25:56 <Herrie|Veer> So I thought we use gen-ext-timezones.py + tzdata + abbrevs.py, mccInfo.json and uiTzInfo.json to generate our data
Feb 24 10:26:07 <Herrie|Veer> But I couldn't find where that's done in build
Feb 24 10:28:52 <Herrie|Veer> We have Canada showing up as Malaysia Standard Time instead of Mountain Standard Time (North America). I'm happy to try to fix but a bit lost
Feb 24 10:35:33 <Herrie|Veer> I mean luna-send -n 1 luna://com.palm.systemservice/getPreferenceValues '{"key":"timeZone"}' gives me values that are not in ext-timezones.json
Feb 24 10:35:57 <Herrie|Veer> Like the Busingen one for Germany that Garfonso mentioned
Feb 24 10:39:32 <morphis> Herrie|Veer: that isn't done in the build
Feb 24 10:39:53 <morphis> we just use what is in https://github.com/webOS-ports/luna-init/tree/webOS-ports/master/files/conf
Feb 24 10:40:01 <morphis> which is generated
Feb 24 10:41:06 <morphis> Herrie|Veer: but better check https://github.com/openwebos/luna-sysservice/tree/master/Src
Feb 24 10:45:02 <Herrie|Veer> Ah that seems to do something different...
Feb 24 10:45:11 <Herrie|Veer> That might explain
Feb 24 10:45:18 <Herrie|Veer> Will look into it
Feb 24 13:01:59 <morphis> Herrie|Veer: really, in which way?
Feb 24 13:03:06 <Herrie|Veer> morphis: I cannot figure how we get the Germany/Busingen for example
Feb 24 13:03:28 <Herrie|Veer> It's not very well documented tbh (no surprise there...)
Feb 24 13:03:41 <Herrie|Veer> Also the tz descriptions how these get there
Feb 24 13:04:02 <Herrie|Veer> Reading through the cpp but that's not my best language lol
Feb 24 13:04:39 <morphis> Herrie|Veer: not much time but let me take a quick look
Feb 24 13:06:14 <morphis> Herrie|Veer: so it uses ext-timezones.json as base
Feb 24 13:06:19 <Herrie|Veer> We for sure have descriptions that come from abbrevs.py somehow
Feb 24 13:06:38 <Herrie|Veer> Yeah but that doesn't have the Germany/Busingen one
Feb 24 13:06:45 <Herrie|Veer> So that's how I got confused
Feb 24 13:07:21 <Herrie|Veer> ext-timezones.json is generated by gen-ext-timezones.py which explains the description problem
Feb 24 13:09:12 <Herrie|Veer> Because that takes the abbrevs.py as input
Feb 24 13:09:30 <Herrie|Veer> That leaves the question where the Germany/Busingen comes from
Feb 24 13:09:55 <Herrie|Veer> I guess it takes that from tzdata directly and not from ext-timezones.json :s
Feb 24 13:10:29 <Herrie|Veer> So what the systemservice returns is probably a combination of ext-timezones.json + tzdata in filesystem?
Feb 24 13:10:53 <morphis> possible
Feb 24 13:11:26 <morphis> see https://github.com/openwebos/luna-sysservice/blob/master/Src/TzParser.cpp
Feb 24 13:12:33 <morphis> Herrie|Veer: check
Feb 24 13:12:34 <morphis> bash-4.3# find . -type f | xargs grep -ni Busingen
Feb 24 13:12:34 <morphis> ./zone.tab:157:DE	+4742+00841	Europe/Busingen	Busingen
Feb 24 13:12:58 <morphis> so that is where it comes from
Feb 24 13:13:08 <morphis> next question is why it gets selected
Feb 24 13:13:33 <Herrie|Veer> Well that I know
Feb 24 13:13:44 <Herrie|Veer> That's my code
Feb 24 13:13:48 <morphis> ah
Feb 24 13:14:09 <Herrie|Veer> It takes the 1st timezone for country with matching offset
Feb 24 13:14:20 <Herrie|Veer> For Busingen and Berlin this is both true
Feb 24 13:14:30 <Herrie|Veer> And Berlin one doesn't have preferred flag
Feb 24 13:16:20 <Herrie|Veer> I can work around that by adjusting the gen-ext-timezones.py
Feb 24 13:17:33 <Herrie|Veer> Needs tweaking for tz descriptions anyway
Feb 24 14:55:25 <morphis> Herrie|2: ok
Feb 24 14:56:26 <PatrickC> https://www.dropbox.com/s/yqnql4j4l1e7k4n/Region%20capture%201%20copy.png?dl=0
Feb 24 17:34:08 <morphis> Tofe: created http://issues.webos-ports.org/issues/871 for you
Feb 24 17:42:34 <morphis> Herrie|2: can you add your screenshots to http://issues.webos-ports.org/issues/871?
Feb 24 18:28:21 <morphis> <morphis> Herrie7: can you add your screenshots to http://issues.webos-ports.org/issues/871?
Feb 24 18:32:06 <morphis> Herrie: ^^
Feb 24 18:39:20 <Tofe> morphis: ok thanks
Feb 24 18:43:27 <morphis> ccccccdtvjiflcffvkibdejgtkhfdbjrkfjceluedbdh
Feb 24 18:48:40 <morphis> Tofe: you have an legacy webOS device to see how it works there?
Feb 24 18:52:26 <morphis> Tofe: btw. we have now sensor support
Feb 24 19:04:40 <Herrie> morphis: done
Feb 24 19:05:40 <morphis> nizovn: we have one problem ...
Feb 24 19:06:03 <morphis> in short: can we split out the qtsensors plugin for sensorfw somehow :)
Feb 24 19:08:43 <morphis> otherwise we have some dependency problems
Feb 24 19:09:25 <morphis> nizovn: I will setup a qtsensors-sensorfw-plugin repo for that
Feb 24 19:10:58 <morphis> nizovn: https://github.com/webOS-ports/qtsensors-sensorfw-plugin
Feb 24 19:11:36 <morphis> that recipe needs a PACKAGE_ARCH = "${MACHINE_ARCH}" set
Feb 24 19:12:27 <morphis> and then qtsensors-sensorfw-plugin and sensorfw needs to be included in LIBHYBRIS_RDEPENDS at meta-luneos/recipes-core/packagegroups/packagegroup-luneos-extended.bb
Feb 24 19:12:43 <morphis> that would make our life a lot easier
Feb 24 19:12:49 <morphis> Herrie: thanks
Feb 24 19:17:36 <HaDAk> funny question for you guys
Feb 24 19:17:45 <HaDAk> did anyone ever put together a Mochi theme for enyo?
Feb 24 19:19:27 <morphis> HaDAk: you mean using mochi within an application?
Feb 24 19:19:47 <HaDAk> i dunno... if i wanted to make an application (or website) using the styling of mochi
Feb 24 19:19:52 <HaDAk> it's just so...pretty.
Feb 24 19:22:19 <GodGinrai> yup
Feb 24 19:22:26 <GodGinrai> I've been meaning to make a Mochi app for a while now
Feb 24 19:22:34 <GodGinrai> just haven't decided on what to make using it
Feb 24 19:23:00 <GodGinrai> HaDAk: Mochi is open sourced
Feb 24 19:23:16 <morphis> HaDAk: see http://forums.webosnation.com/webos-apps-games/327905-nisi-read-later-client-pocket-readability.html
Feb 24 19:23:16 <HaDAk> oh! i didn't realize it was finished/released
Feb 24 19:23:18 <GodGinrai> HaDAk: https://github.com/enyojs/mochi
Feb 24 19:23:25 <HaDAk> yay!
Feb 24 19:26:22 <Tofe> morphis: I have the Pre3 and TP that still work like a charm
Feb 24 19:27:11 <GodGinrai> I love my Pre3
Feb 24 19:27:20 <GodGinrai> even if I don't use it as a phone anymore
Feb 24 19:27:32 <GodGinrai> due to the VZW one not having 4G
Feb 24 19:31:15 <morphis> Tofe: great
Feb 24 19:47:05 <nizovn> morphis: ok, so i will copy just plugin from qtsensors. btw i forgot to set rdepends in qtsensors_git.bbappend and maybe there are some symlinks problems in sensorfw. After that successful qtwebkit build i changed qtsensors recipe, and can't build webkit again. so correction of recipes can take some time.
Feb 24 19:48:16 <morphis> nizovn: qtsensors should not have a DEPENDS/RDEPENDS on sensorfw
Feb 24 19:50:29 <nizovn> ah, yes, new plugin..
Feb 24 19:53:57 <morphis> nizovn: problem is that we build things differently
Feb 24 19:54:08 <morphis> things which are specific for a machine are build separately
Feb 24 19:54:30 <morphis> so everything which needs libhybris has PACKAGE_ARCH = "${MACHINE_ARCH}"
Feb 24 19:54:44 <morphis> there should be no direct depdencies between those and others
Feb 24 19:54:59 <morphis> otherwise for example we would have to build qtwebkit for every machine
Feb 24 19:55:10 <morphis> and this way we can build it only once for all machines we support
Feb 24 19:55:28 <morphis> nizovn: when you can do the plugin and its bb file I can take care about the rest
Feb 24 19:56:04 <nizovn> ok
Feb 24 20:03:24 <morphis> nizovn: see https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-PACKAGE_ARCH
**** ENDING LOGGING AT Wed Feb 25 02:59:58 2015