09:30:42 #startmeeting Qt5 integration meeting 27/2/2012 09:30:42 Meeting started Mon Feb 27 09:30:42 2012 UTC. The chair is Stskeeps. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 09:30:42 Useful Commands: #action #agreed #help #info #idea #link #topic. 09:30:58 should we give ahma a moment to show? 09:31:38 sure - Bostik was calling him 09:31:51 I've tried to get to him, he's MIA but according to build logs he has worked on Qt5 during the weekend 09:32:15 alright.. perhaps i can just introduce what i hope to see from architectual side 09:32:55 the idea is that for the while being, Qt4 is default 'qt' in Mer, with qt5 co-existing and applications able to build against it by specifying it directly 09:33:03 such as pkgconfig(QtCore) >= 4.8.0 09:33:35 in Mer core itself there is very little stuff that actually uses qt itself, such as qt mobility, qt webkit, sensorfw, poppler-qt, contextkit, qjson 09:33:45 i'm not expecting those to be converted or using qt5 at this moment 09:34:25 longer term are we supporting both 4.8 and 5 ? 09:34:36 I can see that being needed 09:34:39 we'll have to see how the situation looks like, qt5 is not finally released in any way yet 09:34:50 4.8 can be supported in reverse way of how we allow qt5 to co-exist 09:35:12 i'm suffering quite bad packet loss atm.. will try paritcipate though 09:35:14 aye, the only truly conflicting parts are the -devel packages 09:35:28 have you had any problems noticed so far? 09:35:41 like, specific examples we need to be vary of 09:35:47 as *.pc and the naked .so symlinks are going to be the same 09:35:59 >= 4.8.0 is a bit painful - what happens when i integrate 4.8.1? (aimed to be released quite soon) 09:36:00 :nod: 09:36:28 w00t: well, for now, we do it with >= 5.0, ie, specifically indicate we need to use qt5 09:36:36 ok, that's fine 09:36:39 and Prefer: those packages 09:36:52 Bostik: right, so we have to avoid those getting mixed 09:37:12 so conflicts? 09:37:23 qjson might be droppable in the long term (as qt5 has its own json handling) 09:37:27 and for the time being, all the packages belonging to qt5 have been prefixed with "qt5-" in any case, meaning that the package requirements will be explicit 09:38:30 will a device be able to run qt4 and qt5 apps concurrently? 09:38:47 as long as they don't install devel headers, i would assume so 09:38:54 due to so-names being different 09:39:04 yes 09:39:05 just making our requirements explicit 09:39:13 I wish ahma was here, because the first logical transition step would be to add Provides: fields to match a versioned qt according the used naming convention 09:39:24 i run 4/5 on my desktop, so i don't see why not 09:39:37 w00t: indeed it's normal there 09:40:21 and there will be a period of transition required.. it isn't a straightforward jump 09:40:26 all the other paths (AFAIK) for qt5 are versioned; internal library and module paths are %{_libdir}/qt5/... and private development headers are in fully annotated paths 09:41:21 I won't make absolute guarantees about that, since we haven't so far tried to run the two versions in parallel 09:41:25 :nod: 09:41:27 worth checking 09:41:48 mostly due to qt5 being somewhat broken and in, not long ago, in heavy flux 09:42:10 ahma just woke up 09:42:20 other things.. qt has a releasing@ mailing list which qt5 maintainer should be on -- and we should sync with whatever naming they come up with for qt5 based rpm systems, such as QtOnPi, as to make it easier to transfer source packaging across distributions 09:42:37 aye 09:42:46 so we should rely on pkgconfig() as much as we can 09:43:34 ok, on a local connection now, so hopefully a bit less lagtastic 09:43:39 do we handle CI of Qt integration differently? thinking testing 09:43:51 I'm on the releasing list, so far it has been rather quiet 09:43:58 ahma: http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-02-27-09.30.log.txt to catch up 09:44:05 Jello 09:44:39 so, infra.. i think we can start out by a OBS project on community OBS where we have the packaging in it at first, with a goal to start including it into mer core (i can provide MDS git repos for this) 09:45:05 so when we have a working snapshot and proven additional prjconf items, we can add it to mer core 09:45:58 in longer term, we might want to run test cases of qt5 as well as part of the mer core CI 09:46:10 *nod* 09:46:24 is Qt5 packaging more modular? 09:46:35 yes, *very much* 09:46:52 would be nice to have a page on the wiki with links 09:46:54 this can be positive and negative, as the snapshots are usually in lockstep 09:47:05 and mer specific pages 09:47:21 qt5/modular-qt-specs% git grep -E '^%package' | wc -l 09:47:21 96 09:47:22 http://wiki.merproject.org/wiki/Category:About 09:47:36 we should start a 'Qt5' wiki page 09:47:44 Bostik: ok - but still a monolithic tarball ? 09:47:50 good heavens no 09:48:06 ahma took my packaging specwork as his baselin 09:48:09 you say that like we haven't had X years of then :) 09:48:16 lbt: qtbase, qtdeclarative, qttools, are seperate source packages/tarballs now 09:48:23 tar structure is modularized 09:48:26 and I've not looked at the git recently :) 09:48:39 excellent ... my workers will be happy :) 09:48:53 this is the baseline: https://gitorious.org/modular-qt-specwork/modular-qt-specs 09:48:55 (sounds like I need a bwaahahaha) 09:49:05 though they assume builds are monolithic ;) 09:49:27 ahma has done some pretty neat tuning on top of that over the weekend, I see 09:49:57 since several of the packages (starting from qtbase) are now going through and producing packages again 09:50:41 lbt: can we get a Mer:Qt5 repository on COBS? 09:50:46 and are we moving this work to the MeeGo c.obs 09:50:53 we can 09:51:26 Bostik: need couple of days to clean up the rest, but yes 09:51:44 goody 09:51:55 is it reasonable that we start having qt5 within a mer prerelease in 2 weeks? 09:51:59 +timeframe 09:52:13 that can run qml2 demos 09:52:39 ahma: when you move to c.obs we need to look at worker allocation - can you make a note 09:53:01 otherwise you may be blocked to worker4 only 09:53:30 Stskeeps: in mer-core/ ? 09:53:33 good to know, I'll make some noise when I'll move the integration effort there 09:53:44 lbt: right 09:54:14 just trying to get some kind of feel of the timeframe we're talking here of effort 09:55:52 (and what ahma and bostik thinks is reasonable / ahma's allocation to this work) 09:56:45 it varies 09:57:20 ahma should have the best guess as to how long it will take for him to sort out the remaining packaging errors 09:57:22 i'll help handholding a bit when it comes to mer-core processes and perhaps OBS project configuration stuff, at least 09:57:33 I should have time this week to finalize the packaging round, document the process into wiki and upload initial source to cobs 09:58:38 assuming there are no more potholes (bwaahaha?) :) 09:58:41 if there are any really freaky packaging problems I can have a look if needed 09:58:59 :nod: 09:59:08 should we have a meeting around this time next week too to sync again? 09:59:08 I've mucked about in the qt5 sources long enough to have a fairly good idea what kinds of errors can crop up 09:59:34 the worst offender by far is the abuse of DESTDIR macro 10:00:02 Stskeeps: I was wondering about that - maybe getting a list of "when this is done we're good" 10:00:28 hopefully "when the obs monitor page is green we're finished" :D 10:00:42 all of the appearances I know should have patches in our packaging rules, but I fear new ones may come up at any time depending on what happens upstream 10:00:43 so, i'm only admitting stuff to mer core that builds and installs, naturally ;) 10:01:10 so, task list.., please note if you disagree 10:01:11 to what extent are we pulling from upstream over the next 2 weeks ? 10:01:46 lbt, ahma: I would prefer to have the packaging updated to what ahma currently has in use, and then synced against upstream once more 10:01:47 what I mean is .. are problems being resolved upstream or does that introduce too much churn 10:01:56 yeah - thought so Bostik 10:02:03 just in case they broke something *again* 10:02:39 so we stay isolated until it works, possibly taking a peek upstream and cherry picking if we think there's a solution to be found 10:02:49 then after that we re-sync 10:04:05 aye 10:04:09 sounds reasonable 10:04:21 so, tasks list: Mer:Qt5 project on COBS, packaging round, wiki process on wiki.merproject/wiki, upload to Mer:Qt5 by next meeting? 10:04:43 yup 10:05:26 "upload to Mer:Qt5" ... ahma - when's good to start working on cobs ? 10:06:22 hmm.. I'd finish this round on nomovok obs 10:06:59 makes sense - just not sure when that ends :) 10:08:19 by mid-week, if there is no deadly ahead 10:08:45 hmmm... qtquick1 is WIP and qt3d is not exactly in shape 10:08:45 no problems then 10:08:47 hmm 10:08:52 sb2 10:09:16 some less-used packages may remain broken for a while (*cough* qttools *cough*) 10:09:25 :) 10:09:29 I saw the README 10:10:29 OK - lets deal with sb2 when it happens - if there's an issue then we handle it 10:10:43 sb2 isn't a problem in this regard, i'd think 10:10:52 it builds Qt4 so should be fine 10:10:54 yeah 10:11:54 so, any other issues to bring up? 10:11:57 and then there is qtwayland - we're at mercy of two upstream projects with that, since wayland upstream went into development mode and qtwayland may switch to tracking something new 10:12:26 :nod: 10:12:48 i don't maintain wayland that much at the moment in Mer, i am planning to post Mesa 8.0 soon though 10:12:57 any contributions in that area welcome 10:14:36 FYI: I just pulled latest qt5 sources and there is a new, "promising" branch in at least two modules 10:14:40 "api_changes" 10:15:16 also.. i think we should get a discussion started on releasing@ about qt package names 10:15:25 so we can expect things to break again at some near future 10:15:27 just to preempt any issues 10:15:32 right 10:17:00 it might be best to open that avenue when we have a green build available in public location 10:17:48 it allows to look at the results and makes it easier for everyone to comment on how many things are wrong/broken/bad 10:19:01 sounds like we have a plan then - time to wrap ? 10:19:17 yep 10:19:28 thank you all for coming 10:19:38 #endmeeting