16:01:08 <timoph> #startmeeting Mer Platform SDK status / planning meeting
16:01:08 <MerBot> Meeting started Fri Feb 24 16:01:08 2012 UTC.  The chair is timoph. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings.
16:01:08 <MerBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:19 <timoph> hello and welcome
16:01:29 <timoph> who do we have here?
16:01:38 <Stskeeps> i'm present
16:02:14 <timoph> lbt: around?
16:02:19 <lbt> yes
16:02:24 <timoph> good :)
16:02:51 <timoph> #topic status update
16:03:23 <timoph> hmmh
16:03:37 <Stskeeps> status from me: not really done anything on SDK side, except for a quick proof of concept with scratchbox2 within the sdk and building software/installing build dependencies for a target
16:04:08 <timoph> I've also been quite busy with other things so haven't done much
16:04:08 <lbt> A few points from me
16:04:29 <lbt> Page here is reasonably up to date http://wiki.merproject.org/wiki/Platform_SDK
16:04:40 <lbt> Been working on using kickstarter to prepare images
16:04:41 <timoph> I did start to improve the helper script but then again lbt had already done something with it :)
16:05:01 <lbt> Yeah, that's .... grown :)
16:05:19 <lbt> https://github.com/lbt/sdk-kickstarter-configs
16:05:29 <lbt> has the latest published sources
16:05:36 <jukkaeklund> ok thats good
16:05:39 <lbt> so images
16:05:47 <lbt> Available under https://img.merproject.org/images/sdk/
16:05:48 <lbt> Focus on mic/osc so far - x86 project building and all image building works
16:06:05 <lbt> you can essesntially follow the SDK page and build stuff
16:06:09 <lbt> including the SDK
16:06:13 <lbt> which is nice
16:06:18 <timoph> #info sources available from https://github.com/lbt/sdk-kickstarter-configs
16:06:32 <lbt> I also updated several packages too
16:06:43 <timoph> #info images from https://img.merproject.org/images/sdk/
16:06:58 <lbt> #info OBS project https://build.pub.meego.com/project/show?project=Mer%3ATools%3ATesting has tools
16:07:17 <lbt> and that includes latest mic/spectacle/kickstarter
16:07:22 <lbt> with some bugfixes
16:07:31 <lbt> I updated all relevant wiki pages (I think)
16:07:43 <timoph> cool
16:07:59 <lbt> so http://wiki.merproject.org/wiki/Category:About should link to sane information for all of them
16:08:16 <lbt> Produced some yaml for an sb2 kickstart too
16:08:26 <lbt> based on Stskeeps' PoC
16:08:37 <lbt> https://build.pub.meego.com/package/view_file?file=00sdk.yaml&package=sdk-kickstarter-configs&project=Mer:Tools:Testing
16:08:43 <lbt> for those who want gory details
16:08:51 <lbt> There are some problems on sb2
16:09:06 <lbt> essentially our cross-tools are built for ssse3 processors
16:09:08 <lbt> :O
16:09:16 <lbt> so my AMD desktop is sad
16:09:26 <lbt> (like MeeGo all over again!)
16:09:38 * timoph was just about to say that :)
16:09:39 <lbt> but Stskeeps assures me that this will be sorted before he sleeps again
16:09:43 <lbt> so next week some time
16:10:05 <Stskeeps> will be fixed in next-next core release as changing that detail can break ability to release
16:10:11 <sledges> :)
16:10:19 <lbt> yeah - that is next week?
16:10:28 <lbt> post tuesday iirc?
16:10:31 <Stskeeps> :nod:
16:10:43 <lbt> OK - so it's not worth worrying about until then
16:11:00 <Stskeeps> since we have a basic platform sdk going, our documentation should revolve around that method
16:11:06 <Stskeeps> ie, no more 'mic2'
16:11:09 <lbt> I have hacked a bit at the sb2 side and it looks like it'll be reasonable
16:11:11 <lbt> totally
16:11:18 <lbt> I've removed mic2 from tools and wiki
16:11:30 <lbt> (although pages still need editing as per the bug)
16:11:40 <Stskeeps> but it also means we have a starting point for vendors, "install platform sdk, try to make an image.."
16:11:55 <lbt> yep - and that's working today
16:11:59 <Stskeeps> so we can iterate developers/vendors alike on how easy it is to use mer
16:12:01 <timoph> anything else for the current status?
16:12:08 <lbt> we also need to extend that to include Vendor repos
16:12:16 <lbt> timoph:  yes, I'm reworking the enter_chroot
16:12:18 <lbt> again
16:12:22 <timoph> :)
16:12:33 <lbt> so it has mer_sdk_chroot mount|enter|umount
16:12:37 <timoph> still a shell script?
16:12:45 <lbt> and you can enter it multiple times
16:12:45 <Stskeeps> lbt: mount does what specifically?
16:12:46 <lbt> yes
16:12:50 <lbt> ....
16:12:52 <lbt> mounts?
16:12:59 <Stskeeps> yes, mounts what, a horse, a duck or /home ?
16:13:11 <lbt> hey, keep it clean!
16:13:34 <lbt> so it does /proc and /sys etc
16:13:44 <lbt> and all data mounts
16:13:46 <lbt> and /home
16:14:00 <lbt> it also allows user hooks
16:14:15 <lbt> so I use that because I have some / symlinks I like
16:14:32 <timoph> so the default is to mount "all" but one can opt out
16:14:44 <lbt> most of the complexity is traps and such like to minimise risk of stale mounts
16:15:34 <Stskeeps> can we check in 'enter' that 'mount' hasn't been done?
16:15:36 <Stskeeps> and instruct accordingly
16:15:39 <lbt> yes
16:15:46 <Stskeeps> and advise upon exit, too
16:15:52 <Stskeeps> to umount before rm -rfing
16:16:20 <timoph> #topic planning
16:16:21 <lbt> http://pastie.org/3447279
16:16:28 <lbt> mmm poor formatting
16:16:35 <lbt> the rm -rf issue is hard
16:16:41 <lbt> I will investigate immutable
16:17:09 <lbt> if you bind mount /home to /fred/home and rm -rf /fred ...
16:17:17 <lbt> there's not a lot we can do
16:17:36 <timoph> we can't protect the user from everything
16:17:48 <timoph> if one does stupid things then one does
16:17:50 <Stskeeps> ok, so planning: we can start with designing the sb2 side next week, with implementation after first prerelease
16:17:51 <lbt> and since people can open 2 shells at once ... then whilst /home is mounted on the SDK if they rm the SDK ... game over
16:17:56 <lbt> yep
16:18:22 <lbt> I discussed with you this morning and I think we won't need to do much wrt more mounts
16:18:23 <Stskeeps> it's quite powerful proposition as we have a genuinely fast and easy to use build environment
16:18:38 <timoph> yes
16:18:49 <lbt> I'm aiming to have a variety of images available too
16:19:02 <timoph> for the sdk?
16:19:03 <lbt> and make it easy for a vendor to make their own which includes their code
16:19:06 <lbt> yes
16:19:16 <lbt> some uses will be non-SDK
16:19:22 <lbt> eg mic bootstrap
16:19:51 <timoph> ok
16:20:17 <timoph> the sb2 stuff is actually the thing I'm most clueless about
16:20:31 <lbt> yeah, I'm going to document it
16:20:31 <timoph> so what do we actually need to do there
16:20:33 <alterego> My SDK is installed in /opt/mer/mer-platform-sdk :)
16:20:49 <Stskeeps> i can guide through that as well, we should just get over some basic installation problems
16:20:52 <lbt> alterego: yeah, I do that
16:21:15 <Stskeeps> but the premise is that you can generate a random mer image, initialize it as a SB2 target, install development headers, and build easily software within it
16:21:33 <Stskeeps> with cross compilers and fast tools
16:21:43 <timoph> ok. I can document the thing while someone walks me through it
16:21:59 <timoph> should be a good sanity check
16:22:30 <Stskeeps> so, a realistic goal for next week: guide that describes platform sdk install, creation of custom image with kickstarter, basic idea for how hardware adaptations can provide kickstarter yamls, building image?
16:22:32 <lbt> so I think our next goal is sb2 building
16:22:57 <Stskeeps> and sb2 building, that is
16:23:07 <timoph> sounds good
16:23:25 <Stskeeps> an example can be that x86 adaptation should provide a yaml installable into the sdk somehow
16:23:46 <lbt> yeah - I may need to rework kickstarter somewhat
16:23:52 <Stskeeps> so we can do lego block style image building
16:23:59 <Stskeeps> "take this hardware adaptation, this mer core, this UI.."
16:24:08 <lbt> exactly
16:24:30 <lbt> before we go too far there though
16:24:39 <lbt> I'd like to validate the SDK against Nemo
16:25:36 <timoph> should be a good proof that it works if you can build nemo with it
16:25:47 <lbt> build a nemo package anyway
16:25:58 <lbt> ideally not using osc build
16:26:21 <Stskeeps> :nod:
16:26:24 <lbt> Stskeeps: so I'd like to declare an sb2 minimal target
16:26:45 <Stskeeps> as in?
16:26:58 <timoph> a cross-build-essential?
16:27:02 <lbt> as you did with mer-core-arm7l
16:27:28 <Stskeeps> okay, so basic development headers and so on in there?
16:27:36 <lbt> mic cr fs -A armv7l mer-core-armv7l-base.ks
16:27:49 <lbt> then sb2-init it
16:27:56 <lbt> then install devel headers
16:28:00 <Stskeeps> right
16:28:01 <lbt> then do something like sb2 install-build-depends SMS-tool.spec
16:28:17 <Stskeeps> are we talking about a build-essential, or a basic usecase
16:28:25 <lbt> usecase
16:28:28 <Stskeeps> ok
16:28:39 <lbt> *then* do something like sb2 install-build-depends ophono.spec
16:28:56 <lbt> and have both ophon and sms-ui build-dep in the root
16:29:09 <lbt> and have both source packages in the SDK
16:29:34 <Stskeeps> makes sense
16:29:35 <lbt> then see how the source in the SDK uses the ophono in the SDK
16:29:42 <lbt> which will hurt I think
16:30:17 <lbt> but if we solve that in a general way, I think we end up with make world ?
16:30:19 <Stskeeps> it can, i guess, but we'd need a publish-package kind of thing
16:30:30 <Stskeeps> fwiw
16:30:37 <Stskeeps> first goal is to simply ./configure, make kind of thing
16:30:37 <lbt> yes make install would install to sb2
16:30:51 <Stskeeps> rpmbuilding is a little more involved as a start
16:31:03 <lbt> yeah ... anyhow... some vague ideas
16:31:12 <Stskeeps> :nod:
16:31:27 <lbt> I'm also keen to keep stuff out of the SD
16:31:28 <lbt> K
16:31:43 <lbt> use the fact that we have bindmount to the desktop
16:31:43 <Stskeeps> mm?
16:31:47 <Stskeeps> well, of course
16:31:57 <Stskeeps> sdk is supposed to be replace-able
16:32:18 <Stskeeps> your targets would go in your homedir, i guess
16:32:55 <lbt> I'm thinking that git/emacs/eclipse/QtCreator - all run outside SDK
16:33:07 <lbt> git maybe not ... but maybe
16:33:10 <alterego> I think git should be in SDK ;)
16:33:14 <alterego> :)
16:33:22 <lbt> alterego: I kinda don't
16:33:30 <alterego> I was actually going to play around with getting Qt Creator to work with the chroot
16:33:31 <lbt> it's an editor
16:33:39 <lbt> alterego: with but not in?
16:33:43 <alterego> Well, I don't think it really matters too much.
16:33:47 <alterego> Not in
16:33:48 <alterego> With
16:33:48 <Stskeeps> lbt: weigh it with practicality
16:33:59 <lbt> no - but I'm really interested in mininimising support costs
16:34:00 <Stskeeps> and let's see how people use platform sdk
16:34:10 <Stskeeps> exiting in and out of a chroot is not pleasant
16:34:13 <Stskeeps> i do that with osc
16:34:13 <alterego> I'd personally like git in there.
16:34:23 <alterego> I have issues with using scratchbox for harmattan development and not having git.
16:34:45 <lbt> alterego: *nod*
16:34:49 <alterego> (obviously I've added git to it now) but more terminals/tabs sometimes annoys bme.
16:35:21 <Stskeeps> lbt: at least our set is limited by what is in mer core anyway, and what can be used to build things in OBS
16:35:24 <alterego> otoh, who says everyone uses git ;)
16:35:25 <lbt> I bring it up as an edge-case
16:35:39 <Stskeeps> i wouldn't outright ban it, i would just say some tools are second tier
16:35:48 <Stskeeps> ie, primary usecases and secondary helpers
16:35:57 <lbt> *nod*
16:36:21 <alterego> So, the platform SDK, is that meant as an image creation and platform package development area?
16:36:25 <Stskeeps> git is a normal tool to work on mer (git clone ssh://review..)
16:36:30 <timoph> I'm with Stskeeps on let's do it so that it works and see how people use it and change it accordingly
16:36:30 <Stskeeps> so i would reason that to be part
16:37:07 <Stskeeps> alterego: tools needed to develop with mer on a platform level, apps is ideally with qt creator instead
16:37:12 <alterego> I'm just wondering about the application sdk, which obviously doesn't actually exist yet, but would it be a similar architecture?
16:37:38 <alterego> So, would that mean we need to get sysroots for madde?
16:37:56 <Stskeeps> yes, that'll come in some form, but first we need a proper platform sdk
16:38:03 <Stskeeps> else people can't contribute or use mer properly :)
16:38:17 <alterego> It would be cool if a vendor could go: "platform: packages; sdk: libqt, libofono, etc"
16:38:19 <Stskeeps> app sdk wouldn't be chroot based
16:38:41 <alterego> And have the platform SDK spit out a device image and an application sysroot.
16:38:49 <Stskeeps> for example
16:38:56 <timoph> yep
16:38:58 <alterego> Where the sysroot only has the -dev versions of "public" API packages, like qt, ofono.
16:39:08 <Stskeeps> anyway, we're drifting
16:39:14 <alterego> Sorry ;)
16:39:23 <Stskeeps> so, we have a plan for the next week?
16:39:29 <timoph> so to summarize
16:39:54 <timoph> next weeks targets: setup guide, image building and sb2?
16:40:00 <timoph> was there something else?
16:40:31 <Stskeeps> [17:22] <Stskeeps> so, a realistic goal for next week: guide that describes platform sdk install, creation of custom image  with kickstarter, basic idea for how hardware adaptations can provide kickstarter yamls, building image?
16:40:35 <Stskeeps> [17:22] <lbt> so I think our next goal is sb2 building
16:40:36 <Stskeeps> [17:22] <Stskeeps> and sb2 building, that is
16:40:38 <Stskeeps> [17:23] <timoph> sounds good
16:40:39 <Stskeeps> [17:23] <Stskeeps> an example can be that x86 adaptation should provide a yaml installable into the sdk somehow
16:40:42 <Stskeeps> yeah
16:41:03 <Stskeeps> also, for good measure: write up use cases as we go along
16:41:05 <Stskeeps> for QA later
16:41:12 <timoph> yes
16:41:24 * sledges can't wait :)
16:41:27 <lbt> timoph: can you update the wiki page at the bottom too
16:41:34 <lbt> delete old stuff
16:41:38 <timoph> lbt: I can
16:42:09 <lbt> meet again next week? Earlier for Sage?
16:42:38 <timoph> so we have enough time to spare to get those things done?
16:42:56 <lbt> *g* .... nothing but time :)
16:42:59 <timoph> I was thinking we could meet again on fri
16:43:13 <timoph> well. I only have the evenings
16:43:53 <timoph> so what would be a good time for Sage? anyone know?
16:44:00 <Stskeeps> perhaps on thursdays instead?
16:44:07 <timoph> works for me
16:44:18 <lbt> sure
16:44:32 <Stskeeps> let's just put it out to a discussion on mailing list, but thursday may work better for people
16:44:32 <timoph> after 15 utc that is
16:44:43 <Stskeeps> i know for a fact i'd be in a bar if i was working in an office on a friday at this point
16:44:46 <Stskeeps> :P
16:44:55 <timoph> :)
16:45:07 <Stskeeps> so, AOB?
16:45:14 <timoph> #topic AOB
16:45:22 <timoph> anything else?
16:45:43 <Stskeeps> feedback on what we have delivered so far in platform SDK/documentation/etc as well
16:46:17 <lbt> The whole tools area is in rapid churn at the moment too
16:46:18 <timoph> do we have any brave souls experimenting with the sdk?
16:46:33 <timoph> we could ask feedback/input from the mailing list
16:46:35 <lbt> oh yes
16:46:43 <lbt> sonach has tried it I think
16:46:53 <Stskeeps> and others
16:47:14 <timoph> would be good to hear what they would like to see in it
16:47:17 <lbt> yep, jackylau this morning
16:47:53 <slaine> I tried it too last week
16:48:03 <Stskeeps> the important thing is that we get the basic use cases going nice and stable first, then move on to more advanced
16:48:05 <slaine> will give it another go over the weekend
16:48:15 <Stskeeps> this is going to be the primary interface to mer for many
16:48:22 <alterego> I'm using it at the moment :)
16:48:33 <alterego> Not done anything serious yet except build a few images.
16:48:46 <alterego> Gonna be attempting to build binaries later.
16:48:51 <lbt> I'm using it for images but waiting for sb2 for building
16:49:00 <lbt> alterego: you got ssse3?
16:49:07 <alterego> Yup
16:49:24 <lbt> I can give you some sb2sdk  .ks that you can try
16:49:44 <alterego> Sure
16:49:53 <lbt> #mer later then :)
16:49:59 <timoph> ok. if there's nothing else. I think we can call it
16:50:15 <Stskeeps> do we have a SDK bugzilla section?
16:50:24 <lbt> we do
16:50:46 <lbt> and "ssues with the SDK itself rather than the tools within it. If a Mer tool has a problem in the SDK that's a tool bug"
16:51:03 <lbt> is the comment
16:51:12 <lbt> with an "I" on the front :)
16:51:18 <timoph> :)
16:52:03 <timoph> #info bugzilla has a section for the SDK (don't file tool bugs there)
16:52:44 <lbt> we don't have any CI process for Tools yet
16:52:57 <timoph> ok. I'll send email about the meeting time on thu and other one asking for sdk input/feedback
16:52:59 <lbt> nor do I plan to in the next week
16:53:28 <timoph> anything else or can we move to #mer
16:54:13 <timoph> ok. thanks for attending
16:54:16 <timoph> #endmeeting