15:11:18 <notmart> #startmeeting
15:11:18 <Merbot`> 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 <Merbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:11:37 <notmart> ok, so let's start
15:12:00 <notmart> #topic stable releases
15:13:11 <Sage> Ok, can you start by describing the need?
15:13:18 <notmart> 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 <notmart> but that will still be possible to make updates o them
15:14:32 <notmart> 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 <Sage> that we have already
15:15:08 <notmart> then all that depends from it would as well be stable (so mer core, nemo:* kde:*)
15:15:23 <Stskeeps> o/
15:16:13 <Sage> 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 <Sage> 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 <notmart> ok, so snapshots of all the needed nemo projects under kde?
15:17:06 <shadeslayer> notmart: would it be favorable to also have a Kubuntu + Plasma Active image ?
15:17:38 <notmart> shadeslayer: if somebody does that he's welcome
15:17:46 <shadeslayer> ack
15:17:49 <notmart> kinda ot right now tough
15:17:52 <shadeslayer> yeah
15:18:08 <notmart> and that gives adaptations and nemo:mw a "stable" state
15:18:25 <Sage> Can we keep this only about mer+nemo? And leave Kubuntu out as it would be totally different topic?
15:18:31 <notmart> what about the mer part?
15:18:37 <shadeslayer> Sage: roger
15:18:52 <notmart> is it possible to build agains a determined release even if is not latest?
15:19:05 <Sage> notmart: yes
15:19:09 <Sage> notmart: let me give example
15:19:43 <Sage> notmart: http://pastie.org/7818437
15:20:07 <Sage> there everything is bulid against static mer releases and it is already available in mer obs.
15:20:28 <Sage> it changes only when someone changes the project config
15:21:03 <aseigo> that's more of a release tag than a stable version?
15:21:09 <notmart> ok, so as long a release stays on http://releases.merproject.org/releases/ it will be available from there
15:22:27 <notmart> 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 <Sage> 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 <aseigo> 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 <aseigo> right... ok.
15:24:27 <Sage> 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 <Stskeeps> btw, also note that we now use mds2 which allows to lock on binary releases much easier
15:24:58 <aseigo> not particularl optimal, but that will probably have to do for now.
15:25:04 <notmart> 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 <Sage> notmart: exactly
15:25:51 <aseigo> 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 <Sage> we don't have security mailinglist or similar in mer that would announce found problems.
15:29:37 <aseigo> 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 <aseigo> notmart: does that pretty well sum up the topic for you?
15:30:10 <notmart> yes, let me try to do a short recap:
15:30:24 <Sage> we still have to do a static nemo available for you. mer is there already and simple to do
15:31:07 <Stskeeps> Sage: maybe webhooks can help?
15:31:07 <notmart> * clone the structure of nemo in the kde project, like kde:stable:nemo:mw etc
15:31:16 <notmart> (maybe better naming needed)
15:31:55 <notmart> all that is in kde:stable:* will build against 0.20130411.1 explicitly referred to in the project metadata
15:31:56 <Sage> notmart: you might not want to do that actually, but to do it similarly to mer. (sry for interruption)
15:32:30 <notmart> * there will be another project like kde:stable: mercorepatches, initially empty that will have eventual updates for mer core
15:32:50 <aseigo> Sage: similar to mer in which way?
15:32:52 <notmart> do it similarly to mer?
15:33:42 <Sage> i.e., we do static nemo snapshot and you do kde:stable:nemopatches containing the patches towards that static nemo snapshot.
15:34:27 <notmart> ok
15:34:29 <aseigo> ah :)
15:34:37 <aseigo> yes, that makes sense...
15:35:01 <notmart> 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 <Sage> notmart: yes
15:35:51 <notmart> ok, that sounds good, less duplicates on obs ;)
15:35:55 <Sage> :nod:
15:37:06 <aseigo> Sage: any thoughts on when we could expect a first snapshot?
15:37:59 <Sage> 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 <notmart> the repo is there i guess? http://releases.nemomobile.org/snapshots/repos/platform/0.20130426.0.1/
15:39:12 <notmart> so is not reachable by ob yet?
15:39:33 <Sage> :nod: need to do download on demand service there that provides the rpm's when obs needs it.
15:40:17 <Sage> 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 <aseigo> ok.. that sounds promising then.
15:42:10 <aseigo> Sage: notmart: let's stay in touch over the next week on this item to track progress
15:42:26 <Sage> I will be in touch during this week if I catch you on IRC ;)
15:42:38 <aseigo> so .. topic 2 ... something more for Stskeeps and zackr  .. libhybris and where things are going with that.
15:42:59 <aseigo> zackr: have you had a chance to look at libhybris at all?
15:43:13 <notmart> 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 <Stskeeps> 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 <Stskeeps> aseigo: still writing blog posts etc to explain the code
15:43:54 <Stskeeps> here as in, it's in libhybris right now
15:44:15 <notmart> #topic drivers and libhybris
15:44:55 <Stskeeps> http://vimeo.com/65513489 is similar setup but without libhybris on AMD radeon tablet
15:45:07 <Stskeeps> so, it's really foundation work
15:45:09 <Sage> aseigo: nemo has libhybris packaged already https://build.merproject.org/project/show?project=nemo%3Adevel%3Ahw%3Aandroid%3Acommon just fyi
15:46:30 <Stskeeps> tested on mali, medfield sgx, intel mesa-android, qualcomm so far
15:46:56 <zackr> Stskeeps: are you always using it with wayland?
15:47:15 <Stskeeps> yes, i wouldn't want to wish trying to get it work sanely with libX11 on my worst enemy
15:47:22 <Stskeeps> it's wayland, or full screen egl
15:47:56 <Stskeeps> 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 <zackr> 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 <Stskeeps> 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 <Stskeeps> i have a blog post coming this week explaining all technical concepts
15:49:51 <Stskeeps> github.com/libhybris/libhybris
15:50:39 <Stskeeps> check out egl/platforms
15:50:49 <zackr> great. what's the bottom line? that libhybris simply provides a working egl implementation on top of the android gles drivers?
15:51:12 <Stskeeps> libhybris basically wraps android gles drivers (and gralloc/framebuffer HAL) to make a sane egl implementation
15:51:21 <Stskeeps> for wayland usage and full screen rendering
15:51:35 <Stskeeps> egl/platforms/common fbdev/ and wayland/ are interesting to peek at
15:52:02 <Stskeeps> 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 <Stskeeps> also solves other driver types, like gps, lights, sensors, etc
15:53:19 <zackr> yea, we're not going to get stable free software mobile gpu drivers anytime soon, so this is great.
15:53:46 <Stskeeps> so it should be very good news for PA and other open systems going forward
15:54:05 <zackr> aseigo: what do you want to do. do you actually want to switch to wayland for the first release?
15:54:57 <Stskeeps> going from qt4/x11 to qt5/wayland is a bit of a pain, at least
15:56:02 <notmart> 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 <notmart> some x11 drivers do exist right now i think?
15:56:41 <zackr> bringing up x11 on egl would be... interesting
15:57:21 <shadeslayer> for mali stuff there's the armsoc driver, except I am not certain if that's completely usable
15:57:21 <Stskeeps> well, the windowing system capability of libhybris is flexible enough
15:57:27 <Stskeeps> but it would be a major headache, still
15:57:48 <aseigo> notmart: yes, there are x11 drivers ..
15:57:49 <aseigo> e.g. https://github.com/ssvb/xf86-video-sunxifb
15:57:58 <shadeslayer> right ^^
15:58:11 <shadeslayer> 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 <Stskeeps> otoh, when KDE has moved sanely to qt5, hw support is also much more mature..
15:59:38 <aseigo> with some more info on http://linux-sunxi.org/Binary_drivers
15:59:41 <aseigo> Stskeeps: yes
15:59:48 <Stskeeps> so if you can do a release/product with x11, perhaps some small libhybris uses (gps, whichever), you're lucky
16:00:23 <aseigo> shadeslayer: not useful in our case afaik
16:00:50 <aseigo> 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 <aseigo> 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 <zackr> 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 <shadeslayer> aseigo: oh? I thought you mentioned that one of the GPU's for the porting targets had Mali?
16:03:43 <aseigo> shadeslayer: that driver is for the T6xx, no? we're looking at a device witha 400
16:03:53 <shadeslayer> ahhhh ....
16:05:08 <aseigo> 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 <shadeslayer> I see
16:07:29 <Stskeeps> 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 <aseigo> 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 <Stskeeps> sure
16:07:41 <aseigo> yeah
16:07:53 <Stskeeps> i would recommend that you have a parallel track that looks into a qt5 based PA
16:08:01 <Stskeeps> on top of wayland
16:08:04 <aseigo> kwin is being ported to qt5, and then it will hook into wayland via qtcompositor
16:08:20 <aseigo> 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 <aseigo> 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 <Stskeeps> could be worse
16:10:35 <aseigo> yes :)
16:10:38 <Stskeeps> i do wonder how egl inside those work though
16:11:46 <aseigo> 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 <aseigo> 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 <aseigo> anything else?
16:13:39 <zackr> 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 <notmart> 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 <zackr> we have options
16:14:15 <notmart> don't have other topics so far
16:14:43 <aseigo> great :) thanks for everyone's time.
16:16:05 <notmart> #endmeeting