15:11:18 #startmeeting 15:11:18 Meeting started Wed May 8 15:11:18 2013 UTC. The chair is notmart. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 15:11:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:11:37 ok, so let's start 15:12:00 #topic stable releases 15:13:11 Ok, can you start by describing the need? 15:13:18 Sage: so, one thing that is kinda blocking the release of pa4 right now, is how to do a release that will have repositories stable in time 15:13:30 but that will still be possible to make updates o them 15:14:32 what would be needed is, a stable release of mer that stays there indefinitely (or at least x months) as a build target 15:14:52 that we have already 15:15:08 then all that depends from it would as well be stable (so mer core, nemo:* kde:*) 15:15:23 o/ 15:16:13 notmart: then what you want is to fork the projects under kde I would say. adding stable under current nemo:* projects isn't going to work as sources of nemo continue updating while we go. 15:16:50 notmart: is it enough to have static repos where kde:* builds against or do you need obs projects for each nemo:* as well? 15:16:59 ok, so snapshots of all the needed nemo projects under kde? 15:17:06 notmart: would it be favorable to also have a Kubuntu + Plasma Active image ? 15:17:38 shadeslayer: if somebody does that he's welcome 15:17:46 ack 15:17:49 kinda ot right now tough 15:17:52 yeah 15:18:08 and that gives adaptations and nemo:mw a "stable" state 15:18:25 Can we keep this only about mer+nemo? And leave Kubuntu out as it would be totally different topic? 15:18:31 what about the mer part? 15:18:37 Sage: roger 15:18:52 is it possible to build agains a determined release even if is not latest? 15:19:05 notmart: yes 15:19:09 notmart: let me give example 15:19:43 notmart: http://pastie.org/7818437 15:20:07 there everything is bulid against static mer releases and it is already available in mer obs. 15:20:28 it changes only when someone changes the project config 15:21:03 that's more of a release tag than a stable version? 15:21:09 ok, so as long a release stays on http://releases.merproject.org/releases/ it will be available from there 15:22:27 well, at the moment the current status is quite well tested with the current latest, that is 0.20130411.1, so would be already quite good always have it as base during the pa4 lifecycle 15:23:05 aseigo: well you can always introduce your own fixes in kde:stable:mer or similar project if you want that fixes issues on specific mer release that you are basing your release on 15:23:23 at least until we find a problem with one of the packages (defect, security issue, ...). would such updates be accomplished by yet another repo on top of that release that replaces the updated packages? 15:23:31 right... ok. 15:24:27 mer doesn't maintain that kind of security patches to specific releases but those fixes will always go to the latest. It is up to vendor (here plasma active) to maintain fixes on top of specific release if update to latest isn't wanted. 15:24:49 btw, also note that we now use mds2 which allows to lock on binary releases much easier 15:24:58 not particularl optimal, but that will probably have to do for now. 15:25:04 yeah, if a fix is needed in a particular mer core package in this way could only be done by another repo that would be updates that override whatever is in mer core 15:25:26 notmart: exactly 15:25:51 we'll have to track devel then continuously for such fixes. what's the best way to keep track of such changes (as opposed to the usual feature adjustments)? 15:27:42 * Sage doesn't have really an answer to that atm. 15:29:10 we don't have security mailinglist or similar in mer that would announce found problems. 15:29:37 ok.. so room for improvement in future. and we know what we have to work with for the right here and now. cool. 15:29:54 notmart: does that pretty well sum up the topic for you? 15:30:10 yes, let me try to do a short recap: 15:30:24 we still have to do a static nemo available for you. mer is there already and simple to do 15:31:07 Sage: maybe webhooks can help? 15:31:07 * clone the structure of nemo in the kde project, like kde:stable:nemo:mw etc 15:31:16 (maybe better naming needed) 15:31:55 all that is in kde:stable:* will build against 0.20130411.1 explicitly referred to in the project metadata 15:31:56 notmart: you might not want to do that actually, but to do it similarly to mer. (sry for interruption) 15:32:30 * there will be another project like kde:stable: mercorepatches, initially empty that will have eventual updates for mer core 15:32:50 Sage: similar to mer in which way? 15:32:52 do it similarly to mer? 15:33:42 i.e., we do static nemo snapshot and you do kde:stable:nemopatches containing the patches towards that static nemo snapshot. 15:34:27 ok 15:34:29 ah :) 15:34:37 yes, that makes sense... 15:35:01 Sage: so i can refer to a static nemo snapshot directly in a project metadata to use them as repositories for building? 15:35:28 notmart: yes 15:35:51 ok, that sounds good, less duplicates on obs ;) 15:35:55 :nod: 15:37:06 Sage: any thoughts on when we could expect a first snapshot? 15:37:59 as said mer is there, nemo I can probably do during this week. Should be relatively simple thing to do just need to learn it as we don't have it in mer obs yet 15:38:40 the repo is there i guess? http://releases.nemomobile.org/snapshots/repos/platform/0.20130426.0.1/ 15:39:12 so is not reachable by ob yet? 15:39:33 :nod: need to do download on demand service there that provides the rpm's when obs needs it. 15:40:17 I have some scripts for it and guys who have done it before just matter of doing required modifications and running the stuff. 15:41:56 ok.. that sounds promising then. 15:42:10 Sage: notmart: let's stay in touch over the next week on this item to track progress 15:42:26 I will be in touch during this week if I catch you on IRC ;) 15:42:38 so .. topic 2 ... something more for Stskeeps and zackr .. libhybris and where things are going with that. 15:42:59 zackr: have you had a chance to look at libhybris at all? 15:43:13 Sage: yes, I'm usually around, so either when you are done or if you need something to do it, just shout in my direction ;) 15:43:17 aseigo: code is here but not very publicised yet; you can use mer-next + libhybris to get a working qml compositor + client working 15:43:25 aseigo: still writing blog posts etc to explain the code 15:43:54 here as in, it's in libhybris right now 15:44:15 #topic drivers and libhybris 15:44:55 http://vimeo.com/65513489 is similar setup but without libhybris on AMD radeon tablet 15:45:07 so, it's really foundation work 15:45:09 aseigo: nemo has libhybris packaged already https://build.merproject.org/project/show?project=nemo%3Adevel%3Ahw%3Aandroid%3Acommon just fyi 15:46:30 tested on mali, medfield sgx, intel mesa-android, qualcomm so far 15:46:56 Stskeeps: are you always using it with wayland? 15:47:15 yes, i wouldn't want to wish trying to get it work sanely with libX11 on my worst enemy 15:47:22 it's wayland, or full screen egl 15:47:56 others are using it with webos's special way of doing it, but it comes down to that you need qt5 to work with this sanely 15:48:55 yea, for this configuration that makes sense. so the native window for egl on libhybris becomes some android window buffer handle, right? 15:49:33 from application point of view it's transparent, you use a bog standard wayland plugin for qt; for compositor it's like a mesa configuration (some differences in page flipping) 15:49:42 i have a blog post coming this week explaining all technical concepts 15:49:51 github.com/libhybris/libhybris 15:50:39 check out egl/platforms 15:50:49 great. what's the bottom line? that libhybris simply provides a working egl implementation on top of the android gles drivers? 15:51:12 libhybris basically wraps android gles drivers (and gralloc/framebuffer HAL) to make a sane egl implementation 15:51:21 for wayland usage and full screen rendering 15:51:35 egl/platforms/common fbdev/ and wayland/ are interesting to peek at 15:52:02 it solves the current issue of graphics driver availability, even if it's not the best way (ie, better to support open source drivers), it gets non-android a lot more HW to work and ship on 15:52:14 also solves other driver types, like gps, lights, sensors, etc 15:53:19 yea, we're not going to get stable free software mobile gpu drivers anytime soon, so this is great. 15:53:46 so it should be very good news for PA and other open systems going forward 15:54:05 aseigo: what do you want to do. do you actually want to switch to wayland for the first release? 15:54:57 going from qt4/x11 to qt5/wayland is a bit of a pain, at least 15:56:02 eh, for first release isn't much feasible, for immediate future some kind of workaround is needed.. even if is slow/non accelerated drivers 15:56:13 some x11 drivers do exist right now i think? 15:56:41 bringing up x11 on egl would be... interesting 15:57:21 for mali stuff there's the armsoc driver, except I am not certain if that's completely usable 15:57:21 well, the windowing system capability of libhybris is flexible enough 15:57:27 but it would be a major headache, still 15:57:48 notmart: yes, there are x11 drivers .. 15:57:49 e.g. https://github.com/ssvb/xf86-video-sunxifb 15:57:58 right ^^ 15:58:11 https://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summary < seems to be the most active repo 15:59:16 otoh, when KDE has moved sanely to qt5, hw support is also much more mature.. 15:59:38 with some more info on http://linux-sunxi.org/Binary_drivers 15:59:41 Stskeeps: yes 15:59:48 so if you can do a release/product with x11, perhaps some small libhybris uses (gps, whichever), you're lucky 16:00:23 shadeslayer: not useful in our case afaik 16:00:50 Stskeeps: yes, seems that might be the case. which might make things simpler out of the gate, and then we can work towards the wayland target 16:01:20 zackr: as notmart noted, wayland for v1 is not realistic.. we can look at all of the pieces next week when you're here though 16:01:24 aseigo: so, graphics wise we won't be able to use libhybris for the first release. we'll need to use the old x11 stack 16:01:38 aseigo: oh? I thought you mentioned that one of the GPU's for the porting targets had Mali? 16:03:43 shadeslayer: that driver is for the T6xx, no? we're looking at a device witha 400 16:03:53 ahhhh .... 16:05:08 who knows, maybe it might be possible to re-purpose it for the 400, but i wouldn't know how much effort that would be. that's zackr's domain. among the things we'll be looking at next week 16:06:10 I see 16:07:29 also consider that you might find that many things are much simpler on a qt5/qtquick2/qml compositor setup.. there's definately a lot of stuff that gets easier 16:07:35 ok, that resolves that matter then, i suppose.. Stskeeps: i'm still very interested in being kept abreast on devel of libhybris and will continue to follow it as wayland is a major next target for us 16:07:38 sure 16:07:41 yeah 16:07:53 i would recommend that you have a parallel track that looks into a qt5 based PA 16:08:01 on top of wayland 16:08:04 kwin is being ported to qt5, and then it will hook into wayland via qtcompositor 16:08:20 we do :) 16:08:39 * aseigo was in nürnberg a couple weeks ago with a bunch of guys laying down the next steps in that 16:10:09 one extreme possibility that i've considered, given that we don't really do window manager per-se, is to look into the possibility of a very simple qt5 based compositor with x wayland to drive the apps .. i have no idea what the resource consumption on that woudl be, however .. 16:10:30 could be worse 16:10:35 yes :) 16:10:38 i do wonder how egl inside those work though 16:11:46 if we didn't have so much xlib and qml1 code kicking around it would be easier .. the transition to xcb and qml2 with qt5 that we're having to go through for e.g. kwin is a major blocker to just doing a "recompile it" 16:12:14 ok.. i think that wraps topic 2 for now .. though i'm really happy to have finally introduced zackr and Stskeeps .. you 2 probably have more than a little to chat about if you ever get in a room together 16:12:19 anything else? 16:13:39 aseigo: i think that's it. next week we'll just need to sit down and bring the x11 stack up and if it won't work well enough, then i'll try to figure something out 16:13:52 release wise i'm happy enough. if will be possible to build against one of the nemo snapshots, it's done in 5 minutes 16:13:54 we have options 16:14:15 don't have other topics so far 16:14:43 great :) thanks for everyone's time. 16:16:05 #endmeeting