13:38:21 #startmeeting 13:38:21 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:39:24 I'll start just by updating on what is the situation of the projects on obs right now 13:40:04 we have as root project in buuild.merproject.org kde: 13:40:11 under thatm we have 3 subprojects 13:40:33 kde:devel:mw, kde:devel:ux, kde:devel:us:integration 13:40:45 kde:devel:ux:integration i mean 13:40:59 most important are kde:devel:mw, kde:devel:ux 13:41:45 notmart, ping 13:41:52 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 (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 rcg: hey 13:43:35 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 all repos build for i586, armv7l armv7hl 13:44:15 so, topic is on organizing repos on bmo? 13:44:24 rcg: yes 13:44:29 good :) 13:45:10 as-in, "good to know what's going on" :) 13:45:18 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 rcg: do you have backlog? 13:45:28 i see 13:45:31 nope 13:45:34 pong 13:45:35 sry 13:45:48 sry I'm late 13:46:04 notmart: what is kde:devel:ux:integration used for? 13:46:06 rcg: here: http://paste.opensuse.org/7439221 13:46:34 Sage_: is a peculiarity of a couple of the git repos we work on 13:46:35 notmart, thx 13:46:36 ah, sry reading a bit slowly 13:47:16 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 notmart: well for nemo :devel: will be the place where stuff from git is automatically pushed 13:47:52 and maintainer will promote from :devel: to :testing: after the changes have been tested properly 13:48:01 (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 Sage_: yes, that's done in the git part, basically only one maintainer merges feature branches into master 13:48:30 notmart: ok 13:48:53 then when they are in master, continuous integration picks it up and they will appear in kde:devel:ux 13:49:28 right now we have exactly one package (plasma-mobile) on this regime, but more should come 13:49:28 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 yes, totally 13:50:03 those 15-20 were just after a quick glance or you have a list? 13:50:21 yes quick glance based on memory and package names :) 13:50:40 ok 13:50:46 moment I can do another list. 13:52:21 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 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 notmart: if newer version you should submit to mer or nemo mw so we keep the effort the same 13:53:42 telepathy-mission-control needs support for connman and networkmanager 13:53:52 is that possible? 13:54:19 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 Sage_, sure 13:54:56 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 just mentioning this as some sort of heads up :) 13:55:29 of course having just one telepathy-mc would be better than having to compile it two times 13:55:35 notmart: http://www.freedesktop.org/wiki/Software/ConsoleKit based on this yes :) 13:56:11 rcg: I agree on that yes 13:56:51 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 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 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 Sage_: so, ne thing to do still is to remove some of the mw packages, 13:59:26 instead, is in general the structure of the projects correct now? 13:59:37 I think it is ok now 13:59:37 as in name of the repos, targets etc? 13:59:49 they arenow all called latest_architecture 13:59:51 moment rechecking 13:59:51 oki 14:00:34 yes looks good 14:00:38 cool 14:02:47 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 then after it packages would go from devel to testing etc one by one when ready 14:04:42 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 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 not for packages no 14:05:44 i.e., I'm currently doing napshots from :testing: level atm. which end up to http://releases.nemomobile.org/snapshots/repos/ 14:05:56 there is also stuff to improve there 14:06:12 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 ok 14:07:47 so: two actions: removing some duplicate from mw, then doing testing: 14:08:08 #action as less duplicate as possible between nemo:mw and kde:mw 14:08:15 #action create kde:testing 14:09:04 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 nexus 7 adaptation is there already 14:09:33 so, there is already an hw adaptation for nexus7 i think.. 14:09:45 that's awesome 14:09:46 yes, it need cleanup but it should work already 14:10:01 also with respect to the nexus 7 one, kulve is doing a lot of work on that one as well 14:10:06 kulve at #nemomobile is at least working iwth it. 14:10:28 rcg: your work on nexus tough had also other device specific modifications besids just purely hardware adaptations iirc? 14:10:52 we, e.g., pushed a patched version of phonon 14:11:14 but i just checked and saw that this is in nemo mw already 14:11:19 where a thing like that would go in theory? 14:11:19 hi , just for heads-up, telepathy-mission-control is build in a different way 14:11:27 i think kulve still has a patched version of qtmobility in the hw adaptation 14:12:04 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 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 telepathy-mission-control uses NetworkManger instead of connman as backend 14:12:36 notmart, iirc there is still a patched ModemManager for nexus 7 14:12:53 rcg: that should go to kde:devel:mw 14:13:13 Sage_, well, the patch is very nexus 7 specific 14:13:24 it's a pretty quick and even more dirty hack 14:13:40 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 rcg: well it should still not be in the adaptation repo 14:14:07 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 Sage_, sure 14:14:23 lets not try to solve all package details here. 14:14:30 rcg: I tried but it does not work 14:14:38 mdfe, :/ 14:15:08 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 would that be ok? 14:15:16 to me it seems that there culd be needs for repos that adapts for hardware thngs of "higher" level 14:15:58 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 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 Sage_, agreed, am not sure if branching code paths based on environment variable is a clean solution 14:17:31 notmart: if you talk about theming and stuff that is something that isn't adaptation thing but just configuration 14:17:41 i.e., what theme to pick and what applications to install 14:18:37 actually, the best solution would be to somehow push that patch upstream to modemmanager 14:18:55 rcg: yes 14:19:04 but i am by far too much occupied with other things right now as to look into that one :/ 14:19:35 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 Sage_, i see 14:20:59 ok, so this in particular seems still an open problem 14:21:12 if we fork/branch any packages from core or mw to adaptation that will bring huge amount of new issues 14:21:19 so the environment variable thing could be a trade-off to get the change into mw 14:22:22 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 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 Sage_, agreed 14:23:35 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 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 others just fork fork fork instead of think proper fix. 14:25:49 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 sorry brb 14:26:40 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 yeah 14:27:14 notmart: what is open problem? 14:27:45 was just trying to make the point of the suituation. 14:27:48 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 ie if we have an agreement right now 14:28:02 I think we have :) 14:28:02 or defer to furter discussion 14:28:18 ok, perfect 14:28:46 Sage_: about the configuration, no i agree they are a separated thng from the adaptation 14:29:05 probably often will be enough a difference in the kickstart 14:29:13 sometimes a package/repo could be needed 14:29:59 Sage_, sorry, am busy right now.. but i fully agree that we should do things properly 14:30:09 but that would be of course completely different from the adaptation repo 14:30:45 unfortunately since i mis-scheduled things i'll have to run in a while too 14:30:52 notmart: .ks file is usually the configuration. i.e, what apps to include and what themes etc. 14:31:03 we can reschedule :) 14:31:12 also I'm often in IRC 14:31:29 so you can just ping me :) 14:31:51 well, i think we can close it for this time... 14:32:00 there is already a bit of work to do 14:32:24 and make again the point of the situation either next time (like same hour/place) 14:32:41 or for any doubt just ping each other on irc whenever needed 14:33:37 there is some things that can be done now in a straightforward way 14:34:20 others that will need a bit more thinking (like telepathy and packagekit using networkmanager vs cnnman, or the modemmanager patches) 14:34:35 Sage_, rcg: other to add for today? 14:35:49 re 14:36:50 looks good to me 14:38:14 ok, so we make again the point of the situation next tuesday, same time 14:38:24 or any clarification in the middle with irc/mailinglists 14:38:26 not much from me 14:38:40 ok 14:38:42 #endmeeting