**** BEGIN LOGGING AT Wed Jan 29 02:59:58 2014 Jan 29 07:55:07 JaMa: building now dora-next locally to reproduce the build error Jan 29 08:06:33 morning Jan 29 08:06:48 Garfonso: mornin Jan 29 08:07:46 for reading tags in C++ how about this library: http://taglib.github.io/ ? It's LGPL and has no extra dependencies. Jan 29 08:10:51 during a rescan, is it sufficient to look at the create/modify timestamp of a file? Jan 29 08:11:35 should be, right? I always get a bit confused by what you can do to filesystems in linux.. like noatime and stuff. ;) Jan 29 08:11:44 Garfonso: TagLib looks nice actually :) Jan 29 08:12:20 Garfonso: generally we can for now expect to have ext4 base filesystem Jan 29 08:12:31 and can enable/disable noatime if we want Jan 29 08:12:40 Seeing it's being used by Kindle, Songbird and VLC is a very good sign too :) Jan 29 08:13:03 Garfonso: I think we have to play with different variants and see what works best Jan 29 08:13:21 as our aim should we be use low memory and cpu for this job Jan 29 08:13:27 yes, will try to start that today. :) Jan 29 08:13:56 btw. https://github.com/profusion/lightmediascanner seems be another good candidate Jan 29 08:15:22 from what I see the lib is pretty much bundled with sqlite Jan 29 08:15:49 We'd prefer DB8 right? Jan 29 08:16:13 yes Jan 29 08:16:22 Garfonso: taglib is already on oe-core Jan 29 08:18:30 I'd say TagLib is the best candidate to start with then? Jan 29 08:19:39 for sure Jan 29 08:19:59 what does "in oe-core" exactly mean? It is already part of the system? Or it is easy to include? Jan 29 08:21:24 Garfonso: our build system is made by combining different layers Jan 29 08:21:30 oe-core is the base layer Jan 29 08:21:49 it provides basic recipes for things like glib, systemd, eglibc, ... Jan 29 08:22:10 all other things not suitbale for the core go into different layers like the webos stuff into meta-webos-ports Jan 29 08:22:17 or the machine specific things into meta-smartphone Jan 29 08:24:23 ok. So everything in oe-core is available in any case... Jan 29 08:25:03 morning Jan 29 08:25:29 morphis: ping Jan 29 08:27:28 just wondering oe = open embedded, right? So oe-core is so slim that we use everything from it? Jan 29 08:34:57 Garfonso: right Jan 29 08:35:20 We just have to be a bit careful not to bring too heavy things into the system image Jan 29 08:40:19 Tofe: pong Jan 29 08:47:37 morphis: about luna-init, what would you like to see in the PR actually ? Jan 29 08:48:30 Tofe: you need to point the recipe to https://github.com/webOS-ports/luna-init/commits/webOS-ports/master Jan 29 08:49:01 so do a inherit webos-ports-submissions and set the SRCREV for the HEAD of the webOS-ports/master branch Jan 29 08:49:07 ok, but that's ok for you to point to our fork then ? Jan 29 08:50:06 With your comment on github I had the feelink you would eventually prefer keeping only upstream Jan 29 08:50:43 But maybe i'm wrong and I should take more coffee before reading Jan 29 08:52:34 I'll get some more coffee. Jan 29 09:07:32 Tofe: forking is ok Jan 29 09:11:05 I'll fix my PR Jan 29 09:13:01 Tofe: thanks Jan 29 09:13:51 Tofe: merged your PR for webos-keyboard Jan 29 09:14:08 you need to add inherit webos_system_bus to the webos-keyboard recipe now and bump the PR Jan 29 09:14:58 yep Jan 29 09:26:29 morphis: there is no PR for webos-keyboard yet, is that normal ? Jan 29 09:26:52 you mean for meta-webos-ports? Jan 29 09:27:03 yes Jan 29 09:27:32 I looks for PR in other meta-wop recipes, but there is none, so I thought maybe I'm going the wrong way Jan 29 09:27:37 I looked* Jan 29 09:28:10 no Jan 29 09:28:33 mainly JaMa and me are exchanging commits through our work branches and pick them into the right branch Jan 29 09:28:40 but it's ok for you to do a PR Jan 29 09:28:47 ok, good Jan 29 09:28:49 I will pick it from there Jan 29 09:39:33 morphis: https://github.com/webOS-ports/meta-webos-ports/pull/18 <-- looks better ? Jan 29 09:41:05 Tofe: when you inherit from webos_ports_submissions you don't have to set the SRC_URI Jan 29 09:41:10 the bbclass does that for you Jan 29 09:41:19 but looks good Jan 29 09:41:33 you verified the role file for webos-keyboard is packaged correctly? Jan 29 09:41:49 not yet, I can do it but not before tonight Jan 29 09:41:58 ok Jan 29 09:42:05 if I find enough time I will do that Jan 29 10:09:22 morphis: yesterday I've built qtwayland OK after _removing_ 0004-Adjust-cast-for-wayland-EGL-API-change.patch patch from .bbappend Jan 29 10:09:59 and there is one more change needed in webos-systemd-services.bb (besides SRCREV bump) Jan 29 10:10:16 http://bpaste.net/show/173395/ Jan 29 10:14:14 JaMa: why should we not list db8@.service in SYSTEMD_SERVICE? Jan 29 10:15:56 it fails in do_package Jan 29 10:16:23 and also in postinst Jan 29 10:17:05 why that? Jan 29 10:17:23 sorry db8.service was failing in do_package, db8@.service is better but will fail in postinst, let me find link Jan 29 10:17:57 btw. webos-telephonyd.service is only added for machines when MACHINE_FEATURES has "phone" set Jan 29 10:18:14 http://lists.openembedded.org/pipermail/openembedded-core/2013-October/085546.html Jan 29 10:18:31 morphis: but installed by do_install for both Jan 29 10:18:38 that's why I've added it to FILES_ Jan 29 10:18:52 seeing QA issue for qemux86 build Jan 29 10:19:34 ah ok Jan 29 10:19:36 makes sense Jan 29 11:05:07 Garfonso: http://libexif.sourceforge.net/ looks good for processing image files Jan 29 11:15:37 Garfonso: maybe we should use a sqlite database in the background for file change tracking Jan 29 11:15:51 so we avoid sending unnecessary db8 queries etc. Jan 29 11:24:48 morphis: Just submitted a PR to both Ports and OWO for luna-init to fix some of the timezones and DST bits. Jan 29 11:26:31 LG SVL updated timezones but didn't reflect them for MCC's. Also did some formatting so layout is consistent. Will release a patch for legacy as well. Will solve my DST issues when with in-laws in Russia LOL :P Jan 29 12:37:32 Herrie|Veer: are those commits from upstream? Jan 29 12:43:49 Garfonso: ping Jan 29 12:44:42 LG did 2 updates to luna-init on owo. I did this one on top to address the MCC updates and formatting. In case you didn't do the 2 from LG in Ports those would need to be done as well I guess (though mine will overwrite them anyway). Not sure how quickly Jan 29 12:44:42 LG nowadays does upstream submissions? Jan 29 12:45:15 In the past it took them months if not longer.... Jan 29 12:48:40 Herrie|Veer: with upstream you open webos? Jan 29 12:49:04 Yeah Open webOS, submitted it there as well. Jan 29 12:49:27 And to our Ports Fork as well :) Jan 29 12:51:40 ok, let me take your change in after I've rebased luna-init Jan 29 12:51:52 rebasing it the better way instead of cherry-pick those changes Jan 29 12:52:22 I agree! Jan 29 12:52:52 Just since I did formatting they are obsolete, but all 3 should merge cleanly after each other :) Jan 29 12:57:44 ok Jan 29 12:57:47 Garfonso: ping Jan 29 13:00:53 morphis/tofe/Garfonso/HaDAk: Some sketches from Benjamin for settings app are in :) They look nice, asked him if I can share here so you can decide what you like :) Jan 29 13:01:07 yeah Jan 29 13:01:16 Herrie|Veer: just the icon? Jan 29 13:01:36 Yes, he made 7 sketches on paper :) Jan 29 13:01:50 Just the icon indeed Jan 29 13:07:08 morphis: pong Jan 29 13:07:24 Garfonso: I took a look how the media index was implemented in legacy webOS Jan 29 13:07:52 there are three different components: filenotifyd, fileparserd and a filenoitify.fs service Jan 29 13:08:05 s/filenotify.fs/filenotify.js/ Jan 29 13:08:18 filenotifyd just listens for changes in /media/internal Jan 29 13:08:43 and has a sqlite database at /var/luna/data/filenotify.db3 Jan 29 13:09:17 it has a table called files which lists all found files with name, size and last modified timestamp Jan 29 13:10:09 Garfonso: http://bpaste.net/show/WSfrj7FWlcQShKC8oFFl/ shows how the components work together pretty well Jan 29 13:11:09 the actual db8 work is done in the js service Jan 29 13:12:52 yes, I think I saw that, too. Jan 29 13:13:22 looks like such a structure would reduce the c++ overhead we would have to do for db8 handling a lot Jan 29 13:13:45 ok. Sounds good to me. Jan 29 13:14:51 good Jan 29 13:15:48 I think we can place the js service in the same repo Jan 29 13:17:16 Garfonso: that also makes it possible for us to create smaller and easier portions of work to do Jan 29 13:30:52 sketches: https://www.dropbox.com/sh/u6zfzcj0qblwhwu/DqeJvp53mG Jan 29 13:31:06 I like 2, 4, 5 and 7 Jan 29 13:43:20 4 and 5 are my favorites Jan 29 13:43:28 where I tend more to 4 Jan 29 13:49:03 HaDAk, check https://www.dropbox.com/sh/u6zfzcj0qblwhwu/DqeJvp53mG Jan 29 13:49:16 Which sketch you like most? Jan 29 13:49:19 * HaDAk is checking Jan 29 13:49:54 Benjamin will create something based on these :) Jan 29 13:51:07 it needs to be simple enough that it's still recognizable at 32x32px, and not so flat that it loses all dimension. i think the pulse, puzzle blocks, gear with key, and gear with colors are all out due to these constraints. Jan 29 13:51:20 that leaves the tilt/press button, webos switch with icon, and gear shifting. Jan 29 13:52:18 the gear shifting might be a bit too complex, but i'd be curious to see it at 32x32. i'm partial to the webos switch…but it may be too simple that people might not understand that it represents settings Jan 29 13:52:38 the tilt/press button seems like the logical choice, but my initial reaction to it is kinda meh. Jan 29 13:52:47 maybe... Jan 29 13:53:08 if the gear with key (or maybe with colors…) has the gear protrude enough, it wouldn't appear so flat Jan 29 13:53:14 i'd be curious to see those done, too. Jan 29 13:55:08 i need to reboot for an update. brb in a few. Jan 29 13:59:14 * HaDAk is back. Jan 29 13:59:29 JaMa: with the droped patch qtwayland still fails for me Jan 29 14:01:32 JaMa: I expect I should better use recent webOS-ports/dora for oe-core, right? Jan 29 14:07:51 morphis: I'm using the one in layers.txt (in jansa/dora branch) Jan 29 14:11:16 webOS-ports/dora,webOS-ports/dora-2014-01-18 here Jan 29 14:13:55 ok Jan 29 14:14:14 JaMa: with the last commit in dora-next you reverted the patch for qtwayland, right? Jan 29 14:20:27 JaMa: with Revert "qtwayland: Remove 0004-Adjust-cast-for-wayland-EGL-API-change.patch" qtwayland compiles fine here Jan 29 14:32:58 Do we have a hard requirement to stick with 32*32 for icons? Jan 29 14:38:58 absolutely not Jan 29 14:39:03 it's good design practice, though. Jan 29 14:44:21 That's true... Jan 29 14:52:57 HaDAk: OK, so 4 for you too as preference? JaMa: you have any opinion? Jan 29 14:53:35 which is 4? Jan 29 14:53:46 or, 4 of the 6 total do you mean? Jan 29 14:57:37 There were 7 ;) Jan 29 14:57:48 so there are. Jan 29 14:57:56 hey, it's still morning. leave me alone :( Jan 29 15:07:37 HaDAk: Have some more strong coffee :P Jan 29 15:07:53 I love my small barista espresso in the morning :) Jan 29 15:07:54 not a bad idea. no time for that, though. :( Jan 29 15:08:12 customer box is rebooting repeatedly. it's three days old. Jan 29 15:08:20 it's also not logging the reason, or sending a notification Jan 29 15:08:23 so….whee. :| Jan 29 15:20:52 Herrie|Veer: I'm so bad with graphics, that I won't say any opinion Jan 29 15:21:01 morphis: very weird Jan 29 15:21:28 JaMa: I only see qtmultimedia failing here Jan 29 15:21:36 morphis: I'm now building also with oe-core/master to see if it will be failing for me with/without the patch Jan 29 15:21:39 because there was a syntax error in qtmultimedia.pro Jan 29 15:21:45 morphis: the same here Jan 29 15:21:46 ok Jan 29 15:21:48 JaMa: LOL, ok I also suck but still have an opinion ;) Jan 29 15:22:10 JaMa: they really messed up this in the 5.1.1 release of qtmultimedia? Jan 29 15:22:16 didn't it worked before? Jan 29 15:23:59 morphis: it fails the same in 5.2.0 and 5.1.1 and it's caused by my sed call in the .inc :/ Jan 29 15:24:02 fixed in master now Jan 29 15:24:30 ah ok Jan 29 15:24:34 meta-qt5 master? Jan 29 15:24:44 yes Jan 29 15:24:51 not yet properly tested Jan 29 15:25:00 :) Jan 29 15:42:41 load average: 28.13, 23.18, 18.75 - time for lunch Jan 29 15:43:22 :D Jan 29 16:02:00 morphis: so the architecture in legacy seems to be that filenotifyd triggers filenotifyd.js (via activity manager). Then filenotifyd.js asks filenotifyd for changes and processes them one by one, which includes triggering fileparserd and storing in db8. Jan 29 16:03:53 morphis: should we do it the same way? My naive idea would have been that our filenotifyd recognizes changed files (with its own sqlitedb), optionally parses them (which is native, too, isn't it?) and then triggers our filenotifyd.js service with all the data. Jan 29 16:06:36 I'm wondering a bit about which architecture would be best... are there obvious reasons for what legacy does? Looks quite complex to me. Jan 29 16:34:29 Garfonso: yeah, right Jan 29 16:34:47 Garfonso: I would like to reduce it to just a native and a js service Jan 29 16:35:28 my personal preference would be to do the db8 work in js as dealing it with it in C++ will be more work Jan 29 16:36:41 Garfonso: so one small ls2 based interface between the two daemons Jan 29 16:37:57 Garfonso: see https://github.com/webOS-ports/mediaindexer/commit/c6e94ba9a891734532bb750289ccc66bf07981a7 Jan 29 18:43:28 Garfonso: one thing which worried me about a js only solution was the amount of node modules we might need Jan 29 18:44:15 but I thought a little bit more about it and to reduce the number we could do our own one wrapping taglib and libexiv Jan 29 18:44:36 as having a native and a js service isn't really the best solution Jan 29 18:59:19 Garfonso: generally I want to avoid maintaining a large stack of node modules in our distro Jan 29 18:59:37 but having one self written and maybe another one to use sqlite would be a doable way Jan 29 19:07:36 JaMa: everything built fine for me now with the qtwayland patch reverted Jan 29 19:08:13 morphis: reverted revert or with the same as dora-next is now? Jan 29 19:08:29 with the patch added again Jan 29 19:08:46 here it's still building in master NOTE: Running task 3214 of 5298 Jan 29 19:08:51 ok Jan 29 19:08:55 but with dora it failed for me twice already Jan 29 19:09:03 will do a runtime test later Jan 29 19:09:17 so it's really weird that it always works for you with the patch and for me always only without Jan 29 20:29:21 morphis: yes, I understand that... basically it should be possible to read tags from node.js, too, because it has quite advanced file i/o. I'll look into that a bit, hopefully during the weekend. Jan 29 20:32:48 morphis: master built fine without that 0004 patch Jan 29 20:56:01 morphis: are you still building for hardware (I'm still building for qemux86) Jan 29 20:56:05 ? Jan 29 21:58:50 JaMa: oh yeah, thats the problem Jan 29 22:01:09 EGL headers are different **** ENDING LOGGING AT Thu Jan 30 02:59:58 2014