**** BEGIN LOGGING AT Thu Aug 22 02:59:58 2013
Aug 22 05:41:59 <Herrie> Morphis/JaMa: Which linux distro's have been confirmed to work when building latest Ports?
Aug 22 06:35:28 <ka6sox> Ubuntu 12.04 still works
Aug 22 08:11:06 <Tofe> morphis: ping
Aug 22 08:30:32 <morphis> Tofe: pong
Aug 22 08:45:34 <Tofe> morphis: I'm still having this cmake error when trying to compile luna-next with the CMakeLists.txt which contains webos_modules_init
Aug 22 08:46:03 <panda-z> was playing luna-next in virtualbox, nice work ;-)
Aug 22 08:46:04 <Tofe> So I'm wondering if you are using some special flags or branch to be used together with that version
Aug 22 08:46:40 <Tofe> panda-z: that's just the beginning :)
Aug 22 08:49:29 <morphis> Tofe: ah
Aug 22 08:49:33 <morphis> Tofe: in OE?
Aug 22 08:50:20 <morphis> panda-z: it's already working fine for you in virtualbox?
Aug 22 08:50:47 <Tofe> morphis: yes
Aug 22 08:51:02 <morphis> Tofe: hm, can you give me the exact output?
Aug 22 08:51:12 <panda-z> Tofe: i'm looking forward to it
Aug 22 08:51:49 <morphis> panda-z: time for helping us?
Aug 22 08:51:51 <panda-z> morphis: yes, it boots fine, and i see the luna-next ui
Aug 22 08:51:53 <Tofe> morphis: http://pastebin.com/QCddrztc
Aug 22 08:52:15 <morphis> panda-z: thats great I didn't had time to verify that my patches cause everything to launch automatically
Aug 22 08:52:45 <panda-z> morphis: how can i help?
Aug 22 08:53:01 <morphis> Tofe: ah, you have latest version of meta-webos-pro?
Aug 22 08:53:12 <morphis> panda-z: you know QML?
Aug 22 08:53:15 <Tofe> morphis: well, I have dylan
Aug 22 08:53:23 <morphis> Tofe: ah
Aug 22 08:53:31 <morphis> so not master branch of meta-webos-ports?
Aug 22 08:53:43 <Tofe> no, usually dylan works fine :)
Aug 22 08:53:51 <panda-z> morphis: i know javascript, and just a little qml
Aug 22 08:54:19 <morphis> panda-z: what would be your preference to help us with as we mostly need help with everything
Aug 22 08:54:36 <morphis> Tofe: you need this one: https://github.com/webOS-ports/meta-webos-ports/commit/f423e45adc3001bd9948f1760a2cba533869120e
Aug 22 08:54:51 <morphis> Tofe: and you should really upgrade to master
Aug 22 08:55:54 <Tofe> morphis: oh, I missed that bb commit. Should have guessed.
Aug 22 08:56:12 <morphis> :)
Aug 22 08:56:15 <Tofe> morphis: I'll switch to master, then
Aug 22 08:56:21 <morphis> Tofe: ok
Aug 22 08:56:32 <morphis> panda-z: on UI site there is still a lot eft
Aug 22 08:56:37 <Tofe> I was keeping dylan just to avoid problems not related to my developments
Aug 22 08:56:53 <Tofe> quite a lot, yes :)
Aug 22 08:57:06 <panda-z> morphis: i don't have a device in my hand. i think i can do some work related to the UI part
Aug 22 08:57:26 <morphis> panda-z: thats the great think you can work with QtCreator on the UI part
Aug 22 08:57:39 <morphis> Tofe did some changes the last days to make this possible
Aug 22 08:57:46 <morphis> and you can test also fine with the emulator
Aug 22 08:57:56 <Tofe> panda-z: http://webos-ports.org/wiki/Luna_Next#Development_on_a_desktop_machine
Aug 22 08:58:55 <morphis> panda-z: what about the device menu?
Aug 22 08:59:56 <panda-z> Tofe: the changes are in Tofe/work branch, right?
Aug 22 09:00:07 <Tofe> panda-z: the remark about the stub QML module is quite important: in that qmlproject, I'm overriding the default LunaNext C++ module, which is only available on target platform, with a fake simple QML module that exports the same symbols and tries to mimic the behavior of the C++ code
Aug 22 09:00:09 <morphis> panda-z: no, they are in master
Aug 22 09:01:48 <panda-z> ah, make sense
Aug 22 09:03:05 <panda-z> morphis: i don't see any device menu
Aug 22 09:03:24 <Tofe> panda-z: yep, that still needs to be done :p
Aug 22 09:03:47 <Tofe> I guess will be able to reuse the one from LSM, but morphis knows a bit better
Aug 22 09:03:52 <Tofe> we'll*
Aug 22 09:04:54 <Tofe> panda-z: the idea is to propose a pluggable system menu, whose mecanism has yet to be defined
Aug 22 09:05:25 <Tofe> shouldn't be too difficult, though, as most of QML is done that way anyway
Aug 22 09:05:31 <panda-z> so will we re-implement the device menu in our own?
Aug 22 09:06:18 <Tofe> No, I think we'll expose the existing one as a QML object, and we'll integrate it in the top bar
Aug 22 09:07:09 <Tofe> (I don't know if there is a QML version of the device menu? What morphis wrote on the wiki suggests so...)
Aug 22 09:07:41 <Tofe> (well, it suggests there is a new UI, not that it is in QML :) )
Aug 22 09:08:43 <morphis> Tofe, panda-z: yes the device menu of the OWO luna-sysmgr is done in QML
Aug 22 09:08:44 <panda-z> it would be great if there is an exist qml version of device menu
Aug 22 09:08:54 <morphis> it highly depends on some C++ code but we can stub it for the first time
Aug 22 09:09:32 <morphis> panda-z, Tofe: at https://github.com/openwebos/luna-sysmgr/tree/master/uiComponents are all the QML components
Aug 22 09:09:40 <morphis> and the device menu is at https://github.com/openwebos/luna-sysmgr/tree/master/uiComponents/SystemMenu
Aug 22 09:10:19 <morphis> I am not 100% sure but it should no have a direct dependency on native code as from what I remember the native side was only communicating with the QML part over signals
Aug 22 09:10:34 <Tofe> oh, great
Aug 22 09:10:41 <morphis> yes
Aug 22 09:10:57 <morphis> panda-z: so that one needs to be ported to QtQuick 2.0 and integrated into luna-next
Aug 22 09:11:14 <morphis> making the system menu pluggable should be nice but not our top priority
Aug 22 09:11:43 <morphis> panda-z: ah and you don't have to care about connected to the various system services, we will add that later
Aug 22 09:13:24 <panda-z> morphis: ok, i'll read the source code first and have a try
Aug 22 09:13:31 <morphis> panda-z: ok
Aug 22 09:13:49 <morphis> panda-z: find with me adding you to our planing board for this?
Aug 22 09:14:29 <panda-z> yes, with pleasure
Aug 22 09:20:35 <morphis> Tofe: can you update your cards on the board after I've merged your PR?
Aug 22 09:20:50 <Tofe> morphis: yes, was going to do so
Aug 22 09:20:56 <morphis> ok
Aug 22 09:22:15 <Tofe> hop, done
Aug 22 09:25:05 <morphis> thanks
Aug 22 09:28:37 <morphis> JaMa: ok, the patch needs some more fixes
Aug 22 09:28:49 <morphis> JaMa: will send you a working and tested version later
Aug 22 09:29:43 <JaMa> morphis: ok, thanks
Aug 22 09:30:33 <JaMa> srcrev switch is scheduled for this weekend, I expect to have a bit more time for -ports next week
Aug 22 09:40:33 <morphis> JaMa: great
Aug 22 16:13:24 <ka6sox> morphis, the holiday schedule is over for the Installer Team and we are back @ working on this.
Aug 22 16:13:52 <morphis> ka6sox: great
Aug 22 16:14:12 <morphis> ka6sox, JaMa: can you have a short look at http://www.webos-ports.org/wiki/System_Upgrade
Aug 22 16:14:32 <morphis> it's only a quick draft but outlines a idea I had today
Aug 22 16:16:28 <morphis> it's rough and doesn't complete in itself as it doesn't covers some upgrade scenarios
Aug 22 16:17:13 <morphis> as I think holding of a client from upgrading isn't possible with this but at least it offers us the possiblity to add meta informations for a upgrade
Aug 22 16:19:19 <ka6sox> this would be compatible with systemd or still upstart?
Aug 22 16:20:37 <morphis> with both
Aug 22 16:21:13 <morphis> ka6sox: instead of having a file placed on the http server having a simple web service printing out json would be better
Aug 22 16:23:26 <ka6sox> yes, create a list to be curled and then installed....Like Preware!
Aug 22 16:28:09 <morphis> ka6sox: yes, a service could be given the current platform version and then returns just a smaller list than downloading a some mega byte big textfile
Aug 22 16:28:18 <morphis> but thats a implementation detail we can fix later
Aug 22 16:28:42 <morphis> we just need to integrate this into the staging process JaMa  will implement
Aug 22 16:29:39 <JaMa> looks good on quick read
Aug 22 16:30:26 <ka6sox> okay
Aug 22 16:30:58 <ka6sox> morphis, I can also have the installer setup to do incremental "upgrades" offline too.
Aug 22 16:31:17 <morphis> that would be another good option
Aug 22 16:33:01 <ka6sox> again using same mechanism
Aug 22 16:33:01 <ka6sox> I"d really like a path that allows us to get from alpha2 to beta for example
Aug 22 16:33:01 <ka6sox> without trashing all the data
Aug 22 16:33:18 <morphis> ka6sox: you mean user-data?
Aug 22 16:33:29 <ka6sox> I'm not a fan of Preware or something on the device switching series of releases.
Aug 22 16:33:38 <ka6sox> morphis, yes, user data
Aug 22 16:33:45 <ka6sox> custom settings etc.
Aug 22 16:34:00 <morphis> ka6sox: that should be doable very easily once we're mounting something to /media/interna
Aug 22 16:34:59 <ka6sox> my experience with opkg is that its not as smart as dpkg and other things for overwriting config files
Aug 22 16:36:18 <morphis> ka6sox: thats why we need to the rootfs in ro state
Aug 22 16:36:29 <morphis> so modifications to anything of the core system is not possible
Aug 22 16:36:45 * ka6sox confused....
Aug 22 16:36:49 <morphis> and if the user does there has to be an instance to rollback those before an update is performend
Aug 22 16:36:57 <ka6sox> I thought we were talking about coreos upgrades?
Aug 22 16:37:00 <morphis> yes
Aug 22 16:37:25 <morphis> with custom settings you mean modifications to /etc for example?
Aug 22 16:37:42 <ka6sox> so if openssh needs upgrading I want the conf files left alone if they are not stock.
Aug 22 16:37:48 <ka6sox> yes, mods to /etc
Aug 22 16:37:53 <morphis> hm
Aug 22 16:38:11 <morphis> does opkg offer a option for leaving out conf files on upgrade?
Aug 22 16:38:13 <ka6sox> this is where dpkg/yum/etc all are better.
Aug 22 16:38:22 <morphis> if so we could add a simple file as indicator for this
Aug 22 16:38:36 <morphis> but that could render the system into a broken state
Aug 22 16:38:50 <ka6sox> either package developers don't know or can't tell
Aug 22 16:39:02 <ka6sox> also I suspect they don't expect interactive upgrades
Aug 22 16:39:11 <morphis> yes
Aug 22 16:39:39 <morphis> thats why I generally don't want anybody to modify the core system as it's causing a lot of trouble for us
Aug 22 16:40:09 <ka6sox> we need to address how to handle customizations during upgrades
Aug 22 16:40:23 <ka6sox> some are annoying..some will leave a brick
Aug 22 16:40:41 <ka6sox> (well we know its not a brick..just seems that way)
Aug 22 16:41:11 <morphis> ka6sox: for the moment I would say we just leave out this case as it's causing work we don't have the time for at the moment
Aug 22 16:41:39 <ka6sox> ok
Aug 22 16:41:47 <morphis> so once someone changes something in the rootfs system will possible be broken after the next upgrade
Aug 22 16:42:08 <ka6sox> should we revisit overlays?
Aug 22 16:42:11 <morphis> and if the update process detects a failing upgrade it will avoid to upgrade again to a newer version
Aug 22 16:42:23 <morphis> overlays might be a good option
Aug 22 16:42:56 <morphis> like aufs
Aug 22 16:43:03 <ka6sox> right
Aug 22 16:43:52 <morphis> that might be the way to go and easy to integrate
Aug 22 16:45:22 <ka6sox> what kernel are we currently using? 3.0.28ish?
Aug 22 16:46:36 <ka6sox> aufs does not have 3.0 support...earliest is 3.2[EOL]
Aug 22 16:46:37 <morphis> yes
Aug 22 16:46:46 <morphis> 3.0 for gnexus and 3.1 for n7
Aug 22 16:46:53 <morphis> hm
Aug 22 16:47:52 <ka6sox> http://aufs.sourceforge.net/
Aug 22 16:48:08 <Garfonso> hi
Aug 22 16:48:35 <morphis> Garfonso: hey
Aug 22 16:48:42 <morphis> ka6sox: you about any alternative?
Aug 22 16:48:46 <ka6sox> morning garfonso
Aug 22 16:48:53 <ka6sox> morphis, I will look into others
Aug 22 16:49:10 <ka6sox> including some FUSE options
Aug 22 16:49:32 <morphis> ok
Aug 22 16:49:52 <morphis> ka6sox: can add a paragraph about this on the update wiki site?
Aug 22 16:50:41 <ka6sox> yes, i think we need to tell people about this option as it will create a nice clean space
Aug 22 16:50:55 <ka6sox> we could use the palm method of doing configs too.
Aug 22 16:51:08 <ka6sox> RO root with writable /et
Aug 22 16:51:11 <ka6sox>  /etc
Aug 22 16:51:35 <morphis> yes
Aug 22 16:52:02 <ka6sox> I'd actually prefer that as its simpleist
Aug 22 16:52:28 <ka6sox> so /var/log/* and /etc are both writable...
Aug 22 16:52:38 <ka6sox> actually I think /var was writable always.
Aug 22 16:54:44 <morphis> ka6sox: yes /var is writable
Aug 22 16:54:50 <morphis> but we can make /etc writable too
Aug 22 16:55:32 <morphis> ka6sox: we could do another thing to
Aug 22 16:55:33 <morphis> o
Aug 22 16:56:07 <morphis> once somebody wants to override something in /etc he has to copy the original file  filename.original and installs the new one
Aug 22 16:56:22 <morphis> on update we switch both files and let the update process
Aug 22 16:56:35 <morphis> afterwards it can be either switched back automatically or manually
Aug 22 16:57:57 <ka6sox> we do something similar for lunace
Aug 22 17:00:08 <morphis> ok
Aug 22 17:00:15 <morphis> lets leave this open for now
Aug 22 17:03:40 <ka6sox> I didn't think we would solve the world's problems here...just having discussion to see options :)
Aug 22 17:03:53 <morphis> :)
Aug 22 17:04:32 <morphis> ka6sox: btw. panda-z|away will start to look at the device menu
Aug 22 17:04:58 <ka6sox> but as I am working again on installer I was thinking about upgrades (especially from Alpha to Betas) and using the installer to do this.
Aug 22 17:04:58 <ka6sox> I'm not a fan of letting the device do this on device.
Aug 22 17:05:31 <ka6sox> as it probably will involve changing a lot of coreos components and I don't like doing that while "running"
Aug 22 17:05:42 <ka6sox> morphis, excellent.
Aug 22 17:05:49 <ka6sox> thanks panda-z|away
Aug 22 17:05:52 <morphis> ka6sox: yes, that why we're rebooting the system in a special mode
Aug 22 17:06:16 <morphis> http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
Aug 22 17:07:40 <ka6sox> maybe we should look @ btrfs too?
Aug 22 17:08:13 <ka6sox> if we are using systemd the boots aren't 10minutes long at least
Aug 22 17:08:43 <morphis> ka6sox: we can't
Aug 22 17:09:13 <ka6sox> ok
Aug 22 17:09:14 <morphis> I would like to avoid having the user putting a image on his phone but rather let him extract a tar.gz
Aug 22 17:09:46 <ka6sox> hmmm...
Aug 22 17:10:14 <ka6sox> this means the prep for an upgrade means we need to do the config swaps *before* untaring the .gz
Aug 22 17:10:32 <ka6sox> or copying them out someplace
Aug 22 17:10:46 <morphis> we're talking about image based upgrades?
Aug 22 17:11:03 <morphis> the image is just put there once and then upgraded by opkg
Aug 22 17:11:16 <ka6sox> the .gz just contains packages?
Aug 22 17:11:26 <morphis> the full rootfs
Aug 22 17:11:52 <morphis> ka6sox: we're currently putting the ext2 into the user data directory of the android system and mounting it via loop
Aug 22 17:12:13 <morphis> with using the tar.gz we avoid doing this by just extract the rootfs into the same folder
Aug 22 17:12:31 <ka6sox> which overwrites any modified configs
Aug 22 17:12:50 <ka6sox> so we need to save them outside first
Aug 22 17:13:25 <morphis> yes
Aug 22 17:13:47 <ka6sox> things like authorized_keys, the system key, the known_hosts all need to be preserved
Aug 22 17:13:48 <morphis> either with the method I described (the update process can move them to /var and copy them back once it's done)
Aug 22 17:14:03 <morphis> yes
Aug 22 17:14:14 <ka6sox> we don't want the system key changing just because we did an upgrade
Aug 22 17:14:15 <morphis> it's pretty huge work :)
Aug 22 17:14:21 <ka6sox> yes, I understand
Aug 22 17:14:31 <morphis> but afaik system key is already somewhere outsite /etc
Aug 22 17:14:36 <ka6sox> this is why the Installer Team is thinking about this in our scripting
Aug 22 17:14:45 <morphis> ah and one fact: we're using adb currently
Aug 22 17:14:50 <morphis> so no rndis/ssh
Aug 22 17:14:59 <morphis> ka6sox: btw. who is the installer team?
Aug 22 17:15:07 <ka6sox> wormo and I :)
Aug 22 17:15:53 <morphis> ok :)
Aug 22 17:16:07 <morphis> you really need to publish the work so we can have a look together
Aug 22 17:16:17 <ka6sox> she will now...
Aug 22 17:16:37 <ka6sox> back from holidays you know
Aug 22 17:17:26 <morphis> :)
Aug 22 17:18:27 <ka6sox> she has static adb and static boot now
Aug 22 17:18:38 <ka6sox> fastboot
Aug 22 17:19:02 <ka6sox> so adbd is not easily installable in our initramfs
Aug 22 17:19:06 <ka6sox> s/not/now/
Aug 22 17:20:05 <morphis> ka6sox: it's part of our rootfs
Aug 22 17:21:03 <ka6sox> yes, but the installer needs a initramfs to shove in there. with the kernel (better to control the process)
Aug 22 17:21:21 <ka6sox> our rootfs isn't installed at that point
Aug 22 17:21:55 <ka6sox> we don't want android to boot up at that point
Aug 22 17:22:46 <morphis> ok
Aug 22 17:23:09 <ka6sox> so we boot, mount the partitions we need, move kernel/MLO out of the way (saving it), put ours in, create rootfs, put stuff in there and then reboot
Aug 22 17:23:53 <ka6sox> we still need a small android app to allow dual booting...but thats later
Aug 22 17:24:20 <ka6sox> I have someone who will do that one.
Aug 22 17:24:32 <morphis> ok, great
Aug 22 17:24:44 <ka6sox> we will also need a webOS app to do the same
Aug 22 17:24:50 <ka6sox> (but again I have someone)
Aug 22 17:26:29 <morphis> ok
Aug 22 17:26:36 <morphis> I will leave this mostly up to you
Aug 22 17:29:19 <ka6sox> :)
Aug 22 17:29:44 <ka6sox> we need to post the recipies for this...I will ask tonight about this.
Aug 22 17:30:36 <ka6sox> okay I need to go out for a few...bbiaw
Aug 22 19:46:16 <morphis> JaMa: https://github.com/meta-qt5/meta-qt5/pull/25
Aug 22 19:48:05 <JaMa> morphis: sorry for not noticing it before, but doesn't it "hardcode" ${OE_QMAKE_PATH_EXTERNAL_HOST_BINS} into cmake files?
Aug 22 19:48:24 <morphis> yes, it does
Aug 22 19:48:31 <JaMa> morphis: e.g. when qtbase is reused from sstate, does it use right OE_QMAKE_PATH_EXTERNAL_HOST_BINS value from environment?
Aug 22 19:48:50 <morphis> yes
Aug 22 19:50:24 <morphis> http://bpaste.net/show/B39wyjaDM9Yt8n6OT6nl/
Aug 22 19:52:22 <JaMa> ah OK, I see now
Aug 22 19:52:46 <morphis> it's a little bit tricky, only $$var gets replaced
**** ENDING LOGGING AT Fri Aug 23 02:59:59 2013