09:30:42 <Stskeeps> #startmeeting Qt5 integration meeting 27/2/2012
09:30:42 <MerBot> 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 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
09:30:58 <Stskeeps> should we give ahma a moment to show?
09:31:38 <lbt> sure - Bostik was calling him
09:31:51 <Bostik> 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 <Stskeeps> alright.. perhaps i can just introduce what i hope to see from architectual side
09:32:55 <Stskeeps> 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 <Stskeeps> such as pkgconfig(QtCore) >= 4.8.0
09:33:35 <Stskeeps> 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 <Stskeeps> i'm not expecting those to be converted or using qt5 at this moment
09:34:25 <lbt> longer term are we supporting both 4.8 and 5 ?
09:34:36 <lbt> I can see that being needed
09:34:39 <Stskeeps> we'll have to see how the situation looks like, qt5 is not finally released in any way yet
09:34:50 <Stskeeps> 4.8 can be supported in reverse way of how we allow qt5 to co-exist
09:35:12 <w00t> i'm suffering quite bad packet loss atm.. will try paritcipate though
09:35:14 <Bostik> aye, the only truly conflicting parts are the -devel packages
09:35:28 <Stskeeps> have you had any problems noticed so far?
09:35:41 <Stskeeps> like, specific examples we need to be vary of
09:35:47 <Bostik> as *.pc and the naked .so symlinks are going to be the same
09:35:59 <w00t> >= 4.8.0 is a bit painful - what happens when i integrate 4.8.1? (aimed to be released quite soon)
09:36:00 <Stskeeps> :nod:
09:36:28 <Stskeeps> w00t: well, for now, we do it with >= 5.0, ie, specifically indicate we need to use qt5
09:36:36 <w00t> ok, that's fine
09:36:39 <Stskeeps> and Prefer: those packages
09:36:52 <Stskeeps> Bostik: right, so we have to avoid those getting mixed
09:37:12 <lbt> so conflicts?
09:37:23 <w00t> qjson might be droppable in the long term (as qt5 has its own json handling)
09:37:27 <Bostik> 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 <lbt> will a device be able to run qt4 and qt5 apps concurrently?
09:38:47 <Stskeeps> as long as they don't install devel headers, i would assume so
09:38:54 <Stskeeps> due to so-names being different
09:39:04 <w00t> yes
09:39:05 <lbt> just making our requirements explicit
09:39:13 <Bostik> 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 <w00t> i run 4/5 on my desktop, so i don't see why not
09:39:37 <lbt> w00t: indeed it's normal there
09:40:21 <w00t> and there will be a period of transition required.. it isn't a straightforward jump
09:40:26 <Bostik> 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 <Bostik> 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 <Stskeeps> :nod:
09:41:27 <Stskeeps> worth checking
09:41:48 <Bostik> mostly due to qt5 being somewhat broken and in, not long ago, in heavy flux
09:42:10 <Bostik> ahma just woke up
09:42:20 <Stskeeps> 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 <Bostik> aye
09:42:46 <Stskeeps> so we should rely on pkgconfig() as much as we can
09:43:34 <w00t_local> ok, on a local connection now, so hopefully a bit less lagtastic
09:43:39 <lbt> do we handle CI of Qt integration differently? thinking testing
09:43:51 <Bostik> I'm on the releasing list, so far it has been rather quiet
09:43:58 <Stskeeps> ahma: http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-02-27-09.30.log.txt to catch up
09:44:05 <ahma> Jello
09:44:39 <Stskeeps> 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 <Stskeeps> so when we have a working snapshot and proven additional prjconf items, we can add it to mer core
09:45:58 <Stskeeps> in longer term, we might want to run test cases of qt5 as well as part of the mer core CI
09:46:10 <lbt> *nod*
09:46:24 <lbt> is Qt5 packaging more modular?
09:46:35 <Bostik> yes, *very much*
09:46:52 <lbt> would be nice to have a page on the wiki with links
09:46:54 <Stskeeps> this can be positive and negative, as the snapshots are usually in lockstep
09:47:05 <lbt> and mer specific pages
09:47:21 <Bostik> qt5/modular-qt-specs% git grep -E '^%package' | wc -l
09:47:21 <Bostik> 96
09:47:22 <lbt> http://wiki.merproject.org/wiki/Category:About
09:47:36 <Stskeeps> we should start a 'Qt5' wiki page
09:47:44 <lbt> Bostik: ok - but still a monolithic tarball ?
09:47:50 <Bostik> good heavens no
09:48:06 <Bostik> ahma took my packaging specwork as his baselin
09:48:09 <lbt> you say that like we haven't had X years of then :)
09:48:16 <Stskeeps> lbt: qtbase, qtdeclarative, qttools, are seperate source packages/tarballs now
09:48:23 <ahma> tar structure is modularized
09:48:26 <lbt> and I've not looked at the git recently  :)
09:48:39 <lbt> excellent ... my workers will be happy :)
09:48:53 <Bostik> this is the baseline: https://gitorious.org/modular-qt-specwork/modular-qt-specs
09:48:55 <lbt> (sounds like I need a bwaahahaha)
09:49:05 <ahma> though they assume builds are monolithic ;)
09:49:27 <Bostik> ahma has done some pretty neat tuning on top of that over the weekend, I see
09:49:57 <Bostik> since several of the packages (starting from qtbase) are now going through and producing packages again
09:50:41 <Stskeeps> lbt: can we get a Mer:Qt5 repository on COBS?
09:50:46 <lbt> and are we moving this work to the MeeGo c.obs
09:50:53 <lbt> we can
09:51:26 <ahma> Bostik: need couple of days to clean up the rest, but yes
09:51:44 <Bostik> goody
09:51:55 <Stskeeps> is it reasonable that we start having qt5 within a mer prerelease in 2 weeks?
09:51:59 <Stskeeps> +timeframe
09:52:13 <Stskeeps> that can run qml2 demos
09:52:39 <lbt> ahma: when you move to c.obs we need to look at worker allocation - can you make a note
09:53:01 <lbt> otherwise you may be blocked to worker4 only
09:53:30 <lbt> Stskeeps: in mer-core/ ?
09:53:33 <ahma> good to know, I'll make some noise when I'll move the integration effort there
09:53:44 <Stskeeps> lbt: right
09:54:14 <Stskeeps> just trying to get some kind of feel of the timeframe we're talking here of effort
09:55:52 <Stskeeps> (and what ahma and bostik thinks is reasonable / ahma's allocation to this work)
09:56:45 <ahma> it varies
09:57:20 <Bostik> 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 <Stskeeps> i'll help handholding a bit when it comes to mer-core processes and perhaps OBS project configuration stuff, at least
09:57:33 <ahma> 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 <ahma> assuming there are no more potholes (bwaahaha?) :)
09:58:41 <Bostik> if there are any really freaky packaging problems I can have a look if needed
09:58:59 <Stskeeps> :nod:
09:59:08 <Stskeeps> should we have a meeting around this time next week too to sync again?
09:59:08 <Bostik> 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 <Bostik> the worst offender by far is the abuse of DESTDIR macro
10:00:02 <lbt> Stskeeps: I was wondering about that - maybe getting a list of "when this is done we're good"
10:00:28 <lbt> hopefully "when the obs monitor page is green we're finished" :D
10:00:42 <Bostik> 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 <Stskeeps> so, i'm only admitting stuff to mer core that builds and installs, naturally ;)
10:01:10 <Stskeeps> so, task list.., please note if you disagree
10:01:11 <lbt> to what extent are we pulling from upstream over the next 2 weeks ?
10:01:46 <Bostik> 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 <lbt> what I mean is .. are problems being resolved upstream or does that introduce too much churn
10:01:56 <lbt> yeah - thought so Bostik
10:02:03 <Bostik> just in case they broke something *again*
10:02:39 <lbt> 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 <lbt> then after that we re-sync
10:04:05 <Bostik> aye
10:04:09 <ahma> sounds reasonable
10:04:21 <Stskeeps> 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 <lbt> yup
10:05:26 <lbt> "upload to Mer:Qt5" ... ahma - when's good to start working on cobs ?
10:06:22 <ahma> hmm.. I'd finish this round on nomovok obs
10:06:59 <lbt> makes sense - just not sure when that ends :)
10:08:19 <ahma> by mid-week, if there is no deadly ahead
10:08:45 <Bostik> hmmm... qtquick1 is WIP and qt3d is not exactly in shape
10:08:45 <lbt> no problems then
10:08:47 <lbt> hmm
10:08:52 <lbt> sb2
10:09:16 <Bostik> some less-used packages may remain broken for a while (*cough* qttools *cough*)
10:09:25 <lbt> :)
10:09:29 <lbt> I saw the README
10:10:29 <lbt> OK - lets deal with sb2 when it happens - if there's an issue then we handle it
10:10:43 <Stskeeps> sb2 isn't a problem in this regard, i'd think
10:10:52 <lbt> it builds Qt4 so should be fine
10:10:54 <lbt> yeah
10:11:54 <Stskeeps> so, any other issues to bring up?
10:11:57 <Bostik> 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 <Stskeeps> :nod:
10:12:48 <Stskeeps> 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 <Stskeeps> any contributions in that area welcome
10:14:36 <Bostik> FYI: I just pulled latest qt5 sources and there is a new, "promising" branch in at least two modules
10:14:40 <Bostik> "api_changes"
10:15:16 <Stskeeps> also.. i think we should get a discussion started on releasing@ about qt package names
10:15:25 <Bostik> so we can expect things to break again at some near future
10:15:27 <Stskeeps> just to preempt any issues
10:15:32 <Bostik> right
10:17:00 <Bostik> it might be best to open that avenue when we have a green build available in public location
10:17:48 <Bostik> 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 <lbt> sounds like we have a plan then - time to wrap ?
10:19:17 <Stskeeps> yep
10:19:28 <Stskeeps> thank you all for coming
10:19:38 <Stskeeps> #endmeeting