10:01:23 <timoph> #startmeeting Mer platform SDK status meeting
10:01:23 <MerBot> Meeting started Fri Mar  9 10:01:23 2012 UTC.  The chair is timoph. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
10:01:23 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
10:01:33 <timoph> #topic status
10:02:07 <timoph> I've been experimenting with sb2 with the sdk
10:02:11 <lbt> when was the last meeting BTW?
10:02:19 <timoph> a sec
10:02:27 <lbt> just so I know what updates to give :)
10:02:47 <timoph> feb 24
10:02:59 <timoph> so two weeks ago
10:03:07 <lbt> ta
10:03:24 <timoph> anyway. sb2 cross compiles nicely at least armv7hl
10:03:25 <lbt> Maybe start with the SDK update then
10:04:03 <timoph> also tried running qtcreator inside the sdk
10:04:20 <timoph> works but didn't try it with cross compilers
10:05:00 <timoph> for that next thing would be to include sb2, etc. to the sdk image
10:05:41 <timoph> wrote rough docs on sb2 commpilation to the wiki
10:05:44 <timoph> http://wiki.merproject.org/wiki/Platform_SDK#Compiling_with_the_SDK_.28FIXME.29
10:06:08 <timoph> that's pretty much my things
10:06:10 <Stskeeps> lbt has posted a snapshot release that has cross compilers available in a sane manner, ie, seperate repo
10:06:19 <timoph> ah. cool
10:06:24 <timoph> I need to try that
10:06:32 <Stskeeps> mdfe_: http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.txt to catch up
10:06:43 <mdfe_> thx
10:07:27 <lbt> OK, so a couple of weeks ago I did some extensive rewriting of the SDK chroot control script
10:07:36 <lbt> that's a lot more robust now
10:07:45 <lbt> Documentation up on the wiki
10:08:04 <lbt> We had a couple of minor issues but they got fixed
10:08:24 <Stskeeps> kulve: http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.txt to catch up
10:08:33 <lbt> As Stskeeps says, we needed to tweak the mer release process to make a cross/ area
10:08:57 <lbt> http://releases.merproject.org/releases/0.20120315.0.0.2/builds/i486/cross/
10:09:10 <lbt> is now automatically generated from each release
10:09:18 <Stskeeps> (and will be in the SDK .ks?)
10:09:24 <lbt> it's in there now
10:09:40 <lbt> I'd hoped to point at an image but my yaml is buggy :)
10:09:57 <lbt> I'll have an image up this morning
10:10:01 <lbt> (UK time)
10:10:13 <lbt> oh yes
10:10:38 <lbt> Stskeeps also modified the cross tool generation to make generic x86 versions of the gcc/binutils
10:10:56 <lbt> so all SDK work is now doable on any machine
10:11:03 <lbt> any x86 machine :)
10:11:08 <Stskeeps> except for 386
10:11:08 <Stskeeps> :P
10:11:11 <timoph> :)
10:11:19 <Stskeeps> but if you want to develop mer on that, all respect to you..
10:11:19 <Stskeeps> :P
10:11:28 <lbt> *g*
10:12:01 <lbt> I'm still occasionally prodding an lxc version of the SDK
10:12:12 <lbt> and I know phaeron has had some success with a VM version
10:12:26 <Stskeeps> perhaps it could be good to mark as a task bug
10:13:02 <lbt> #action setup bug/tasks for the alternative SDK versions to help track them
10:13:18 <Stskeeps> from plasma active they seem to be working on SDK story too
10:13:33 <Stskeeps> it would be valuable to work with them to show how a vendor can provide a XYZ SDK
10:13:35 <timoph> yeah. I think the SDK development in general could use some more visibility in general and have tasks in bugzilla
10:14:26 <lbt> Stskeeps: agreed - I almost added : I have a task to improve kickstarter to support better image building around SDKs
10:14:39 <Stskeeps> #link http://vizzzion.org/blog/2012/03/plasma-active-3-sprint-ongoing/
10:14:52 <lbt> part of that is to make it easier to assemble custom SDKs for vendors
10:16:08 <lbt> so I'm done for updates
10:16:26 <timoph> so the current status is that we have working cross compilation via sb2, compilers build automagically for mer releases and we have a saner sdk management script in addition to what we had 2 weeks ago
10:16:41 <lbt> info that?
10:16:54 * timoph meant to :)
10:16:57 <Stskeeps> yep, i think we can polish a it on the sb2 part though - the newer sb2 versions make it a little bit easier
10:17:03 <Stskeeps> ie, no need to chmod -R u+w stuff
10:17:10 <timoph> #info the current status is that we have working cross compilation via sb2, compilers build automagically for mer releases and we have a saner sdk management script in addition to what we had 2 weeks ago
10:17:28 <timoph> yeah. chmodding was a bit of a pain
10:17:40 <Sage_> o/
10:17:43 <Sage_> sry I'm late
10:17:43 <lbt> hey Sage_
10:17:50 <lbt> from a planning point of view I'm going to use timoph's work and get that integrated into the image generation
10:18:14 <Stskeeps> timoph: i'd propose a wrapper that sets some sane defaults on top of a given target
10:18:23 <Stskeeps> timoph: or even mic create-sb2-target kind of thing
10:18:30 <lbt> I don't think SDK images should include any target images btw
10:18:32 <timoph> #topic planning
10:18:36 <lbt> yeah
10:18:44 <Stskeeps> slaine: http://mer.bfst.de/meetings/mer-meeting/2012/mer-meeting.2012-03-09-10.01.log.txt to catch up
10:18:45 <timoph> Stskeeps: that sounds like a sane way of doing it
10:18:51 <lbt> create-sb2-target sounds sane
10:18:51 <Stskeeps> Sage_: does mic support plugins?
10:18:56 <slaine> ta
10:19:13 <Sage_> Stskeeps: depends what you mean with that. I has plugin structure for some of the things yes
10:19:15 <Stskeeps> ok
10:19:25 <Stskeeps> Sage_: think mic cr fs --make-sb2-target=name
10:20:10 <Stskeeps> so that'd be available as a sb2 target afterwards to use
10:20:10 <Sage_> hmm... I don't think that is supported you can do mic cr sb2target
10:20:14 <Stskeeps> ok
10:20:17 <Stskeeps> that's ok too
10:20:36 <Sage_> so you should be able to do new image types
10:21:31 <Stskeeps> might make sense
10:22:24 <Stskeeps> would certainly make it a blast to work with, want to build against a plasma image, just create the image and install development headers from their repos
10:22:42 <lbt> *nod*
10:22:49 <timoph> yep
10:23:05 <lbt> I have a delivery :)
10:23:07 <lbt> from a planning point of view I'm going to use timoph's work and get that integrated into the images - try and find places where helper scripts make sense
10:23:09 <lbt> bbiam
10:24:04 <timoph> yeah. I need to try the updated sdk image and fix the compilation bit in the wiki
10:24:31 <timoph> dunno actyally on what to start working after that
10:25:23 <timoph> might be worth to continue experimenting with the application development side of things
10:25:29 <Stskeeps> qt creator sounds like an interesting area
10:25:38 <Stskeeps> and perhaps guides on how to do typical qt programming
10:26:14 <Stskeeps> like, with the sdk
10:26:22 <timoph> I think I'll go for that
10:27:04 <Stskeeps> i'd really like to know how to select different sysroots
10:27:18 <Stskeeps> maybe something to work with the qtonpi guys about
10:27:47 <timoph> yep. since seems that they have that working already
10:27:57 <Stskeeps> only with one hardcoded sysrot
10:28:50 <timoph> it's a start
10:29:15 <Stskeeps> on compilation side (though not really sdk), i got a sb2 build going with the new OBS cross build patches
10:29:31 <Stskeeps> and will start to push patches to them as i walk over my proof of concept and cleanly commit it
10:29:53 <lbt> back
10:31:03 <lbt> so from a planning PoV... I'd like to eventually see something like osc sdkco <pkgA>; osc sdkco <pkgB>;
10:31:23 <timoph> so my next goal is to do cross builds from qtcreator using the sdk and document it
10:31:25 <lbt> that would install the development BR into the target
10:31:44 <Stskeeps> lbt: right, though there's primary use cases first
10:31:53 <Stskeeps> but yes, a useful task bug
10:32:28 <lbt> Stskeeps: so what BRs are in the target?
10:33:12 <Stskeeps> lbt: for now, we start with manual addition of BR's usecase, then we make it easier
10:33:13 <lbt> I am assuming the idea is to avoid needing "osc build"
10:33:16 <Stskeeps> yes
10:33:33 <Stskeeps> "here's a spec, give me BR's" is also ok method
10:33:38 <Stskeeps> build can do this offline
10:33:48 <Stskeeps> .spec and .ks, that is
10:33:52 <lbt> ah, I thought that was an API call to OBS
10:33:53 <Stskeeps> or target, for that matter
10:33:55 <Stskeeps> it is
10:33:59 <Stskeeps> but it can do it without OBS too
10:34:22 <lbt> ah - so build can do it against repos
10:34:29 <Stskeeps> :nod:
10:34:40 <Stskeeps> or against zypp ones
10:34:58 <lbt> but we need osc to do it against projects (like a project with 2-3 packages on the same feature branch)
10:35:16 <lbt> right - so that differentiates the use-cases
10:35:38 <Stskeeps> so we basically just need a day-to-day development environment, i don't even mind to have 'osc createsb2target'
10:36:10 <Stskeeps> but first against images itself
10:36:10 <lbt> yep - so step 1 ... actually use it
10:36:16 <Stskeeps> yep
10:36:31 <lbt> (FYI I do 'all' my Mer development in the SDK)
10:36:44 <lbt> anyone else do that?
10:36:49 <timoph> o/
10:36:50 <Stskeeps> some parts
10:36:53 <Stskeeps> do we have git yet?
10:36:56 <lbt> yes
10:37:13 <lbt> I'm trying to judge what usage is like
10:38:47 * timoph thinking about goals for the next week or two
10:39:58 <timoph> target creation?
10:40:40 <Stskeeps> sounds sane, ie, the first prototype sb2-build-as-it-should-be
10:41:22 <timoph> and also the qt-creator stuff that I'm going to work on
10:41:43 <niqt> target creation = develop how for harmattan ?
10:42:05 <timoph> no. creating scratchbox2 targets
10:42:14 <niqt> ok, how for maemo
10:42:15 <timoph> e.g. n900 nemo target
10:42:21 <lbt> I'd like a goal of everyone here using SDK as their primary dev environment
10:42:29 <Stskeeps> niqt: we'll only be doing mer SDK targets
10:42:46 <Stskeeps> albeit there might be some reasoning for qtonpi stuff too, if we can group effort..
10:43:10 <lbt> timoph: Nemo, PA etc targets should naturally fall out of image creation
10:43:32 <timoph> well yeah but one should be able to bake such a target
10:43:41 <lbt> I'm not knowledgeable enough about Harmattan to know if we can do it there
10:43:48 <lbt> don't see why not
10:44:06 <Stskeeps> i'd advise against it, we'd have to do too much scratchbox1 emulation
10:44:12 <lbt> OK
10:44:36 <timoph> yeah. maemo already has a sdk
10:44:42 <timoph> we don't need to redo it
10:46:48 <lbt> I'm fine with that - like I say, I don't see much of Harmattan :)
10:47:26 <timoph> I'd say we just need to provide targets for Mer itself. People can expand the targets to include what they need in them (this is what I meant by the nemo n900 example)
10:47:31 <Stskeeps> :nod:
10:48:03 <timoph> so. anything else?
10:48:27 <lbt> OK - in that case I think we need people to put a Nemo "reference vendor" hat on and check the SDK is suitable for Nemo
10:48:27 <timoph> are we happy with the next goals? target creation & the qtcreator stuff
10:48:52 <lbt> by building Nemo SDK targets and reporting issues back to us
10:49:00 <lbt> timoph: yep
10:49:09 <timoph> lbt: I've being using nemo n950 image with sb2 to compile stuff
10:49:41 <lbt> yep - I'm just doing my vendor interface bit :)
10:50:01 <timoph> #info next goals: sdk target creation and cross compilation with qtcreator
10:50:17 <timoph> next meet? in a week (or two)?
10:50:45 <lbt> weekly meetings are fine for me ... fast moving area
10:50:50 <timoph> true
10:51:36 <timoph> let's fine tune the exact time & day in the beginning of the week (dunno yet how busy my week is)
10:52:09 <timoph> anything else?
10:52:20 <lbt> not here
10:52:58 <timoph> ok. thanks for attending.
10:53:01 <lbt> o/
10:53:04 <timoph> #endmeeting