13:38:21 <notmart> #startmeeting
13:38:21 <Merbot`> Meeting started Tue Mar 26 13:38:21 2013 UTC.  The chair is notmart. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
13:38:21 <Merbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:39:24 <notmart> I'll start just by updating on what is the situation of the projects on obs right now
13:40:04 <notmart> we have as root project in buuild.merproject.org kde:
13:40:11 <notmart> under thatm we have 3 subprojects
13:40:33 <notmart> kde:devel:mw, kde:devel:ux, kde:devel:us:integration
13:40:45 <notmart> kde:devel:ux:integration i mean
13:40:59 <notmart> most important are kde:devel:mw, kde:devel:ux
13:41:45 <rcg> notmart, ping
13:41:52 <notmart> as in, kde:devel:mw for extra dependencies (hope we can drop some other packages from there, still) and kde:devel:ux being things that come from the kde repos
13:42:19 <notmart> (some vould eventually go into kde:devel:apps or something in the future, but i would say keep it simple for now)
13:42:22 <notmart> rcg: hey
13:43:35 <notmart> kde:devel:us:integration is just a reflection of the workflow in git, and is meant to contain packages from kde repos that have an "integration" git branch, is kinda an "even more devel" and will be there only for the devel stage
13:44:07 <notmart> all repos build for i586, armv7l armv7hl
13:44:15 <rcg> so, topic is on organizing repos on bmo?
13:44:24 <notmart> rcg: yes
13:44:29 <rcg> good :)
13:45:10 <rcg> as-in, "good to know what's going on" :)
13:45:18 <notmart> rcg: i was just doing a quick recap on how the structure is in bmo right now, so then if there is something that needs to be changed is easy to point out
13:45:27 <notmart> rcg: do you have backlog?
13:45:28 <rcg> i see
13:45:31 <rcg> nope
13:45:34 <Sage_> pong
13:45:35 <Sage_> sry
13:45:48 <Sage_> sry I'm late
13:46:04 <Sage_> notmart: what is kde:devel:ux:integration used for?
13:46:06 <notmart> rcg: here: http://paste.opensuse.org/7439221
13:46:34 <notmart> Sage_: is a peculiarity of a couple of the git repos we work on
13:46:35 <rcg> notmart, thx
13:46:36 <Sage_> ah, sry reading a bit slowly
13:47:16 <notmart> basically we have a git branch called integration in which all the feature branches go to be tested and be merged into master only afterwards
13:47:24 <Sage_> notmart: well for nemo :devel: will be the place where stuff from git is automatically pushed
13:47:52 <Sage_> and maintainer will promote from :devel: to :testing: after the changes have been tested properly
13:48:01 <notmart> (and we have an ui to add that repo so if one wants to test all not yet finished features can enable it in the device)
13:48:30 <notmart> Sage_: yes, that's done in the git part, basically only one maintainer merges feature branches into master
13:48:30 <Sage_> notmart: ok
13:48:53 <notmart> then when they are in master, continuous integration picks it up and they will appear in kde:devel:ux
13:49:28 <notmart> right now we have exactly one package (plasma-mobile) on this regime, but more should come
13:49:28 <Sage_> I gave already some feedback on the :mw content about duplicated packages we should go those through. I think there was something like 15-20 packages that area already merged to Mer or Nemo mw that you use as well.
13:49:42 <notmart> yes, totally
13:50:03 <notmart> those 15-20 were just after a quick glance or you have a list?
13:50:21 <Sage_> yes quick glance based on memory and package names :)
13:50:40 <notmart> ok
13:50:46 <Sage_> moment I can do another list.
13:52:21 <notmart> iirc there was only one that was actually needed to be compiled differently that was packagekit, the rest of duplication was just either packages not yet in mw or newer versions
13:53:04 <Sage_> ConsoleKit (obsoleted by systemd something iirc), PackageKit (in nemo mw), alsa-plugins (in mer core), boost (in mer core), grubby (adaptation package), mtdev (in mer core), newt (adaptation), slang (adaptation?), taglib (in nemo mw), telepathy-mission-control (in nemo mw), upower (in mer core), uboot-mkimage (adaptation), xorg-x11-drv-mtev (in mer core), xorg-x11-drv-omapfb (adaptatoin)
13:53:32 <Sage_> notmart: if newer version you should submit to mer or nemo mw so we keep the effort the same
13:53:42 <rcg> telepathy-mission-control needs support for connman and networkmanager
13:53:52 <rcg> is that possible?
13:54:19 <Sage_> rcg: well there are some things where we need to look more closely. I just based this on package names not functionality or content
13:54:39 <rcg> Sage_, sure
13:54:56 <notmart> i'm not sure if with the minimum systemd user session support we have polkit works already without consolekit, should need to be tested
13:55:00 <rcg> just mentioning this as some sort of heads up :)
13:55:29 <rcg> of course having just one telepathy-mc would be better than having to compile it two times
13:55:35 <Sage_> notmart: http://www.freedesktop.org/wiki/Software/ConsoleKit based on this yes :)
13:56:11 <Sage_> rcg: I agree on that yes
13:56:51 <notmart> things that can be removed i think right away: alsa-plugins, boost (iirc was a bugfix that was then submitted to mer-core) grubby, mtdev, upower, taglib, slang, newt, uboot-mkimage, xorg-x11-*
13:57:54 <notmart> yes, packagekit was the same reason of telepathy, the only way to chose between connman and networkmanager is still only at compile time in an exclusive way
13:59:13 <rcg> notmart, for telepathy-mc there is also an "auto" setting iirc... but i dunno if that compiles support for both to choose at runtime or if it does some autodetection thingie at compile time
13:59:14 <notmart> Sage_: so, ne thing to do still is to remove some of the mw packages,
13:59:26 <notmart> instead, is in general the structure of the projects correct now?
13:59:37 <Sage_> I think it is ok now
13:59:37 <notmart> as in name of the repos, targets etc?
13:59:49 <notmart> they arenow all called latest_architecture
13:59:51 <Sage_> moment rechecking
13:59:51 <notmart> oki
14:00:34 <Sage_> yes looks good
14:00:38 <notmart> cool
14:02:47 <notmart> so then when this is ok (after removing some mw stuff) to do the testing and release stages would be just a copy of the current structure? (even devel in reality is frozen at the moment, to be able to do a release eventually)
14:03:11 <notmart> then after it packages would go from devel to testing etc one by one when ready
14:04:42 <Sage_> well doing testing stage is probably enough atm. and use that as the release as you don't probably have automated testing or anything atm.
14:05:08 <Sage_> nemo isn't using the 'stable' either atm. just because we don't have automation there in place which will take some time
14:05:10 <notmart> not for packages no
14:05:44 <Sage_> i.e., I'm currently doing napshots from :testing: level atm. which end up to http://releases.nemomobile.org/snapshots/repos/
14:05:56 <Sage_> there is also stuff to improve there
14:06:12 <notmart> we'll probably keep for a while to send packages in stable only for mayor releases and bugfixes of them, while usually keeping those packages as fixed and alsone as possible all the time
14:07:22 <notmart> ok
14:07:47 <notmart> so: two actions: removing some duplicate from mw, then doing testing:
14:08:08 <notmart> #action as less duplicate as possible between nemo:mw and kde:mw
14:08:15 <notmart> #action create kde:testing
14:09:04 <notmart> another thing i wanted to quickly discuss (and here have to see if/how much rcg can help) is about archos and nexus adaptations
14:09:28 <Sage_> nexus 7 adaptation is there already
14:09:33 <notmart> so, there is already an hw adaptation for nexus7 i think..
14:09:45 <notmart> that's awesome
14:09:46 <Sage_> yes, it need cleanup but it should work already
14:10:01 <rcg> also with respect to the nexus 7 one, kulve is doing a lot of work on that one as well
14:10:06 <Sage_> kulve at #nemomobile is at least working iwth it.
14:10:28 <notmart> rcg: your work on nexus tough had also other device specific modifications besids just purely hardware adaptations iirc?
14:10:52 <rcg> we, e.g., pushed a patched version of phonon
14:11:14 <rcg> but i just checked and saw that this is in nemo mw already
14:11:19 <notmart> where a thing like that would go in theory?
14:11:19 <mdfe> hi , just for heads-up, telepathy-mission-control is build in a different way
14:11:27 <rcg> i think kulve still has a patched version of qtmobility in the hw adaptation
14:12:04 <Sage_> I'm starting to watch these things more carefully now and pointing people the right places. Just to make sure adaptation stay only adapations and don't fork too much stuff
14:12:10 <rcg> notmart, for the phonon thing, our solution was to use an environment variable and choose code paths based on that one at runtime
14:12:31 <mdfe> telepathy-mission-control uses NetworkManger instead of connman as backend
14:12:36 <rcg> notmart, iirc there is still a patched ModemManager for nexus 7
14:12:53 <Sage_> rcg: that should go to kde:devel:mw
14:13:13 <rcg> Sage_, well, the patch is very nexus 7 specific
14:13:24 <rcg> it's a pretty quick and even more dirty hack
14:13:40 <notmart> mdfe: yeah, same thing for packagekit, those that can't switch at runtime but need to be built differently will have to stay there i think
14:13:41 <Sage_> rcg: well it should still not be in the adaptation repo
14:14:07 <rcg> mdfe, do you know of the top of your head if it is possible to build telepathy-mc with support for both connman and nm and let it figure out what to choose at runtime?
14:14:21 <rcg> Sage_, sure
14:14:23 <Sage_> lets not try to solve all package details here.
14:14:30 <mdfe> rcg: I tried but it does not work
14:14:38 <rcg> mdfe, :/
14:15:08 <rcg> Sage_, with respect to the modemmanager hack, we could use a similar approach as for phonon and use an environment variable to decide which codepath to use
14:15:13 <rcg> would that be ok?
14:15:16 <notmart> to me it seems that there culd be needs for repos that adapts for hardware thngs of "higher" level
14:15:58 <Sage_> rcg: well, only thing that should be in n7 repo is configration or plugin for modemmanager (if it can have plugins) but modemmanager itself should be elsewhere
14:16:03 <notmart> of packages (such as even just configuration) that do belong only to a particular device but don't belong to an hw: adaptation because from the wrong "level"
14:17:03 <rcg> Sage_, agreed, am not sure if branching code paths based on environment variable is a clean solution
14:17:31 <Sage_> notmart: if you talk about theming and stuff that is something that isn't adaptation thing but just configuration
14:17:41 <Sage_> i.e., what theme to pick and what applications to install
14:18:37 <rcg> actually, the best solution would be to somehow push that patch upstream to modemmanager
14:18:55 <Sage_> rcg: yes
14:19:04 <rcg> but i am by far too much occupied with other things right now as to look into that one :/
14:19:35 <Sage_> rcg: same thing with nemo we don't fork/branch any mw components in the adaptations. If there is need for some kind of configuration we need to make the mw component configurable for different hw
14:20:27 <rcg> Sage_, i see
14:20:59 <notmart> ok, so this in particular seems still an open problem
14:21:12 <Sage_> if we fork/branch any packages from core or mw to adaptation that will bring huge amount of new issues
14:21:19 <rcg> so the environment variable thing could be a trade-off to get the change into mw
14:22:22 <Sage_> lets say you have qt-mobility version X in mer core, and you fork it to adaptatoin so qt-mobility version X there +patch. Then qt-mobility updates in mer core to version X+1 and suddently your device breaks because newer version is available in core and you have still old fork/branch in adaptation
14:22:47 <Sage_> this introduces a _huge_ maintenance burden for adaptation maintainer as he needs to constantly watch that version is in sync and stuff rebased on every update.
14:23:00 <rcg> Sage_, agreed
14:23:35 <Sage_> which means you adaptation can suddently break without you even noticing it properly. Thus, no forks of mw/core packages in adaptation pretty please ;)
14:24:20 <Sage_> yes there is need for doing new features to some of the mw at times because of this but you are not always the only one needing the feature
14:24:34 <Sage_> others just fork fork fork instead of think proper fix.
14:25:49 <Sage_> Issues with any of the stuff? Please bring it up and ping me about it and lets see how to solve it.
14:26:30 <rcg> sorry brb
14:26:40 <Sage_> IMO Mer Core has been working very nicely so far in this matter of keeping adaptations out of the core and we should try to make it be so for mw/ux/apps etc.
14:27:07 <notmart> yeah
14:27:14 <Sage_> notmart: what is open problem?
14:27:45 <notmart> was just trying to make the point of the suituation.
14:27:48 <Sage_> notmart: can you also ellaborate a bit more on the configuration issue you see? What needs configuration etc. We should make sure we define two separate things configuration and hw adaptation.
14:27:55 <notmart> ie if we have an agreement right now
14:28:02 <Sage_> I think we have :)
14:28:02 <notmart> or defer to furter discussion
14:28:18 <notmart> ok, perfect
14:28:46 <notmart> Sage_: about the configuration, no i agree they are a separated thng from the adaptation
14:29:05 <notmart> probably often will be enough a difference in the kickstart
14:29:13 <notmart> sometimes a package/repo could be needed
14:29:59 <rcg> Sage_, sorry, am busy right now.. but i fully agree that we should do things properly
14:30:09 <notmart> but that would be of course completely different from the adaptation repo
14:30:45 <notmart> unfortunately since i mis-scheduled things i'll have to run in a while too
14:30:52 <Sage_> notmart: .ks file is usually the configuration. i.e, what apps to include and what themes etc.
14:31:03 <Sage_> we can reschedule :)
14:31:12 <Sage_> also I'm often in IRC
14:31:29 <Sage_> so you can just ping me :)
14:31:51 <notmart> well, i think we can close it for this time...
14:32:00 <notmart> there is already a bit of work to do
14:32:24 <notmart> and make again the point of the situation either next time (like same hour/place)
14:32:41 <notmart> or for any doubt just ping each other on irc whenever needed
14:33:37 <notmart> there is some things that can be done now in a straightforward way
14:34:20 <notmart> others that will need a bit more thinking (like telepathy and packagekit using networkmanager vs cnnman, or the modemmanager patches)
14:34:35 <notmart> Sage_, rcg: other to add for today?
14:35:49 <rcg> re
14:36:50 <rcg> looks good to me
14:38:14 <notmart> ok, so we make again the point of the situation next tuesday, same time
14:38:24 <notmart> or any clarification in the middle with irc/mailinglists
14:38:26 <Sage_> not much from me
14:38:40 <notmart> ok
14:38:42 <notmart> #endmeeting